In-depth understanding of Ember-Data features (Part 2)_html/css_WEB-ITnose

Written in front

I have been very busy recently. I have changed to a new job and I have to learn a lot of new technology stacks. I have also found a lot of excuses for myself not to keep blogging. It is often ironic that more of the remaining time is not used but wasted. Maybe this is youth, squander it. This is not what I want. In this case, I will continue to write, Keep doing a good job in blogging and strive to be among the top 100 blogs. Please keep this in mind.

                                                        Late at night on September 7th, I was next to the computer.

JS front-end framework Ember.js series

In order to better use Ember-Data, you need to use Store, Store You can think of it as an in-memory cache that Ember-Data uses to restore and save data models. In fact, the Store is also responsible for obtaining data from the server through the bound Adapter.

You can also customize the Adapter:

Or customize the serializer:

Here are just Point out the custom scenario, which will be analyzed in detail next.

Getting data in Model

The following are two simple ways to get data:

1. Store.find('mainMenu'); This method is trying to get All data of type mainMenu.
2. Store.find(‘mainMenu’, ‘JSFlotJAgent’); This method is trying to obtain data of type mainMenu and id of type “JSFlotJAgent”.

For more examples, please refer to: http://emberjs.com/api/data/classes/DS.Store.html

Identification model relationship

The mainMenu and Children types in the above model are both mainMenu, forming the concept of an "infinite" tree with nested node objects in a loop. The following figure shows the relationship between mainMenu and Chart in the model:

Note: OneToOne, OneToMany, etc. in the above picture are ambiguous. The author's picture should be changed to OneToNone and ManyToNone.

Here mainMenu has a parent node to identify the upper-level reference relationship, a children node to represent the collection of child nodes, and finally a one-to-one chart to represent chart data. Chart can be understood as the main content of a node, and parent and children represent the location and relationship of the current node, which is somewhat similar to two pointers pointing to the parent node and child node respectively.

In the next section we analyze the model relationships in Ember-Data in detail.

Ember-Data supports multiple data relationship types. These relationship types are used to expect the data type structure returned from the data end. Next, let’s analyze the role of these APIs in detail.

Understanding the Ember-Data relational model

Ember-Data defines 5 relational models, three of which are real types, and the other two can be understood as special examples .

Note: OneToNone in the second line of the picture is replaced with OneToOne. The author may have made a typo here.

Among them, as we mentioned in the previous section, there are many conventions in Ember-Data. For example, the defined attributes must be in Camel style (such as modelA), the list array attributes must be ended with s (such as modelAs), and all ids must be Uniqueness, which makes it easier to read the JSON Hash object passed from the server.

Understanding Ember-Data edge (sideloaded) loading

Edge loading is loading in steps by increasing the data level (can be understood as loading the first level of data collection first, and then loading as needed Load a sub-level data collection).

Let’s first look at the definition of Model:

This is a typical article and comment structure, that is, an article contains multiple comments, and one comment belongs to an article.

Let’s see how edge loading works:

When requesting all data of type, Ember-Data found that there is no such data in the warehouse. Then a request is made to the server, and the server only returns the article content and comment id (which can be understood as only returning a preview of the comment, not all the information of a comment). Then when the comment details are requested again, the server returns the real information of the comment.

You can have the server return all data when requesting data for the first time: (instead of waiting for the comment request to return)

Note: In this scenario, if the user does not view the comments, the comments will never be displayed, which means that the data may be loaded meaninglessly.

Of course, this also depends on your data scenario. Maybe this model is not suitable for you. Doing so will generate more HTTP requests, but at the same time it will reduce the amount of "available" data returned. How? The trade-off requires careful analysis, and of course you can also customize how to return data.

Here Ember provides three basic scenarios for rewriting Adapter:

1. There is no universal standard for the data type of data transmitted by the server API.
2. The data sent from the server API is different from the data type you defined.
3. Rewrite the Adapter and retain the Serializer to ensure that the type in the top-level structure of the Json data sent from the server is different from the type you defined, but the subtypes are the same.

Customized Adapter

Let’s take a look at this scenario:

In the data type in our previous section, mainMenu Contains a one-to-one Chart type. The current requirement is to set the Timespan of the Chart to partially obtain the Chart data. If it is not set, the default is 10 minutes.

First, extend a type from DS.RESTAdapter and follow the Adapter naming convention (XXXXAdapter must follow this pattern).

Then, you can rewrite the following method:

For our current needs, we only need to rewrite the find() method, which will Make an HTTP request.

Among them, the important thing is to use Timespan to reorganize the http request, which has achieved our purpose.

For more information, please refer to: http://guides.emberjs.com/v1.11.0/models/customizing-adapters/

Customizing Serializer

Compared to RESTSerializer , we give the following non-standard data model:

In this return type, user_name, account_name, user_role are non-standard data relative to RESTSerializer. And the top-level attribute name user_model does not match.

We can rewrite the methods in the Adapter to achieve our goals:

Here we need to rewrite the normalize method in order to solve the problem of non-standardization of user_name, account_name, user_role, Override the typeForRoot method to solve the user_model problem.

Customized URL

You can customize the ULR access type and conversion definition of the Adapter. Here is a good example:

The final access will be as follows URL: http://api.myapp.com/json/v1/mainMenus

1. Can the advantages of using Store to store data be combined with Filter?

Store can automatically cache data and maintain data identity through the id attribute. And allows users to use Filter to filter unwanted data.

1. How does Ember-Data notify that new data has arrived?

When you use store.find(), the data will automatically update the RecordArray, and any calculated properties or listeners on the RecordArray will be notified. If you do not need to request and want to load data, you can use Store.push or pushPayload to push data to the Store, so that the Store will also get the listening event triggered. Such as SSE or WebSocket scenarios.

Ember-Data update log: https://github.com/emberjs/data/blob/master/TRANSITION.md

Bibliography: "Ember.js In Action"