How the resolver is used
The resolver is used widely throughout an Ember application. It is used to lookup routes, models, components and much more.
When your Ember app transitions into a route, the resolver is used to find the corresponding route module.
For example: if you navigate to
/blog, then the blog route needs to be looked up.
This is done by asking the resolver to resolve
route:blog, this will resolve a module named
blog of type
After the route is done loading the model, we need a controller, so we ask the resolver for
Lastly a template needs to be rendered, so once again we go to the resolver and ask for
The same thing happens when rendering a component. First the resolver is asked for
The rules of the resolver
Today the resolver is used the most to resolve modules using Ember CLI’s AMD module system. So I’m going to use that in the next few examples.
First of all, a resolver requires a
This variable is found in the
config/environment file of an Ember CLI app and is being passed to the resolver by your Ember application.
You should also know that the
app/routes/blog.js file in your Ember CLI app gets a different path in the compiled output.
app part of the path is replaced by the
modulePrefix variable. So our example would become
my-app/routes/blog if our
modulePrefix variable is
Dissecting a resolver statement
The resolver disects the statement
route:blog into two parts, a type (
route) and a name (
blog). Those parts are then translated into a path which can be used to load a module.
In the case of Ember CLI’s AMD modules it would give you
my-app/routes/blog, which is constructed of
type (pluralized) /
The resolver can also easily resolve things nested inside subfolders.
template:component/my-component, it’ll be resolved to
You can also make up your own type, it doesn’t have to be one of Ember’s types.
For example, Ember Validations uses the resolver to look up modules of the
Resolving addon modules
The resolver has one more trick up its sleeve, it can resolve things outside of your app using a custom
If you prefix the statement asked to the resolver with your custom
modulePrefix and an
@, then it’ll replace the configured
modulePrefix with yours.
an-addon@component:x-utility would be resolved to
The resolver has some exceptions built in, to resolve a few special things.
main as the name part will resolve without the name in the resulting module name.
router:main will resolve to
my-app/router, leaving out the name part. The same rule applies to
The resolver is a fairly straightforward abstraction that helps you resolve modules, agnostic from all the various module loading systems. If you get to know how it works it can be a great new tool in your arsenal.