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:

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


On Sun, Sep 25, 2016 at 12:34 PM, Mark Hamburg <>

> 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.
> 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 
For more options, visit

Reply via email to