Fine grain control over tag updates by passing nextOpts to shouldUpdate #2238

Closed
joshgillies opened this Issue Jan 26, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@joshgillies
Contributor

joshgillies commented Jan 26, 2017

I'd like to offer this question up for discussion.

Since the introduction of shouldUpdate I've been using this extensively to control when tags in my app update. It's great! However, the more I use it the more I find myself wanting to assert previousOpts and nextOpts within a shouldUpdate function to gain super fine grained control over tag updates.

Looking through Riot.js source I can see where we call shouldUpdate and it's just before a tags nextOpts are calculated. As such the current implementation doesn't provide any meaningful way to assert whether based on changes to opts should a tag update.

My suggestion initially is to simply pass nextOpts as the optional second argument to shouldUpdate. But moving forward I wonder whether there's scope to internally track whether a tags opts have changed between render cycles, and simply short circuit a tags update if they haven't.

@sourcegr

This comment has been minimized.

Show comment
Hide comment
@sourcegr

sourcegr Jan 27, 2017

But moving forward I wonder whether there's scope to internally track whether a tags opts have changed between render cycles, and simply short circuit a tags update if they haven't

Please correct me if I am wrong, but many tags base their behaviour in many more than just the nextOpts... It could be a global variable, maybe a parent value or expression, maybe a store object etc. and it would be very common for some of these to change - so the tag should be updated!

But of cource your first suggestion is a very good - actually I think there was a discussion about such a feature.

But moving forward I wonder whether there's scope to internally track whether a tags opts have changed between render cycles, and simply short circuit a tags update if they haven't

Please correct me if I am wrong, but many tags base their behaviour in many more than just the nextOpts... It could be a global variable, maybe a parent value or expression, maybe a store object etc. and it would be very common for some of these to change - so the tag should be updated!

But of cource your first suggestion is a very good - actually I think there was a discussion about such a feature.

@joshgillies

This comment has been minimized.

Show comment
Hide comment
@joshgillies

joshgillies Jan 27, 2017

Contributor

@papas-source

many tags base their behaviour in many more than just the nextOpts... It could be a global variable, maybe a parent value or expression, maybe a store object etc.

Ah yes, good point, in these cases whether to update a tag should be controlled by the developer. 👍

actually I think there was a discussion about such a feature.

Do you happen to know which issue/pr this was being discussed against? The closest I could find was this comment from @cleytonb #2118 (comment)

Contributor

joshgillies commented Jan 27, 2017

@papas-source

many tags base their behaviour in many more than just the nextOpts... It could be a global variable, maybe a parent value or expression, maybe a store object etc.

Ah yes, good point, in these cases whether to update a tag should be controlled by the developer. 👍

actually I think there was a discussion about such a feature.

Do you happen to know which issue/pr this was being discussed against? The closest I could find was this comment from @cleytonb #2118 (comment)

@sourcegr

This comment has been minimized.

Show comment
Hide comment
@sourcegr

sourcegr Jan 27, 2017

probably that one...

sourcegr commented Jan 27, 2017

probably that one...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment