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