- file names
- directory names
- html tags/ember components
- CSS classes
When using Ember CLI it’s important to keep in mind that the Resolver changes some of the naming conventions you would typically use out of the box with Ember, Ember Data and Handlebars. In this section we review some of these naming conventions.
And if it’s a nested controller, we can declare nested/child controllers
instance-initializers are loaded automatically.
Nested routes as such:
And views, which can be referenced in sub-directories, but have no inheritance.
It is important to keep in mind that the Resolver uses filenames to create the associations correctly. This helps you by not having to namespace everything yourself. But there are a couple of things you should know.
All filenames should be lowercased
Dasherized file and directory names are required
If you prefer to nest your files to better manage your application, you can easily do so.
You cannot use paths containing slashes in your templates because Handlebars will translate them back to dots. Simply create an alias like this:
Test filenames should be suffixed with
-test.js in order to run.
As your app gets bigger, a feature-driven structure may be better. Splitting your application by functionality/resource would give you more power and control to scale and maintain it. As a default, if the file is not found on the POD structure, the Resolver will look it up within the normal structure.
In this case, you should name the file as its functionality. Given a resource
Users, the directory structure would be:
Rather than hold your resource directories on the root of your app you can define a POD path using the attribute
podModulePrefix within your environment configs. The POD path should use the following format:
Then your directory structure would be: