Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

@joshgillies
Copy link
Contributor

@joshgillies 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
Copy link
Contributor

@sourcegr sourcegr commented 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.

@joshgillies
Copy link
Contributor Author

@joshgillies 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
Copy link
Contributor

@sourcegr 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.