On Oct 11, 2016, at 1:09 PM, OvermindDL1 <overmind...@gmail.com> 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 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.

Actually, no, with respect to Cocoa. If a Cocoa view sends out a message that 
the value changed, the controller is not required or even expected to echo that 
change back. The message can disappear into the aether and the state will 
remain. (Caveat: It's been a while since I've coded against the Cocoa APIs.) 
So, it is essentially an identical situation of there being extra state that is 
tied to the existence of a Cocoa view object or a DOM element.

The problem this poses for all render-and-diff-based virtual DOM systems — and 
you are correct that React shouldn't be immune — is that the diffing algorithm 
has to infer when to keep using an existing element and when to create a new 
element. The only truly reliable way around that would be to require attaching 
unique identifiers to rendered nodes that the diff algorithm to use to 
recognize continuity and that's messy in broader practice (though see below). 
That said, that's exactly what Html.Keyed does so if there is a problem here it 
isn't in Html.Keyed but rather in the documentation around how the virtual DOM 
relates to the physical DOM and how in particular that plays out for Html.Keyed.

What should perhaps be more worrisome is that the render-and-diff algorithm can 
produce different results depending on how often we render. Render frequently 
and maybe an element goes away and then a new element gets created. Render 
infrequently and maybe the existing element gets reused. Html.Keyed can be used 
to work around this by using a new key to force creation but again 
understanding that work around takes understanding the relationship between the 
virtual and physical DOM at a deeper level than the documentation for Elm (or 
React?) tends to cover. (For those who are a bit performance obsessed, 
Html.Keyed also has the annoyance of introducing an extra div element, but 
that's just a niggle.)

The work on web components touches on this issue as well. The point to using 
web components is often to allow them to encapsulate private state but then we 
need to manage the lifetime for that private state.

This really comes down to a question of managing when the DOM diff algorithm 
should consider two elements the same and when it shouldn't. As noted, we could 
simply require that all elements have unique ID's and continuity would be based 
on ID equality but then we would have the problem of managing a global ID 
space. Not wanting to go there, let's look at what we've got available:

* Normal nodes manage their children positionally. This should argue for 
treating such nodes as always having a fixed set of children and the DOM diff 
algorithm could complain when they don't noting that changing the set of 
children introduces risks that the diff algorithm will make the wrong choice or 
will miss a change by not running often enough. (There are also risks if 
children change their kind because if the change is seen it will result in 
element destruction and creation and if it is not seen because the kind changes 
back, it will likely result in element reuse.)

* Keyed nodes manage their children based on keys. These work well for identity 
provided one understands the implications of that identity. Keyed nodes can be 
used for lists but also for forced destruction and creation of DOM elements.

What seems like it bears some further investigation is looking at more ways to 
use keyed nodes to manage non-homogenous lists, changeable lists of sub-views.

Another interesting point to investigate would be debugging tools that compare 
the number of elements created and destroyed depending on how often the 
render-and-diff algorithm is run.


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.

Reply via email to