If you are even thinking about "deep down", you are not considering reference equality. Because reference equality, which lazy uses, simply compares that the two objects/records are at the same memory address. A question of "deep down" cannot arise.
> Am 17.05.2016 um 17:56 schrieb Steve Schafer <[email protected]>: > > Yes, I'm aware of that. The model should be equal, but there may be something > buried deep down that's causing a problem. I think it may have to do with > something that effectively looks like this: > > y = { x | a = x.a } > > While Elm thinks that x == y, JavaScript does not. I've tried to expunge all > of these, but there may be something lurking somewhere. And Elm doesn't make > it easy to figure out where such things may exist. > > >> On Tuesday, May 17, 2016 at 10:59:01 AM UTC-4, Janis Voigtländer wrote: >> You are aware that the functions from Html.Lazy use reference equality? So >> two models are only considered equal if they are the same JS object (at the >> the same pointer address). The zipper data structures I know don’t give that >> degree of equality after moving down and up again. >> >> >> 2016-05-17 15:43 GMT+02:00 Steve Schafer <[email protected]>: >>> 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]>: >>>>> 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]. >>>>> 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. > > -- > 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.
