Ember CLI will create our folder structure for us. Ember.js uses the model-view-controller (MVC) pattern. You'll see in this recipe how the folder structure is laid out and how the model, controller, and view (templates) are separated from each other.
Ember CLI relies on ES2015 modules. This means that you can write code today using tomorrow's JavaScript syntax. This is accomplished via the Ember Resolver.
Tip
ES2015
ECMAScript 6, also known as ES2015, is the upcoming version of the ECMAScript programming language. ES2015 includes several new features, including template strings, destructuring, arrow functions, modules, and class definitions, to name a few. This is all available now within your Ember project.
An ember pod is a different type of structure that organizes your modules by feature instead of type. As your project grows, you may want to organize your project by feature to help keep things organized. The Ember Resolver will look for a pod structure first before it looks at the traditional structure.
To set up the pod structure automatically, you can edit the .ember-cli file in the root of your project directory and add this line:
{
"usePods": true
}Tip
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
This will set the default structure to always use pods. When using pods, it is a good idea to set the location where all pods live. To do this, you will need to edit the config/environment.js file:
...
var ENV = {
modulePrefix: 'pod-example',
.. podModulePrefix: 'pod-example/pods' The podModulePrefix property sets the POD path with the following format, {appname}/{poddir}. In the preceding example, the pod directory is now set to /pods in the app folder. If the location is not set, all new modules will be created in the app/ folder.
After a new project is created, a normal folder layout is generated. This layout consists of several different types of modules. Here is a short description of each directory:
|
Directory |
What it does |
|---|---|
|
|
Adapters help extend logic to communicate with a backend data store |
|
|
Components are used to help reuse code and must have a dash in their name |
|
|
Helpers are used for HTML reuse |
|
|
Initializers are run first and help set up your application |
|
|
This is a special type of Ember.Object used with multiple inheritance |
|
|
Routes help move through different application states |
|
|
This serializes your data model |
|
|
Transform is used to deserialize and serialize model attributes |
|
|
Utils are small utility classes |
|
|
Models hold the data store |
|
|
Templates use HTMLBars to display HTML to the user |
|
|
These are templates used in your components |
A new project app folder with a default layout will look similar to this:
Each module will have its own directory. For example, the templates folder will store all the templates while the components controller will store all the components.
Let's say that we added a new post resource using pods. The following command will generate a new post model, route, and template, and it will update the router:
$ ember g resource posts
Now the filesystem will look like this:
Pods sorts directories by features. The post and posts folders are features and the files are named after the function they serve.
The directory structure in each Ember CLI project is by design. When creating a new project or generating new scaffolding, the CLI will place files in a certain directory with a certain naming structure that the Ember Resolver understands using the ES2015 format.
The Ember Resolver is responsible for the looking up of code in your application and converting the name conventions in the actual class files. With Ember pods, the resolver knows to look there first before the default structure.