On Thursday, February 9, 2017 at 1:07:27 AM UTC+9, OvermindDL1 wrote:
>
> It is not strictly be design (that might be a bug if you can come up with 
> a simple descriptive example that we can copy into elm-try or so), but it 
> is easy to work-around.
>

Did you try my gist? I updated it to make it easier to work with elm-try. 
https://gist.github.com/Shump/bd778bde23af0dd3f8c95f92ec45fc33 If you run 
each of them and enable "Paint Flashing" in chrome's devtools (open console 
-> click "three dots" option menu -> click "Rendering" -> check 
"Paint Flashing"), you'll see that the version with *use* tags repaints the 
whole board (bad performance), and the one using "normal" shapes only 
repaints the hovering tile (good performance).
 

> What I do is make just an integer (some primitive value), and just 
> increment it whenever the view should be updated (gotta be careful to catch 
> all cases though), then use that as the key in a `lazy` call that then 
> wraps the rest of the view, that way the view only updates when the integer 
> key is incremented (I wrap it around at 2 billion just-in-case that ever is 
> hit).
>
> However that makes the diff compare only the key before checking 
> everything else, and if the key integer is unchanged then the entire view 
> is skipped for diffing, thus making it very fast.  :-)
>
> You can add more keys and more lazy's for sections of the board as well if 
> you need to get more fine grained.  Just always try to use a primitive as 
> the key or a record that is passed verbatim from model update to model 
> update.
>

I feel like it shouldn't be necessary to look into adding keys for 
performant rendering with *use* tags when it is not needed for "normal" 
shapes... This is why I'm wondering if this might be a bug... or if it 
turns out that this is intentional, and *use* tags are performance killers, 
it should probably be mentioned in the documentation...

I'm sorry if this wasn't clear in my original post... I hope this makes 
things clearer.

-- 
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.

Reply via email to