Launch pad of an Ember App

5 min read • 15th May 2019
Rocket launch pad image

I'm sure most of you, Ember developers, would be aware of the ember new command and the scaffolding it generates for the application we want to build.

ember new sample-app

Great, now ember has done a lot of magic in getting us the file system laid out neatly making it very quick for anyone to start working. But, how many of us know what is the initial start point of an Ember app or the launch pad of an ember application? If you already know it, then I am sure you can exit this article from here on, otherwise go ahead and read on.


Let's run the default ember new sample-app command and see what it generates on the file system. So here it is:

Perfect, where does the sample-app start when we run ember serve. The highlighted sample-app/app/app.js could probably be. Let's check what that file contains.


Link to this sectionLet's analyse it line by line now

Link to this sectionThe Application Instance and it's .extend()

An instance of Application is the starting point for every Ember application. It helps to instantiate, initialize and coordinate the many objects that make up your app.

import Application from '@ember/application';

const App = Application.extend({
  modulePrefix: config.modulePrefix,
  podModulePrefix: config.podModulePrefix,
  Resolver
});

To know what an Application instance is, this is the best place to start with.
What the above lines of an app.js does is to simply instantiate the Application instance with project configurations.

  • modulePrefix: This is by default the app name that you specified during the ember new command. This is pulled in from config/environment.js.
  • podModulePrefix: If your project wishes to be under pod based folder structure, then this is added on config/environment.js.
  • Resolver: The most important part of an Ember app and this is discussed in the next step.

Link to this sectionember-resolver

The Ember Resolver is the mechanism responsible for looking up code in your application and converting its naming conventions into the actual classes, functions, and templates that Ember needs to resolve its dependencies, for example, what template to render for a given route.

import Resolver from 'ember-resolver';  
...  
App.extend({  
  ...  
  Resolver  
});  
...

ember-resolver is basically a system that helps the app resolve the lookup of JavaScript modules agnostic of what kind of module system is used, which can be AMD, CommonJS or just plain globals. It is used to lookup routes, models, components, templates, or anything that is used in your Ember app.
Simply put, the file path is resolved to modulePrefix/pluralise(type)/file-name.js. But it again depends on what the type is. To read in depth about what resolvers are and what they do, here's the best place to start. The best way to read in depth about what happens inside a resolver and how it works is by code, and here it is.


Link to this sectionember-load-initializers

import loadInitializers from 'ember-load-initializers';

...

loadInitializers(App, config.modulePrefix);

Refer: https://github.com/ember-cli/ember-load-initializers/blob/master/addon/index.js#L30.

This is a tiny addon that loads the initializers and instance-initializers during app boot. This addon iterates over files inside sample-app/app/initializers and sample-app/app/instance-initializers and invokes the app.initializer or app.instanceInitializer passing on the resolved name of the files. Here's the place to deeply understand the loadInitializer() method.

Link to this sectionInitializer

The goal of initializers should be to register dependencies and injections. This phase runs once. Because these initializers may load code, they are allowed to defer application readiness and advance it.

Link to this sectionInstance initializer

Instance initializers run after all initializers have run. Because instance initializers run after the app is fully set up, we have access to the store, container, and other items. However, these initializers run after code has loaded and are not allowed to defer readiness.


So, what happens next? How does the app load its routes, components, templates, controllers, and what not? I am sure you might have guessed it already, go ahead and drop in your inputs on the comments below. If this article needs tweaks, please do share them as well.

Enjoyed this article? Tweet it.

I guess you might be looking to add your comments? Glad to tell you that this section is under construction. But don't hold on to your thoughts! DM them to me on Twitter