Impressive, even if it does not - at first sight - feel like it addresses my issue (as I have no lazy code)
On Saturday, 31 December 2016 21:21:09 UTC+1, Mark Hamburg wrote: > > Tracked down and reported against the virtual DOM but the short summary > for anyone else seeing routing problems — though possibly not the ones that > started this thread — is that DOM updates have trouble if you have a lazy > node that resolves to an Html.map node. Don't do that. At least until > there's a fix. If you want to be lazy, stick a div in or avoid the map by > pushing the tagger function further down. > > Mark > > On Dec 14, 2016, at 10:23 PM, Mark Hamburg <[email protected] > <javascript:>> wrote: > > I'm looking at a bug tonight that looks very much like a tagger got > dropped in processing messages coming up the HTML tree. This is with > various bits of Html.Keyed paranoia. I'm thinking more and more strongly > that there are bugs in the tagging logic in the virtual DOM. I guess I know > what I'm hunting for over Christmas... > > Mark > > On Wed, Dec 14, 2016 at 7:17 AM, Mark Hamburg <[email protected] > <javascript:>> wrote: > >> I was dealing with a case where a textfield from a login screen would >> blur after the screen had been removed and replaced by the main content. >> (Literally. I was looking at the new content.) The blur message would get >> tagged as headed for the content area which would then lead to a crash when >> the message wasn't understood. >> >> My fix was to put an Html.Keyed at the top of the tree to reflect what >> state the app was in. (And then in a bit of paranoia, I looked for other, >> similar places further down and added Html.Keyed protection there as well.) >> >> Mark >> >> On Dec 13, 2016, at 10:24 PM, Simon <[email protected] <javascript:>> >> wrote: >> >> Thanks, I suspected that keyed would be part of the solution. >> Any sense on whether I need to apply it only to the components being left >> (easy) with no need on those that the code is switching to (much leasy in >> my case)? >> >> >> On Wednesday, 14 December 2016 03:55:29 UTC+1, Mark Hamburg wrote: >>> >>> I just dug into what I think is essentially the same bug. My guess was >>> that textfields were getting removed from the DOM and then firing their >>> blur events up through the event mapping chain — which had been updated to >>> match the new view tree structure. It's on my list to try to build a small >>> example of the bug after my team gets through its next milestone. >>> >>> In the meantime, I worked around this by making fairly aggressive use of >>> Html.Keyed to prevent pieces of the DOM from being reused. >>> >>> Mark >>> >>> On Dec 13, 2016, at 9:56 AM, Simon <[email protected]> wrote: >>> >>> Sorry about using the C word! >>> >>> I had an error several months ago (0.16/0.17) where the wrong data would >>> be attached to message, causing all sorts of weirdness. It happened after a >>> successful logon and as the App tried to redirect to the main view. I have >>> a vague feeling that in the end all I needed to do was update >>> elm-lang/virtual-dom. >>> >>> Anyway, it has come back. It has something to do with when the browser >>> puts in login information for you. I can create the error by deleting the >>> auto-input and inserting my password and clicking enter to submit. >>> >>> Then what I see in my logs is this message >>> >>> `User.SwitchGroup: Blur "password"` >>> >>> Whereas SwitchGroup has type `String -> Msg` and `Blur "password"` are >>> artefacts of the elm-form library that was used in the Login component and >>> is not used in the User one. >>> >>> Does this remind anyone of something they have experienced, solved, and >>> remembered how they solved it? >>> >>> -- >>> 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. >>> >>> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> >> > -- 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.
