Per the discussion on the Html.Keyed thread, this problem can be addressed using Html.Keyed. In particular, here is a solution that adds an After with Keyed case that doesn't exhibit the problems of the After case:
https://gist.github.com/markhamburg/b17b6d0ecb19d73ab10f015f693c4a6b The basic lesson of this is that if the children of a node are dynamic rather than static and if any of those children or their further descendants have state that is outside of Elm's control, you want to build the node using Html.Keyed.node rather than using the somewhat simpler Html APIs (and you want to be careful to construct the keys so as to preserve identity correctly). Mark On Sun, Sep 25, 2016 at 12:34 PM, Mark Hamburg <mhamburg...@gmail.com> wrote: > 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.
