If you haven’t seen it yet, please take a look at ember-concurrency. As the tagline says:
ember-concurrency is an Ember Addon that enables you to write concise, worry-free, cancelable, restartable, asynchronous tasks.
From the tagline alone, it might not sound all that compelling, but trust me, it really strikes at the root of so many problems (some you didn’t even know you had) when it comes to managing asynchronous/concurrent code in Ember with only promises/callbacks at your disposal.
At this point, there’s quite a bit of documentation that’s been produced, as well as a collection of examples of day-to-day use cases, so be sure to give those a look. If anything is unclear, please let me know here or open an issue on the GitHub repo. In the meantime, here is a (brief) list of problems / use cases that ember-concurrency solves:
Never write an
if(this.isDestroyed)check ever again -> instead, use a Task, which gets automatically canceled when the object it lives on is destroyed
- Never explicitly cancel a timer ever again -> instead, use
yield timeout(ms)in a Task, and let the timer be canceled automatically when the task is canceled
- Never worry if some asynchronous operation is going to cause problems if/when it continues running after the component that initiated it is unrendered -> if you’ve implemented the operation as a Task, it’ll be canceled when the component is unrendered
- Never have to set/unset your own
isRunningflags that wrap an async action/operation ever again so that buttons in your template can show up as disabled/unclickable -> just use the
isRunningflags on the task object
- Never write an
if()statement in an action that returns early if the async process it’s supposed to start is already running -> use a Task Modifier to annotate how to prevent unwanted concurrency
- Never write your own half-baked implementation of cancelable promises -> chances are what you’re trying to do can be expressed via a Task, which is cancelable, while still adhering to the Promise .then()-able interface
- Never build your own bespoke artisanal async queue of operations using an un-cancelable chain of promises -> use the .enqueue() Task Modifier
…and a ton a more.
Please try it out in your apps. There may be some churn in the API in the coming weeks, but at this point, I don’t foresee any major breaking changes, and based on the feedback I’ve received so far from some early adopters, you won’t regret giving it a try.
And whether you love it or hate it, please let me know how your experience with ember-concurrency is and how I can make it even better (or the documentation more clear).