When is it important to use Ember.run?

Design
1

I’m trying to wrap my head around the meaning and best practice of Ember.run. The docs are useful in showing some ways to take advantage of the Ember.run.* helper methods, but I find it lacks information on the most basic usage of Ember.run.

I floated a stack overflow question about this which has not attracted interest: ember.js - Why should I use Ember.run() when handling events in other libraries? - Stack Overflow

My understanding of Ember.run is that it immediately runs the callback supplied to it, and then runs the RunLoop algorithm of flushing all the queues.

I’m trying to understand why you’d ever need to manually ensure the synchronization of bindings and firing of subsequent events. In my example, I’m handling a jQuery UI event by sending an action to a controller. As far as I can tell, wrapping this send within a call to Ember.run has no effect.

Within unit and integration tests, I have come across some cases where using Ember.run is helpful, namely when you expect things to happen immediately that would otherwise be deferred, such as appending a view to the DOM.

There must be some use cases for Ember.run that escape me. Could you folks shed some light on this topic?

2

I wrote about this early this week in Guide: When and how to handle asynchronous side-effects in testing?

My understanding of Ember.run is that it immediately runs the callback supplied to it, and then runs the RunLoop algorithm of flushing all the queues

The point of calling Ember.run is to allow the RunLoop to track all of the async calls and make sure that they’re executed completely. One caveat is that its possible to create a scenario where a function executed by Ember.run triggers a callback that runs after the RunLoop stops running.

In my scenario, the 3rd party library called setTimeout, which caused the original function to finish executing and triggered the start and finish of RunLoop before the setTimeout expired. As a result, the callback of the setTimeout executed outside of the RunLoop.

you expect things to happen immediately that would otherwise be deferred, such as appending a view to the DOM.

Its not being called immediately, it’s just handling the deferred side effect within the RunLoop.