Ember 1.12.0 instance initializer: deferReadiness method does not exist

I think it is smart to post @tomdale's explanation here as an answer.

@tomdale : "It is not possible to defer the readiness of the application in the instance initializer, as by definition the instance initializers only start after the application has finished loading.

Sidebar in App Load Semantics: "App Appiness" (as in, deferReadiness(

) and advanceReadiness()

) refers to whether all the code for the app is loaded. After all the code has been loaded, a new instance is created which is your application.

To recap, the lifecycle of an Ember app running in a browser is:

• Ember is loading.
• You are creating an instance of Ember.Application global (for example, Application).
• At the moment, none of your classes have been loaded yet.

• As you evaluate your JavaScript file, you register classes with (for example App.MyController = Ember.Controller.extend(…);
  
  )

• Ember waits for the DOM to be ready to ensure that all your JavaScript is tagged <script>
  
  .

• The initializers are run .
• If you need to lazily load code or wait for additional customization, you can call . deferReadiness()
  
  
• Once everything is loaded, you can call . advanceReadiness()
  
  
• At this moment we say that it Application
  
  is ready; in other words, we told Amber that all the classes (components, routes, controllers, etc.) that make up the application are loaded.
• A new instance of the application is created and the instance initializers are started .
• Routing begins and the user interface is displayed on the screen.

If you want to delay showing the interface because you need to do some runtime customization (for example, you want to open a WebSocket before launching the application), the correct solution is to use beforeModel/model/afterModel

hooks in ApplicationRoute

. All of these hooks allow you to return a promise that will prevent children from evaluating routes until they are resolved.

Using deferReadiness()

in an initializer is a poor hack that many rely on. I call this a hack because, unlike the model promise chaining in the router, it breaks things like errors and substation loading. By blocking rendering in initializers, IMO you create a worse experience for users because they won't see the loading load or errors if the promise is slow or rejected, and most of the code I've seen has no error handling code at all. This leads to applications that can only break with a blank white screen and not show the user that something bad has happened. "

See also discussion: https://github.com/emberjs/ember.js/issues/11247