From 2b452c210b5a218609cca6cd3490b1ee3104194f Mon Sep 17 00:00:00 2001 From: Matthew Beale Date: Thu, 18 Jun 2015 16:43:13 -0400 Subject: [PATCH] Note that defer is not permitted in instance initializers --- source/blog/2015-05-13-ember-1-12-released.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/source/blog/2015-05-13-ember-1-12-released.md b/source/blog/2015-05-13-ember-1-12-released.md index 72ddfa82d4..d752071cec 100644 --- a/source/blog/2015-05-13-ember-1-12-released.md +++ b/source/blog/2015-05-13-ember-1-12-released.md @@ -144,11 +144,13 @@ In Ember.js 1.12 application boot is separated into two phases: * Application initializers run. At this phase of boot, the goal of initializers should be to register dependencies and injections. These initializers are doing work that is shared across all FastBoot requests, and therefore should not - create instances. This phase runs *once*. + create instances. This phase runs *once*. Because these initializers may + load code, they are allowed to defer application readiness and advance it. * Instance initializers run next. This is the right time to do work that is specific to each FastBoot request. You can create instances and modify their state here. This phase runs when the browser application runs, for each - integration test, and for each FastBoot request. + integration test, and for each FastBoot request. These initializers run + after code has loaded and are not allowed to defer readiness. The two-phase initialization process is safer when multiple addons may be registering factories and injections. @@ -159,9 +161,7 @@ Ember-CLI 0.2.3 supports instance initializers. For example: // app/instance-initializers/sleep.js export function initialize(application) { - application.deferReadiness(); - // Wait 3s before continuing to boot the app - Ember.run.later(application, 'advanceReadiness', 3000); + application.container.lookup('service:websocket').connect(); } export default {