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. Mark -- 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.
