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

Batched updates #81

Closed
anandthakker opened this issue Jun 24, 2016 · 5 comments
Closed

Batched updates #81

anandthakker opened this issue Jun 24, 2016 · 5 comments

Comments

@anandthakker
Copy link

Depending on the store/action design of an app, batching updates can be a pretty useful/important perf optimization. @yoshuawuyts what are you thoughts on the best choo-like way to handle this? Would you be interested in adding a hook that would make this possible in some app-wide way (like maybe a way to provide 'middleware' function through which updated states were passed before being emitted to the view-rendering)? Or would you prefer for people to handle this by simply throttling individual view functions?

@yoshuawuyts
Copy link
Member

yoshuawuyts commented Jun 24, 2016

Ooh, yeah I've been considering this; combined with documenting best practices on thunking views and caching routes (yoshuawuyts/sheet-router#17) it would def be worthwhile to put an upper cap on flushing updates.

In the past for virtual-dom applications I used yoshuawuyts/virtual-raf to flush updates at 60fps; it could def be worthwhile exploring this for choo too - especially the interaction with webworker rendering would become interesting (max-mapper/yo-yo#22).

I think this should happen after the 3.0 release though; as it's a minor tweak without practical API changes. Does this answer what you meant? Cheers!

@yoshuawuyts
Copy link
Member

Created https://github.com/yoshuawuyts/nanoraf yest; might add this. Talked about this on IRC, and considered not doing batched updates; but realized yesterday that sometimes something like a higher order effect might trigger a whole slew of updates in rapid succession because stores are separated - there'd be no way of throttling that so we should prob def do this. If not today, then soon ✨

@yoshuawuyts
Copy link
Member

Created a new branch: https://github.com/yoshuawuyts/choo/tree/raf which uses nanoraf - it's based off the 3.0 branch and adds full batched updates.

This won't be part of 3.0 however as we probably need to test it a little, and I'd rather put out 3.0 before then - but it's non-breaking so can de make it 3.1 or smth ✨ Only difference that occurs is that older (<IE10) browsers will need a shim. I don't think that's bad enough to call a breaking change as it will realistically affect less than 1% of browsers out there, probably less for this lil choo thing we got here.

Anway, it can be played with now; keen to hear your thoughts on it.

@anandthakker
Copy link
Author

@yoshuawuyts I haven't given it an actual test drive, but from a read of the code the approach looks great to me! I have a couple of thoughts but I'll post them as issues over in nanoraf.

@yoshuawuyts
Copy link
Member

yoshuawuyts commented Jul 31, 2016

This was merged in 3.0.0 - seems to be working excellently 🎉 - thanks for suggesting it @anandthakker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants