Anatomy of Ember.js (Part One, Theoretical)

Ember.js is difficult to learn. Although not even so. Ember.js concepts are difficult to learn and understand. It seems to me that any Ember.js training course should begin with these words.

I am a developer working with Ruby on Rails (before that I had programmed in .NET and Python). It was quite problematic for me to understand the magic that makes Ember.js work. Sometimes I talk with other novice developers who have embarked (or are trying to embark on) the path of Ember.js - all of their problems begin 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 that we have in the arsenal of controllers, models and views (controller, model, view). But in order to find out what they are responsible for and how they work, the beginning developer is offered to step on the rake a couple of dozen times first. Plus, the load on controllers, models and views of Ember.js gives us a whole platoon of motley objects such as components, templates, router and paths (component, template, router, route).

But first things first. Let's start our training with Ember.js by remembering that this is not an MVC (model-view-controller) framework; forget about it. Yes, Ember.js has controllers, models, and template views, 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, sending a colleague 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 digression):Ember.js works on two principles. Rules above convention over configuration and if Ember.js does not find the expected object, then it creates it on the basis of its internal rules. Here it is worth noting the way the Ember.js code generator works. You are probably familiar with generators in other frameworks: they create a file with code and save it on your disk. Unlike other frameworks, the code generator in Ember.js only creates an object when it needs it and holds it in memory. After the object becomes unnecessary, Ember.js destroys it - this principle frees you from unnecessary support for template code.

Let's continue. Let's say the user requested the / posts path. Based on this query, 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 search for an object of type Route called PostsRoute. The path to Ember.js is responsible for providing the model to the controller.

Ember.js will search for a model called PostModel. The model describes the data structure of objects stored in your storage and business logic. You can imagine the model as a class from which Ember.js creates objects containing data. A data warehouse is just an abstract technical layer that sits between the model and your server. Data is stored in the repository 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 don’t 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 located between the controller and the template - the view. It is the view, which in our case will be called PostsView, tells Ember.js which template should be used for this request. According to the rules, Ember.js will use a template called posts.

Feedback

Users can interact with our application (poke buttons, drag and drop elements and dirty developers with other methods available to the user). Ember.js distinguishes between two types of user interaction with the application. The first is the so-called Native browser events - click, drag, drop, mouseEnter, mouserLeave and so on. The second way is events that have a name. The second type of event is basically triggered by clicking on the element on which this event is definitely.

So what is the difference, you ask? Well, or you wanted to ask. The first type of event is handled exclusively by the view; Ember.js no matter what button the user clicks, the main fact is that the click occurred. The second type works 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 beginners find out that other objects can be embedded in Ember.js templates, thereby causing an entire cycle to be re-run. In fact, there is nothing to worry about.

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

Let's start with partial patterns. This is the easiest object that you can put in your templates (although the object is probably too big a name for partial templates). Ember.js just takes the template you specified and presents it in the parent template; this will use the parent context - i.e. in a partial template, you will have access to the model, controller, and parent view. Simply put, all events will be handled 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 component both have their own template. Behind the view and component is its own object. The difference lies in two key points. Firstly, event processing - the component itself processes the registered 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 objects that you give it to him; the view, in turn, has access to all objects available to the parent template. In terms of the context of the parent template, the view has access to the model and the controller but has its own view. The component is more isolated and has no 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 the render in the 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 name of the template will find the controller and view. Then he will give the model to the controller and after the controller processes the model, Ember.js will insert it into the template. Simply put, with the help of a render, you can collect several templates independent from 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 is of interest to you, then you can continue to get acquainted with it by reading the official guide . You can also continue acquaintance with the help of my book , an extended translation of one of the chapters of which is this article.