Further review of the virtual DOM code — without fully understanding the structures it uses — suggests that it has the capacity to update tagger functions. In general, this would be good because it would avoid destroying and recreating nodes. It would set up exactly the sort of problem I am seeing, however, if it ever replaced a tagger with another tagger with a different type signature.
Mark On Wed, Dec 7, 2016 at 10:17 AM, Mark Hamburg <[email protected]> wrote: > Reading through the virtual DOM implementation, am I correct that when an > element goes away, it simply calls removeChild to take it out of the > physical DOM but does not remove any of its listeners? If that is the case > and if that removal could then lead to the text field generating a blur > event, then I could imagine a scenario where the event node tree gets > updated with new taggers when we switch views and these get used to tag the > message coming from the event handler still listening for blur events on > the removed node. Does this sound credible to anyone else who knows the > code or am I pursuing the wrong path? > > Mark > > P.S. If I'm right about this, the fix for my code is to use Html.Keyed > more so that there's less patching and more new nodes when things change > but this strikes me as a generally dangerous situation in Elm's > implementation. > > On Wed, Dec 7, 2016 at 9:56 AM, Mark Hamburg <[email protected]> > wrote: > >> I haven't got this narrowed down enough yet to produce a small, isolated >> case — or to diagnose what's happening — but I wanted to see whether this >> rings a bell with anyone before I dig further. >> >> In Elm 0.18 using Michael Combs's update to the MDL package, I'm using >> MDL text fields in a view via the TEA support rather than via Parts. (I >> don't know that that's an issue but it seemed worth calling out.) If I >> dismiss the view by hitting return while a textfield is active, I see the >> following things happen: >> >> 1. The model switches to the next state. It fires up a new view using its >> own version of MDL (parts based this time). That gets displayed and >> everything appears in order. >> >> 2. The blur message for the text field from the old view now comes >> through and gets tagged with the route for the new view tree. >> >> 3. That tagged blur message gets delivered to the update logic for the >> new view and we end up crashing with a JavaScript TypeError. >> >> There is no native code in the MDL libraries, so this is the stock Elm >> 0.18 implementation crashing with a "Not A Function" type error. >> >> My wild guess is that the old text field had a handler attached for the >> blur event which dispatched the message in question and that then rose up >> through the DOM even though the text field should actually be gone from the >> DOM. That then resulted in it passing through a tagger node which tagged it >> for the new state of the tree. But that's just a theory. >> >> Has anyone seen anything like this before? Does anyone have any better >> theories? >> >> Thanks. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
