Eh, not really, it is precisely the same issues as you would have with, for
example, React, or any of the other JS libraries that use virtual-doms.
Just an aspect of how web browser DOM's are made due to backwards
compatibility with a lot of old sites over a period of many many decades.
Have to know about the platform that is being programmed for is all, this
is not Elm specific. :-)
Remember, it is just a diffing algorithm, when it gets to that point of
your vdom and it compares an old vdom node of, for example:
```
checkbox [ onClick (CheckToggle 42) ] [ text "Something" ]
```
and compares it to the new of:
```
checkbox [ onClick (CheckToggle 43) ] [ text "Another thing" ]
```
It sees that there are two changes (well potentially 1 due to lack of keyed
event handlers, but we'll say 2 for this example), thus it accesses the
checkbox at the index that it is at here (say, 14 or so) by just something
like `var node = curNode.children[14];` then just applies the two changes
`node.removeEventHandler("click",
oldEvent); node.addEventHandler("click", newEvent);
node.children[0].nodeValue = "Another thing";`, which was just removing the
old event handler, adding the new, and mutating the text. Notice that it
did not set the checked value because you never said what the checked value
should be (thus meaning there was no difference in your defined checked
state, thus it just leaves it at whatever it was since it sees no change to
apply).
By making it keyed then it is like "oh, these do not match at all, probably
a major structural change, kill the old, create the new".
If instead it did, as you imply, the deleting of the checkbox and
recreating it so it has a consistent state regardless, then that would be
an absolutely monstrous amount of DOM manipulating for, say, just a tiny
text change, thus entirely defeating the point of a differencing system
like a virtual dom (of which the sole purpose of is for speed), while also
causing things like the checkbox to uncheck any time anything near its
point on the DOM changed even by a single character in a text node. :-)
If, however, you defined what the checked state should be in the vdom, then
it would see that the old was checked, and the new was not, and would
remove that property of it. :-)
And as for cocoa, unlike the DOM anytime something like, say a checkbox is
checked, cocoa sends a message to the application to handle the change, if
unhandled then no update would happen... and the app would be frozen as the
event loop would not be processing, unlike the DOM in a browser that would
just keep on puttering along even if no handlers for any events were
registered in javascript at all. They are entirely different programming
domains.
Some setups, like Angular 1, used two-way binding to overcome these issues,
so the DOM could be reflected back in to the data model, however that is
both hard to model and incurs significant speed hits based on access
patterns (hence why Angular 2 got rid of it as I recall, though not messed
with it to know for sure).
On Tuesday, October 11, 2016 at 1:33:38 PM UTC-6, Mark Hamburg wrote:
>
> 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 <overm...@gmail.com
> <javascript:>> 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...@googlegroups.com <javascript:>.
> 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.
