Function

next (target, method, args*) Object public

Module:	@ember/runloop

Defined in packages/ember-metal/lib/run_loop.js:473

import { next } from '@ember/runloop';

target

Object

target of method to invoke

method

Function|String

The method to invoke. If you pass a string it will be resolved on the target at the time the method is invoked.

args*

Object

Optional arguments to pass to the timeout.

returns

Object

Timer information for use in canceling, see `run.cancel`.

Schedules an item to run from within a separate run loop, after control has been returned to the system. This is equivalent to calling run.later with a wait time of 1ms.

import { next } from '@ember/runloop';

next(myContext, function() {
  // code to be executed in the next run loop,
  // which will be scheduled after the current one
});

Multiple operations scheduled with run.next will coalesce into the same later run loop, along with any other operations scheduled by run.later that expire right around the same time that run.next operations will fire.

Note that there are often alternatives to using run.next. For instance, if you'd like to schedule an operation to happen after all DOM element operations have completed within the current run loop, you can make use of the afterRender run loop queue (added by the ember-views package, along with the preceding render queue where all the DOM element operations happen).

Example:

import Component from '@ember/component';
import { scheduleOnce } from '@ember/runloop';

export Component.extend({
  didInsertElement() {
    this._super(...arguments);
    scheduleOnce('afterRender', this, 'processChildElements');
  },

  processChildElements() {
    // ... do something with component's child component
    // elements after they've finished rendering, which
    // can't be done within this component's
    // `didInsertElement` hook because that gets run
    // before the child elements have been added to the DOM.
  }
});

One benefit of the above approach compared to using run.next is that you will be able to perform DOM/CSS operations before unprocessed elements are rendered to the screen, which may prevent flickering or other artifacts caused by delaying processing until after rendering.

The other major benefit to the above approach is that run.next introduces an element of non-determinism, which can make things much harder to test, due to its reliance on setTimeout; it's much harder to guarantee the order of scheduled operations when they are scheduled outside of the current run loop, i.e. with run.next.