Inject Code with Application Initializers

Published on Oct 07, 2015

Initializers are useful when you need code to run before starting up the rest of your app.

In today’s video we introduce initializers, and use an Application Initializer to inject code into a component.




import Ember from 'ember';
import Preloader from '../controllers/preloader';

export default {
  name: 'preloader',
  after: 'simple-auth',
  initialize(container, app){
    app.register('preloader:main', Preloader)
    app.inject('controller', 'preloader', 'preloader:main')
    app.inject('component', 'preloader', 'preloader:main')
//using the preloader in a component



Today we’re going to talk about initializers, specifically how to use application initializers to inject code into your application.

So initializers run before the rest of the application boots up, and there are two types of initializers. There are application initializers and instance initializers. Application initializers are what you’re used to, because they were introduced early in the 1.x series. Instance initializers were introduced in 1.12. And application initializers are more flexible, but instance initializers can save you a lot of time if you’re using testing or fastboot. We’ll go over more of the differences in this week’s pro-episode.

So the initializer has several properties, which we’ll be seeing in our example today. So it has the ‘initialize’ method, which is the only required one, and this method is the one that runs when the app is booting up. It has the ‘name’ which is useful for when you’re using the ‘before’ and ‘after’ methods. The ‘before’ and ‘after’ methods basically help you order how the initializers are run.

So this is our example initializer. Notice that the file’s in the initializers folder.

and that you just export default the hash, and that hash comes with three of the four arguments that we said, including the one that’s required.

So the name we’re giving it is preloader, and then we’re doing it after simple-auth. So simple-auth is another initializer that I have in this project. And so what we’re doing in the initialize function so it takes two arguments, initialize always gives you two arguments, container and app, and container is good if you want to do something like looking up the store. So you could do container.lookup(‘store:main’). So that would give you the store.

But we don’t need the store in this particular example.

So first we’re registering something onto the container, and we’re using app since that’s how we do it now. It used to be container that did that. And we’re putting in the preloader file. So the preloader class is coming from the controllers. It’s what used to be a service object. And then we’re injecting that into every controller and every component. And how we end up using that is, this is a component,

it’s being injected into a component, and then we can just get it because it’s a property on that component since it’s been injected in.

So to go back over that again, we’re registering the preloader class as preloader:main, and then we’re injecting it into the controller and the component. And we’re injecting preloader:main what got registered here, and then we’re injecting it as preloader. That’s what the second argument is.

And then later on in a component or a controller, we can just do this.get(‘preloader’),

and it’ll all access the same instance of preloader.

You can also specify where you want it put. So right now it’s putting on all components, but you could put it like this and it would put it on only the minigame-wrapper component.

Now this used to be a perfect use-case for initializers. But this exact use-case for loading something that you can access as a service, it has been overtaken by services which were released in ember-1.10.

So I’ll be covering those in an episode soon. But first in this week’s pro-episode, I’ll be covering instance initializers, how they differ from application initializers and how you can use them to load data.

I’ll see you then.

Subscribe to our mailing list