Please have a look at this Ellie:
https://ellie-app.com/pqP4bfpDbCa1
There is an text input field, that gets the value from one of two fields in the model, dependent on a third field. That works fine until you change the value in the input field. From then on, it never gets updated anymore.
Why is that, and how should i fix it so it does update?
this is a common enough occurence with forms that change dynamically, The way to fix it is to use the Html.Keyed library, which enables you to create mark up that ‘forces’ the elm diffing engine to update your input field
Others will explain it better than me, but perhaps this clue is enough to get you started?
Thanks for the reply. Tried it (see https://ellie-app.com/pC7bSjJQbha1), but it does not solve it. Then again, i may just not understand the Keyed thing.
@eelcoh I believe in this case Element.Input.textKey is actually what you need to use. Quoting the docs (emphasis original):
Style Elements renders a text input using defaultValue, but if the value changes in your model, but not as a result of the input onChange event, then your input and model will get out of sync.
So, if you manually change the value of a text input in your model, you need to ensure this key changes.
A common way to do this is to maintain increment a counter whenever you manually change the text.
This option will be removed as soon as this bug is addressed farther upstream.
So if it feels awkward and like a hack, it’s because it is.
In particular, I’d strongly advise considering migration to the same author’s stylish-elephants library, as it seems to have this bug/hack fixed — at least for me it worked OK out of the box, while I had to use textKey previously.
Yes, textKey solved it! Thanks!
Fixed at https://ellie-app.com/pC7bSjJQbha1
Cool to hear 
Hrm. Is that not an indication of a bug in the virtual DOM implementation?
Using Html.Keyed sounds like a nasty workaround to me. Especially since the documentation currently reads
A keyed node helps optimize cases where children
and we don’t want to optimise, right? We want the virtual DOM to actually render our view and not take shortcuts it deems to be appropriate but which in fact cause the rendering to break.
I don’t think the virtual dom is taking shortcuts in this case; it literally does not know more by default. I believe other non-keyed vdom implementations exhibit a similar behaviour. Perhaps the documentation for keyed could be clearer in that regard, or a warning could be fired.
But if it didn’t and made the browser render the whole view instead of some parts only, it would probably render fine, no? So I reckon that the vdom implementation decides to not having to instruct the browser to re-render certain parts which causes issues in this case.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.