I haven't yet dug into the actual example code, but this response goes straight to the issue of continuity of identity that makes things like web components an interesting problem for a functional virtual DOM.
Mark P.S. I prototyped a system a few years ago on Cocoa in which view creation was explicit — thereby providing identity — but property updates after creation all came from reactive signals. It worked pretty well but took more thought to use than does Elm's "just re-render the tree as you want it" approach. What we're seeing here is that without identity — or with erroneous identity — the diff the vdoms approach can have its own serious surprises. > On Oct 11, 2016, at 10:11 AM, OvermindDL1 <overmind...@gmail.com> 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 elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
