input type not dynamic

[paolino]

Trying to add the classic switch from visible to invisible password field. The dynamic attributes are not controlling the "type" attribute.

do
                    seeD :: DS Bool <- icon ["eye"] >>= foldDyn (const  not) False
                    let pwAttrD  = fmap ("name" =: "password" <> ) $ ffor seeD $ \case
                            True -> "type" =: "password"
                            False -> "type" =: "text"
                    (u,pw) <- elAttr "form" ("autocomplete" =: "on" <> "name" =: "login") $ do
                        u <- divClass "username" $ do
                            text "email"
                            textInput $ def
                                & set textInputConfig_inputType "email"
                                & set textInputConfig_attributes
                                    (constDyn $ "name" =: "username")
                        pw <- divClass "password" $ do
                            text "password"
                            textInput $ def
                                -- & set textInputConfig_inputType "password"
                                & set textInputConfig_attributes
                                    pwAttrD
                        return (u,pw)

[tomsmalley]

You should use inputElement instead: textInput sets the type explicitly with the _inputType field, as you've seen. This overrides any dynamic "type" attribute. I believe we are going to be moving away from textInput and friends, but unfortunately the examples haven't caught up yet.

[paolino]

Thanks for pushing me to the source, so now I have my eye-featured password field.

Regarding TextInput obsolescence, I think a dedicated constant config field for the input type attribute was a good idea and the see / not see dynamic is indeed a special case for modern password fields.

Nevertheless, I cannot think of a valid application of the rewrite interpretation of the textInputConfig_inputType field.

So, if we don't come up with a counter example where rewriting the dynamic attribute is an expected / wanted feature, I would propose a breaking back compatibility change with a fallback interpretation of the inputType field, betting it will actually break no old code and give us the the chance to reuse TextInput for optionally observable password fields.

[dfordivam]

@paolino actually the textInput is already in a "backward compatibility"/deprecation cycle. There is a bigger problem with this API that it cannot work with prerender/ static rendering.
So for all new code inputElement is the recommended API to use.

@luigy perhaps textInput should have a deprecated marking?

[ali-abrar]

It seems to me that if you're changing the type of the input, you should probably wrap the whole thing in some kind of Workflow that knows how to handle the switching and convert the value of the input from the type expected by the initial input to the type expected by the switched input. What would happen, for example, if you switched from "text" to "checkbox"?

[dredozubov]

@paolino can you post the workaround for the problem? I agree the current implementation of textInput looks completely broken in regard of it bluntly overwriting the textInputConfig_inputType value.

[paolino]

I'm working on something else now, so I hope I'm pasting the right snippet eh. 1. passwordInput :: (MS m, DomBuilderSpace m ~ GhcjsDomSpace) 2. => Bool -> DS Bool -> m (TextInput Spider) 3. passwordInput t seeD = do 4. let dAttr = fmap (("autocomplete" =: if t then "new-password" else "current-password") <>) $ ffor seeD $ \case 5. True -> "type" =: "password" 6. False -> "type" =: "text" 7. modifyAttrs <- dynamicAttributesToModifyAttributes $ dAttr 8. i <- inputElement $ def 9. & inputElementConfig_elementConfig . elementConfig_modifyAttributes 10. .~ fmap mapKeysToAttributeName modifyAttrs 11. return $ TextInput 12. { _textInput_value = _inputElement_value i 13. , _textInput_input = _inputElement_input i 14. , _textInput_keypress = domEvent Keypress i 15. , _textInput_keydown = domEvent Keydown i 16. , _textInput_keyup = domEvent Keyup i 17. , _textInput_hasFocus = _inputElement_hasFocus i 18. , _textInput_builderElement = i 19. } Best

…

On Wed, 26 Jun 2019 at 16:57, Denis Redozubov ***@***.***> wrote: @paolino <https://github.com/paolino> can you post the workaround for the problem? I agree the current implementation of textInput looks completely broken in regard of it bluntly overwriting the textInputConfig_inputType value. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#283?email_source=notifications&email_token=AAANYHUPMM3S7OVPHVAS4HTP4N7V7A5CNFSM4GRJEE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYTZ6NI#issuecomment-505913141>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAANYHTTQMKEEO3RXYAZOT3P4N7V7ANCNFSM4GRJEE7Q> .

-- Paolo Veronelli ([email protected]) *Functional developer @ global.de <http:https://global.de/>*

[dredozubov]

That's what I did as well, thanks.