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 [email protected]. For more options, visit https://groups.google.com/d/optout.
