Re: [elm-discuss] Re: Html.Keyed

2016-10-15 Thread OvermindDL1
On Wednesday, October 12, 2016 at 5:32:09 AM UTC-6, Max Froumentin wrote: > > 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? > Yep, adding an attribute I

Re: Element continuity (was Re: [elm-discuss] Re: Html.Keyed)

2016-10-14 Thread Mark Hamburg
Actually, the existing documentation for Html.Keyed comes close to saying what needs to be said: > Works just like Html.node, but you add a unique identifier to each child > node. You want this when you have a list of nodes that is changing: adding > nodes, removing nodes, etc. In these cases,

Re: [elm-discuss] Re: Html.Keyed

2016-10-13 Thread 'Rupert Smith' via Elm Discuss
On Thursday, October 13, 2016 at 9:20:36 PM UTC+1, Rupert Smith wrote: > > On Tuesday, October 11, 2016 at 9:09:31 PM UTC+1, OvermindDL1 wrote: >> >> 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: >> ``` >> c

Re: [elm-discuss] Re: Html.Keyed

2016-10-13 Thread 'Rupert Smith' via Elm Discuss
On Tuesday, October 11, 2016 at 9:09:31 PM UTC+1, OvermindDL1 wrote: > > 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 i

Element continuity (was Re: [elm-discuss] Re: Html.Keyed)

2016-10-12 Thread Mark Hamburg
On Oct 11, 2016, at 1:09 PM, OvermindDL1 wrote: > > 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

[elm-discuss] Re: Html.Keyed

2016-10-12 Thread Max Froumentin
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 u

Re: [elm-discuss] Re: Html.Keyed

2016-10-11 Thread OvermindDL1
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

Re: [elm-discuss] Re: Html.Keyed

2016-10-11 Thread Mark Hamburg
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

[elm-discuss] Re: Html.Keyed

2016-10-11 Thread OvermindDL1
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 actua