No, I have a couple of ports that handle things like monitoring text selection in input fields, but that's about it. I think what's happening is that the differ is getting confused because of my use of a zipper data structure; when I traverse down the structure and then back up, it *should *be able to tell that the structure is unchanged, but it seems not to be able to do that. I need to investigate further to determine exactly what's going on.
On Friday, May 13, 2016 at 11:16:56 AM UTC-4, Janis Voigtländer wrote: > > Was your 0.16 code using Signal.forwardTo inside the view function? If > so, there’s a good chance that 0.17 will please you with much better > Html.lazy behavior. > > > 2016-05-13 16:19 GMT+02:00 Steve Schafer <[email protected] <javascript:>> > : > >> I *am* using Lazy, and in my specific 0.16 application (I haven't had a >> chance to update it to 0.17 yet), I haven't found the rendering >> optimizations to be all that smart. My view is a handful of Bootstrap >> accordion-style sections, with the inactive ones empty and the active one >> displaying a fairly large HTML table, typically twenty rows by twenty >> columns (think spreadsheet). A no-op update with *zero *changes to the >> model incurs about 200 ms of JavaScript processing time, essentially all of >> it in the virtual DOM diffing and rendering process, according to Chrome. >> There's no way that I can afford redundant updates that cost that much. >> >> You keep saying that the model needs to stop listening to subscriptions >> if it doesn't want to handle them, but there's no practical way to make >> that work for some of the scenarios that have been mentioned here. For >> example, say that your app wants to handle onKeyDown for just the up- and >> down-arrow keys, and ignore all other keys. How does one make that work, >> short of dropping out to JavaScript to create a custom event stream? >> >> >> On Thursday, May 12, 2016 at 11:21:46 AM UTC-4, Noah Hall wrote: >>> >>> > The problem is that update is not an ordinary function, as it has side >>> effects (rendering the view). If the view is complex, those side effects >>> can be computationally expensive, so you still need some way to minimize >>> redundant invocations of update. And it seems like the only practical way >>> to do that would be to somehow prevent no-op events from ever reaching >>> update. An alternative would be some sort of "escape clause" for update to >>> be able to say, "I didn't change the model at all, so don't update the >>> view." >>> >>> If you care a lot about this performance, then you should be using >>> either Html.Lazy or elm-lang/lazy. By default the renderer is already >>> very fast and very clever - this is how virtual-doms work, by >>> generating diffs and checking if they actually need to re-render or >>> not. If you want to not trigger things, then you need to use the model >>> to stop listening to that subscription. >>> >>> On Thu, May 12, 2016 at 5:03 PM, Peter Damoc <[email protected]> wrote: >>> > On Thu, May 12, 2016 at 5:54 PM, Janis Voigtländer >>> > <[email protected]> wrote: >>> >> >>> >> So, the suggestion is that that solution should be different, moving >>> the >>> >> if-then-else into the update-function (and not having NoOp on a >>> mapped Sub). >>> >> A potential problem I see with this is when there is more than one >>> >> update-function. Several components in a TEA setting, somehow >>> combined. >>> >> Couldn’t the new suggestion mean that one has to duplicate the >>> if-then-else >>> >> logic in several update-functions? >>> > >>> > Not in my understanding. >>> > In a TEA setting, the top most component could do all the processing >>> needed >>> > and pass to the children only the relevant information. >>> > This top level component could also use something like Lazy in the >>> view to >>> > optimize for "fake" updates. >>> > >>> > Basically, all the logic from around the subscriptions would end up in >>> the >>> > too most component. >>> > >>> > >>> > >>> > >>> > -- >>> > There is NO FATE, we are the creators. >>> > blog: http://damoc.ro/ >>> > >>> > -- >>> > 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] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
