More bluntly, yes, Html.Keyed gives you the desired stability but only if you use it for all nodes for which the sequence of children is not fixed that could have a web component descendent.
Mark On Friday, September 23, 2016, Mark Hamburg <[email protected]> wrote: > Keyed expects all of the siblings to be keyed. This means that if you use > one stateful (and since part of the point is that this is opaque, so you > should probably assume stateful) web component in a list of siblings, you > need to use keys keys on all of them. > > What's more that statefulness propagates up the tree. If you need to be > protected from accidentally re-creating views at one level, you need that > protection all the way up to the root. > > Each of these issues gets mitigated if the sequence of child views is > fixed but without attention to the issue it's a lurking source of spurious > bugs that the type system won't catch for you and that will instead require > intensive testing to protect against. > > Mark > > On Thursday, September 22, 2016, Richard Feldman < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> I'm confused - Keyed is explicitly the solution to this...what is >> insufficient about Keyed as a solution? >> >> On Thu, Sep 22, 2016 at 9:11 PM Mark Hamburg <[email protected]> >> wrote: >> >>> The issue is that when you have external state, there need to be ways — >>> features, patterns of coding, etc — that prevent accidental destruction of >>> one component accompanied by creation of a new component when what one >>> wanted was an update to the existing component. This depends on having a >>> notion of identity that the HTML support in Elm eschews except for the >>> keyed case. >>> >>> Mark >>> >>> >>> On Thursday, September 22, 2016, Richard Feldman < >>> [email protected]> wrote: >>> >>>> I'm not sure what you mean there - what part about the status quo >>>> regarding form elements doesn't seem sensible? >>>> >>>> On Thu, Sep 22, 2016, 8:43 PM Max Goldstein <[email protected]> >>>> wrote: >>>> >>>>> I really like Mark's summary, and I think Richard is incorrect to >>>>> dismiss the first point: >>>>> >>>>> 1. Make sure the virtual DOM works "sensibly" with elements with >>>>> hidden local state. >>>>> >>>>> Checkboxes, drop downs, and other form inputs are a root problem. >>>>> Maybe the solution is web components, but maybe not. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "Elm Discuss" group. >>>>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>>>> pic/elm-discuss/2RTddO_4rLw/unsubscribe. >>>>> To unsubscribe from this group and all its topics, 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]. >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Elm Discuss" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/to >>> pic/elm-discuss/2RTddO_4rLw/unsubscribe. >>> To unsubscribe from this group and all its topics, 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]. >> 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.
