preface

With the rapid development of modern Web applications, especially the emergence of frameworks such as React and VUE under the guidance of data-driven thinking, we need to pay more and more attention to the organization and management of data. As application complexity increases, failure to effectively and reasonably design data separation becomes an obstacle in terms of performance, maintainability, and so on. So we need to focus on front-end data design.

There is no clear specification for how to design data structures that are specific to the front end. There are many paradigms in relational database design. It is a good practice of front-end data formalization to learn from but not copy the characteristics of the front-end.

Fan Shihua

Before we dive into data canonization, we can look at an example

Here’s an example:

In actual business, businesses with many iterations are generally configured, that is, in addition to business data, the contents related to page layout display are also controlled by interfaces. The data returned by the back end might look like this:

{
    info: [{key:'a'.txt:'1'.value:0
        },
        {
            key:'b'.txt:Show '2'.value:1}}]Copy the code

So when you respond to an operation, you need to update the value of each item and if you change the info array, it’s a big inconvenience. If you say that’s fine, but that’s ok, then when you do that, you’re going to commit and you’re going to have this whole bunch of redundant data that the back end doesn’t need, you’re going to have to deal with value. At this point, the data is not so complex, but you have seen the layers of nested objects, the data format is amazing, if you still operate on it, you may not know which field to operate on in the next iteration.

If you separate presentation from logic and extract a specific attribute to store data that interacts with the back end, it looks simpler and more maintainable.

{
    info: [{key:'a'.txt:'1'
        },
        {
            key:'b'.txt:Show '2'}].values: {a:0.b:1}}Copy the code

So you can actually say that we’re talking about formalization or flattening. Let’s take a look at the database paradigm before moving on to front-end data normalization

Let’s take a look at the database paradigm before moving on to front-end data normalization

What is a paradigm: As the name suggests, a canonical pattern (a bit rough, but it seems to be). Originally wanted to find a paragraph of definition to paste below, but looked too stiff, write down personal opinion good.

The columns of the first Normal Form 1NF table are atomic and cannot be redecomposed. As long as the relational database satisfies 1NF

The premise of the second normal form 2NF is to satisfy 1NF on the basis of 1NF. Each row or instance must be uniquely distinguishable, requiring what we call a primary key.

Third normal form 3NFSatisfy 1NF and 2NF, and one database table does not contain non-primary key fields that are already contained in other tables.

That is, there is no redundancy in the table, which can be obtained from other tables through relationships rather than stored separately. That is, related information can be associated with foreign keys. There is a very good expression of the picture, borrowed:

And of course there are other paradigms that I’m not going to mention here.

To sum up, a paradigm is to reduce redundancy and improve efficiency. The higher the paradigm is followed, the less redundancy. However, it should also be analyzed in detail and not blindly pursue to conform to the paradigm. Sometimes the pursuit of paradigms to reduce redundancy will reduce the efficiency of data reading and writing, when the anti-paradigm, use space to trade time.

State design requirements in REdux

Redux also puts forward a formal requirement for state design. For complex data structures, in addition to data duplication, the following problems may also occur:

  • When data is redundant in multiple places and needs to be updated, it is difficult to ensure that all data is updated.
  • Nested data means that the Reducer logic is more nested and more complex. This is especially true if you intend to update deeply nested data.
  • Immutable data requires the ancestor data of the state tree to be copied and updated when updated, and new object references cause all UI components connected to it to be repeatedly rendered. Even though nothing has changed with the data to be displayed, updates to deeply nested data objects also force completely unrelated UI components to repeat render

Therefore, the recommended practice for managing relational or nested data in the Redux Store is to treat this section as a database and Store the data as a stereotype. Here are some ideas:

  • Any type of data has its own “table” in state.
  • Any “data table” should store items in objects, with each item’s ID as a key and the item itself as a value.
  • Any reference to a single item should be done based on the ID of the stored item.
  • The ID array should be used for sorting.

Specific practice -Normalizr

This is where Normalizr comes in, as it is almost always mentioned for complex data management. Its function is explicit through its brief: normalizing JSON according to a schema. Normalize the processing of JSON according to the schema. Its usage is not introduced here, only provides the data before and after the conversion to do a comparison. If you are interested, go to the official website.

Original data:

{
  "id": "123"."author": {
    "id": "1"."name": "Paul"
  },
  "title": "My awesome blog post"."comments": [{"id": "324"."commenter": {
        "id": "2"."name": "Nicole"}}}]Copy the code

After the transformation

{
  result: "123".entities: {
    "articles": {
      "123": {
        id: "123".author: "1".title: "My awesome blog post".comments: [ "324"]}},"users": {
      "1": { "id": "1"."name": "Paul" },
      "2": { "id": "2"."name": "Nicole"}},"comments": {
      "324": { id: "324"."commenter": "2"}}}}Copy the code

Such data is more in line with our previous redux design requirements.

conclusion

Here the front-end data formalization is almost introduced, a feeling is js data structure design is not database design, to follow the corresponding paradigm will make our data structure more clear. Even if it is not considered at the beginning, with the increase of business scale, the original structure will naturally go to a more elegant direction when developing, which is the process of progress. But still, we should look at it based on the actual situation and not blindly introduce it. It is not a praiseworthy practice to simplify it into complexity. The whole article is personal opinion, there is a wrong place welcome to point out

Reference article:

Blog.csdn.net/qq_35401191… Zhuanlan.zhihu.com/p/36487766 cn.redux.js.org/docs/recipe…