Specifically the server sent a list of records over websocket one at a time (at times a *lot* of records), those were stored pretty much verbatim in the model. I had a field on the model that was just an Int, started at 0, the view rendered the list of those records (just one part of the interface, though the largest, and just read-only) behind a lazy call that was just passed that integer, so the first render rendered it empty (technically a 'loading' indicator if the integer was 0) and I received the records from the server until it stopped, once I got the last record then I just incremented it to 1 (I put it behind another message so I could just send that one message from anywhere to update that view). Any time the server pushed a record update (remove/add/etc..) then I just kept incrementing the integer. It was a perfectly suited method for my use-case, though it would be harder to do if it handled any user inputs and such (though still doable).
I had a similar setup in another elm app later but instead of using lazy I made my ProgramEx library, which added a `filter` callback so that I can just outright turn off view updating entirely for certain messages (as well as transforming messages, update other TEA things, etc..., filter was useful) and I just never ended up using lazy as keyed was perfect enough for most efficiency reasons (lazy could still be useful if the list got utterly huge though, but not for the new case). On Tuesday, October 11, 2016 at 11:52:35 AM UTC-6, Mark Hamburg wrote: > > 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 <overm...@gmail.com <javascript:>> > 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...@googlegroups.com <javascript:>. > 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.
