Ember.js philosophy

Recently, there is a trend on the web to “thinning” the server and “thickening” the client. Every day vacancies Full-stack of developers is becoming more and more, and the net backend is less. For the last 2 years I have been working as a Ruby on Rails developer, and in the near future I would not like to remain without work. Therefore, I began to consider options for studying the client framework.

There were several options:

• Meteor
• Angular
• Ember

But there must be only one left. Meteor offers an interesting concept - a common client and server code, but it’s still raw and I don’t want to leave the wonderful Ruby language. Therefore, the Meteor has disappeared. Since Ember was similar to Rails (magic, convention over configuration), it was he who was chosen. In addition, the Handlebars template engine looked very nice compared to Angular directives.
')
The choice is made. That's where the problems started.

The manual is written very well, everything is done well, but when you start to do something yourself, there are constant questions. The main problem I had was that I did not see the whole picture, did not understand the architecture. There are few articles on this topic, and those that exist tell about the most basic concepts, therefore this note appeared.

Ember is called the MVC framework, so I expected to see something similar to Ruby on Rails and classic MVC. But it was not there! In addition to the model, view and controller (which do very different things than on the server), there were a lot of different things: components, routes, adapters, serializers, templates, storage.

The entrance threshold is high and it was quite difficult to put all this together in your head, to understand what it interacts with. That is why I want to share with you a small Ember scheme, it describes the work of the components, their interaction. I hope she will help you with an understanding of what is happening in the application, its study and faster and easier entry than it was with me.

Request Life Path

Consider the scheme in more detail.

Point of entry

We have a one-page application, so we have one entry point - index.html . All transitions will be done using an anchor or history api. All paths will be working, that is, you can easily add the desired page to the bookmarks and the content will be available on it.

Router

First of all Router works for us. It is he who chooses what to do next, depending on the address, and transfers control to the route specified in it.

Route

Route processes incoming data, such as url parameters, and accesses models or models. It is the link between the data (Model) and their handler (Controller).

Model

Models are our entities, for example in a blog - post, user, comment. Here not pure Ember is already used, but its complement is Data.
In order to obtain the specified objects there are 2 options:

1. Get them using the API.
2. Get from local storage where data was added during a previous API request.

When working with the storage, everything is simple - the data there is already in the form of objects and when requested comes from there, but 2 more entities are used to work with the API: adapters and serializers.

1. Adapters set the rules for working with the API, for example, to get all posts - GET / posts, and update the post - PUT / posts / 1.
2. The serializers parse the server's json response and set the json request format.

Controller

When we receive the data, we can proceed to processing it. It is in the controller that the computed properties are described. Controllers are of several types:

1. Controller is a regular controller, for example for static pages.
2. ObjectController - to represent a single object.
3. ArrayController - to represent an array of objects, it can still have an embedded ObjectController for each object (for example, for the calculated properties of each object) [1]

Representation

After that it is necessary to draw our data. This is where templates, views, and components come to the rescue. Let's first talk about templates - sections of html code into which our data is inserted. They may contain partials, components, and views.

Now let's talk about views and components. Components are descendants of representations, therefore both that, and the second are repeatable code locations. In connection with the imminent transition to version 2.0 [2], we are advised to use only components.

Components are complete sections of code that are responsible for one function and will be used in different places. Take an example from life: it was necessary for me that the long text automatically collapsed and the Expand button appeared. That's what I used the components for.

Partials are the same templates that are inserted into other templates, all of which apply to them in the same way.

Actions / Events

Now it is necessary to tell a little about actions and action bubbling - a chain of actions.
Actions - what happens when certain events (clicking on an element, sending a form). They are described in controllers, routes, views, components.
Consider a small section of code:

// index.hbs <h1 {{action 'doSomething'}}>{{post.title}}</h1> 

 // index-controller.js App.IndexController = Ember.Controller.extend({ actions: { doSomething: function() { console.log('     ') } } }) 

When you click on the header, this event will be transmitted to the corresponding controller and processed there - in this case, it will display an inscription in the browser console.

Action bubbling

Action bubbling is the transmission of an event up the chain if no handler was found in the route / controller.
Let us have such routes, controllers and views:

 // post-route.js App.PostsRoute = Ember.Route.extend({ actions: { doSomething: function() { // 1 } } }) // posts-controller.js App.PostsController = Ember.ArrayController.extend({ itemController: 'post' actions: { doSomething: function() { // 2 } } }) // post-controller.js App.PostController = Ember.ObjectController.extend({ actions: { doSomething: function() { // 1 } } }) 

 // posts.hbs {{#each post in controller}} <h1 {{action 'doSomething'}}>{{post.title}}</h1> {{/each}} 

When clicking on the name of the post, the nearest action will be performed - i.e. in PostController, if it doesn’t exist, it goes to a higher level, and so on.

Here is the same scheme:



Something like this in general terms looks like the life cycle of a single query in the Ember application, and I hope it will help you with understanding the architecture and starting to learn this wonderful framework.

PS: If it will be interesting, in the next article I will talk about writing an application on EmberJS, integration with Ruby on Rails, additional packages and Ember CLI.