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] <javascript:>>
> :
>
>> 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] <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.
