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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
