Anatomy of Ember.js (part one, theoretical)

Ember.js difficult to learn. Although not even the case. Ember.js concepts are difficult to learn and understand. It seems to me that any Ember.js course of study should begin with these words.

I am a developer working with Ruby on Rails (before that I was programming in .NET and Python). For me it was quite problematic to understand the magic that makes Ember.js work. Sometimes I communicate with other novice developers who have embarked (or are trying to get up) on the Ember.js path - all their problems start because they do not understand how this framework works.

Yes, on the one hand there is official documentation in which all aspects of this framework are described in detail. But she lacks the concept; for a novice developer, these are just pieces of information scattered randomly. From the documentation, for example, you can find out what we have in the arsenal of controllers, models and types (controller, model, view). But in order to find out what they are responsible for and how the novice developer works, they first suggest stepping on a rake a couple of dozen times. Plus, the load to the controllers, models and views of Ember.js gives us a whole platoon of disparate objects such as components, templates, a router and paths (component, template, router, route).

But first things first. Let's start our Ember.js learning by remembering that this is not a MVC (model-view-controller) framework; forget it. Yes, in Ember.js there are controllers, models and types – templates, but this is where its similarity with MVC frameworks ends. Ember.js is a framework for writing applications running in the user's browser.
')
Take a look at the following diagram, it describes in detail the life cycle of a request in a standard application written in Ember.js:



The states of your application are described using the address that you specify in the address bar of your browser. Using the address, you can save the state of your application or even share the state with other users, for example, by sending a link to a specific task in your bug tracker (the application shows the task - this is its state).

So imagine that an application written in Ember.js receives information that the address in the address bar has been changed. The router intercepts this information and tries to figure out what to do next with it.

UFO (small lyrical digression): Ember.js works on two principles. Rules above configurations (convention over configuration) and if Ember.js does not find the expected object, then it creates it itself based on its internal rules. It is worth noting the way the code generator Ember.js works. Probably you are familiar with the generators in other frameworks: they create a file with a code and save it on your disk. Unlike other frameworks, the code generator in Ember.js creates an object only when it needs it and keeps it in memory. After the object is no longer needed, Ember.js destroys it - this principle frees you from unnecessary support for generic code.

We continue. Suppose the user requested the / posts path. Based on this request, the router will try to find the next object in the chain by its name - the path. As you probably already guessed, Ember.js will look for an object of type Route with the name PostsRoute. The path to Ember.js is responsible for providing the model to the controller.

Ember.js will look for a model called PostModel. The model describes the structure of data stored in your repository and the business logic of objects. You can imagine a model as a class from which Ember.js creates objects containing data. Data storage is just an abstract technical layer that lies between the model and your server. Data is stored in the storage after Ember.js picks it up from the server.

After the path takes the data, it gives it to the controller. The controller in this case will be called PostsController. It is worth noting that there is no direct connection between the controller and the model; they do not know about each other and the controller, in principle, no matter what model you give him. The controller is just a data decorator - it processes them before giving it to the user.

Then Ember.js takes the processed data from the controller and gives it to the template. But there is another object that is between the controller and the template - the view. It is the view that in our case will be called PostsView that tells Ember.js which template to use for this request. According to the rules Ember.js will use a template called posts.

Feedback

Users can interact with our application (click on buttons, drag items and mess with the developer in other ways available to the user). Ember.js distinguishes between two types of user interaction with an application. The first is the so-called. browser native events — click, drag, drop, mouseEnter, mouserLeave, and so on. The second way is the events that have a name. The second type of event is basically triggered by clicking on the item on which this event is definitely.

So what's the difference, you ask? Well, or wanted to ask. The first type of event is processed exclusively by the view; Ember.js no matter what button the user presses, the main fact that the click happened. The second type is triggered only after clicking on a specific element and is processed by the controller. If the controller cannot handle the event, Ember.js tries to process the event in the path (Route Object) and only then reports an error.

Pattern Structure

Everything starts to seem even more confusing after the newbies find out that you can embed other objects into Ember.js templates, thereby re-invoking the whole cycle. In fact, there is nothing wrong with that.

At the moment you already know that the template has a context - a model, a controller and a view.

Let's start with partial templates. This is the simplest object that you can attach to your templates (although the object is probably too loud a name for partial templates). Ember.js will simply take the template you specified and present it in the parent template; this will use the context of the parent - i.e. in the partial template, you will have access to the model, controller, and view of the parent. Simply put, all events will be processed by the view and controller of the parent.

The view and the component are quite similar to each other (in truth, the view is the parent class of the component). The view and the component both have their own template. Behind the view and component is its own object. The difference lies in two key points. Firstly, event handling - the component itself processes the nominal events and the view simply simply gives them to the parent template, which in turn gives them to the controller. Secondly, the environment - the component is completely isolated and can only work with the objects that you give him; the view in turn has access to all objects available to the parent template. From the point of view of the context of the parent template, the view has access to the model and the controller but has its own appearance. The component is more isolated and does not have access to anything.

The last element is a render. It is the most complex of all the objects available in the templates. When you call a render in a template, you need to provide it with two parameters - the name of the template and the model. Ember.js will find the template and, based on the template name, will find the controller and view. Then he will give the model to the controller and after the controller processes the model, Ember.js inserts it into the template. Simply put, with the help of a renderer, you can collect several templates independent of each other on a single page with a completely different context; The render does not have access to the context of the parent template (instead, the render has its own context) and all events will be processed using the view and the render controller.

I hope you enjoyed the theoretical introduction to Ember.js. If Ember.js interested you, you can continue to get acquainted with it after reading the official guide . You can also continue acquaintance with the help of my book , an extended translation of one of which chapters is this article.