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 <[email protected]> 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. -- 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.
