Ember-runloop-utils NPM

Ember-runloop-utils

Observers are hard to use, when possible we should avoid them see: this video if you are curious how.

Now sometimes, observers are required (but rarely):

pushing change information away from ember (to d3, or jQuery or similar)
thats more or less it

Unfortunately, even in this scenarios it can be quite tricky to write them correctly.

Common Requirements (tricky to implement):

schedule on the run-loop
should fire once per run-loop queue flush
should not fire if the object is isDestroyed or isDestroying
sometimes should not fire if the object is no longer inDOM

Solution:

This library provides several helpers which aim to address the above issue. The goal is to have a shared, well tested implemention of onceObserver and inDomObserver macros.

// For the DOM observer use-case
import inDOMObserver from 'ember-runloop-utils/in-dom-observer'
import Component from 'ember/component'

export default Component.extend({
  dataDidChange: inDOMObserver('data.[]', function() {
    // safely and efficiently invoke your wonderful D3 code
  })
})

// For crappy reasons non inDOM use-cases
import inDOMObserver from 'ember-runloop-utils/in-dom-observer'
import Component from 'ember/component'

export default Service.extend({
  dataDidChange: onceObserver('data.[]', function() {
    // for some unknown and most likely poor reason create an observer that only flushes once per run-loop flush
    // in well factored code, this should essentially never happen instead:
    //  * use actions + invoke explicit methods
    //  * use computed properties
    // Why is stef so emo about this? go watch -> https://www.youtube.com/watch?v=vvZEddrClAQ
  })
});