Personally I've known it to help very little (keyed is usually more appropriate), but there have been a few times where it saves significant processing, but at those places I ended up setting it up with a 'sentry' value in a model (just an integer) that I incremented every time I wanted that lazy view to be re-rendered. This was highly useful when I was getting streamed a *ton* of data from a server over websocket that was being placed all kinds of randomly into a keyed list (see keyed!), but this was causing significant flickering and such until it was done, so I just basically 'turned off' the rendering with lazy via the sentinel until I got the last message. That kept the model flat and lets my finely control when I want the view to update. I've not heard of others using it like this yet and I'm unsure if it is well accepted, but I do not really use it for 'optimization' per-say (the vdom is really plenty fast, and again use keyed nodes when possible), but rather I used it as a better method of controlling when the view is actually updated.
On Tuesday, October 11, 2016 at 9:07:02 AM UTC-6, Mark Hamburg wrote: > > I was looking back at our first "big" (as in not the tiniest of toys) Elm > app and at its tendency to factor the model based on the view hierarchy. > This had struck me as a dubious pattern at the time and there is a strong > argument voiced by some that one should just stay flat as long as possible. > But why had we done it this way? Some of it certainly stemmed from the > emphasis in the TEA documentation at the time on how one can nest > model-update-view-message quads. But another part stemmed from wanting to > use Html.Lazy fairly aggressively. That desire also led to more logic that > tried to avoid generating new values when existing values would do. > > So, my question in retrospect is: How important is using Html.Lazy to > performance? Is it something one should put in at obvious break points > where there are expected to be large subtrees? Is it something that should > be used close to the leaves with the internal tree largely left non-lazy? > Is it something that you ignore until it seems like things aren't fast > enough and then start trying to contort your model and view to make lazy > work? > > My expectation from years of development is that on performance issues, > one shouldn't go putting in more complicated code for problems that aren't > yet known to exist — e.g., just sprinkling in laziness everywhere — but one > should plan for what one would do if performance became a problem — e.g., > if this were an issue, we could make it lazy right here. Lots of people > adhere to the first principle citing concerns over "premature optimization" > but the second principle tends to get less attention thereby leading to > "sand in the gears" that can never be adequately addressed. > > So, how import is lazy HTML and how does one best plan for its > introduction where it proves necessary? > > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
