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 <mhamb...@gmail.com > <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 <mhamb...@gmail.com > <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 <hotb...@gmail.com <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 <hotb...@gmail.com> 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 elm-discuss...@googlegroups.com. >>> 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 elm-discuss...@googlegroups.com <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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
