Thanks OvermindDL1, that's very helpful. I now understand it's down to the lack of two-way binding. Makes sense. Wouldn't it be useful to use a change of id attribute as a change of key?
On Tuesday, October 11, 2016 at 6:11:15 PM UTC+1, OvermindDL1 wrote: > > The ticked checkbox is because the user ticked it, it is some of the > implicit DOM state. When the view changed to remove a checkbox but it > still had another one after, since they were not keyed it just did a 'diff' > between states. The vdom has no information on any implicit state in the > actual DOM, in fact it does not access the actual DOM at all except to > apply patches, thus when it saw from its point of view that the checkbox > label had its name changed but nothing else different about it then it sent > a patch to change the text and that is all. By changing the 'key' of it > then it knows that it is an entire tree change and will not even attempt a > patch but will instead rather re-generate the entire tree. > > Basically if a tree were to be regenerated just because some text changed > than that would make a virtual-dom extremely slow, its whole point is only > to generate a set of differences between two virtual-doms and apply those > differences to the real dom without ever reading anything from the real dom > (as that is very slow). > > It would indeed be preferable for checked-state to be controlled > exclusively via the model and view, however only an event is sent for those > changes and there is no way for the vdom to update its internal information > otherwise, and registering an event everywhere, even bubbled events, would > again make the vdom very slow and force the user to have to handle a lot of > extra cases (imagine checked state, text values, even focus and all being > controlled like this). > > > On Tuesday, October 11, 2016 at 11:01:57 AM UTC-6, Max Froumentin wrote: >> >> Hi there, >> >> Today I raised https://github.com/elm-lang/virtual-dom/issues/37 >> Given there's no consensus on whether it's a bug, I'm bringing the >> discussion here. >> >> The reason why I think it's a bug is that the second time the view >> function runs it generates a ticked checkbox, although nowhere in the view >> function is there any indication that a ticked checkbox should be generated. >> >> The alternative view is that the checkbox that's been clicked on has only >> been mutated with new data. That's why it remains ticked. You need to use >> Html.Keyed to tell elm that it is an entirely new checkbox. >> >> I must say I'm not convinced why the view function should generate Html >> that depends on the previous state of the model. >> >> Thanks for any insight. >> >> -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
