There's been a discussion of what it would take to support Web Components well in Elm and one of the primary issues that has come up has been problems with the virtual DOM not preserving component DOM elements during an update or preserving them when it should not. This matters because these are elements that often are being used because they keep state outside of Elm and spurious destruction/construction or reuse leads to state resetting when it shouldn't or being "preserved" when it shouldn't.
This problem, however, already exists for text fields which have notions of focus and selection which exist outside of Elm. The following gist demonstrates the problem. Typing into the field should capture all of the successive text strings. It works fine in Before mode in which the text field sits at the same spot in the virtual DOM throughout. But in After mode, every time you type, the text field moves in the DOM and gets destroyed and re-created. https://gist.github.com/markhamburg/874a2dc5e92d233415cbe9cbe0e8e5d6 Some cases, could be handled using Html.Keyed but this is really built for handling lists — imagine instead of the example I just provided one where we pop an error field into view ahead of the text entry — and in fact requires that concern be paid all the way up the tree — the error field might be several levels up from the text field in the view hierarchy. Basically, with care and attention, we can get the virtual DOM to do the right thing most of the time, but what we have is a lurking source of difficult to reproduce bugs where if the virtual DOM changes in the wrong way at the wrong time, the state for an element will get messed up. How could we fix this? This is where my limited knowledge of browser behavior and of what the key decisions are in the virtual DOM that lead to improved performance impairs my ability to say anything definitive. But essentially what it seems like we want is a return of an optional identity attribute for views that should be used on any view that involves external state. The virtual DOM update code should sweep through the old tree and collect up a map of identity strings to DOM elements and look in this map to find the right DOM element for any item in the new virtual DOM tree. Basically, the identity attribute means "preserve the external DOM element". Are there better solutions that don't just involve saying "avoid writing code like that" (though a solution that said "write code like this instead" would also be an option). 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.
