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
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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.