Interesting. I can understand using a sentinel to force re-rendering but I'm curious as to how your model or view was structured such that it could inhibit re-rendering via laziness.
Mark > On Oct 11, 2016, at 8:42 AM, OvermindDL1 <[email protected]> wrote: > > 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. -- 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.
