Readers' Questions - "What's the difference between ember-lifeline and ember-concurrency and which one should be used?"

[chrisrng]

Hello once again to Readers’ Questions, presented by the Ember.js Times. Today I’m answering this question:

What’s the difference between ember-lifeline and ember-concurrency and which one should be used?

This week’s Readers’ Question refers to two different Ember addons that make working with async easier. Since single page applications are often long lived, scheduled asynchronous work needs to be managed and cleaned up when not in use (e.g, when transitioning to another route). If we don’t, we can end up with asynchronous calls attempting to act on already destroyed elements which can trigger errors and memory leaks.

ember-lifeline

The ember-lifeline addon introduces several functional utility methods to help manage async states by associating async behavior to object instances. Ember provides the run loop to schedule work and exposes an API that lifeline uses to override key lifecycle hooks and provides the necessary cleanup for you so that you don’t have to think about it. Lifeline also exposes a primitive, disposables, which allows lifeline to clean up any resources that are outside of Ember’s lifecycle.

ember-concurrency

The ember-concurrency addon uses generator functions to reduce the boilerplate code around maintaining concurrency while adding structure to async code by providing a Task primitive. It uses a declarative API to ensure that only one instance of an operation is running at a time by enforcing logical boundaries.

So which one should I use?

There is some overlap between the two (both have logic to run through a list of disposables/tasks), however each addon could be used independently or together to solve their respective challenges.

Further reading

To read more about each addon check out their respective repos:

• ember-lifeline
• ember-concurrency

[jessica]

Thank you for this great write-up! @chrisrng

[Bauke]

Ember-lifeline seems to be more focussed on making async operation to fall in line with the Ember runloop, where ember-concurrency has a better API for (derived) state.

I picked ember-concurrency to change the default render-blocking behaviour of the model hook. Returning an object containing tasks in the model hook allowed me to still use this.modelFor in nested routes. I then used the derived state to create a skeleton loading component that accepts tasks and exposes the final data to the block content that’s only rendered when all tasks are complete. Works like a charm!

[sukima]

Ember offers a vanilla solution (PromiseProxyMixin) and for cases that need more state management and cancellation (concurrency management) you have ember-concurrency.

I even wrote lengthy in depth blog posts about it: Two-Task Routes in Ember, Asynchronous Computed Properties in Ember