The premise

Front-end from native javaSCript to JQuery, to Vue, React, Angular, The Times are advancing, and front-end has been improving. The author believes that “framework” is for business. It is based on the existing development, looking for deficiencies and optimizations. A product that comes out of a large number of business models.

As long as The Times progress and businesses continue to develop, the framework is bound to be optimized and reconstructed to serve the existing businesses. Therefore, it is our learning direction to understand its design ideas, extract the applicable business scope and learn the methods to solve different businesses.

source

React was originally developed as an advertising system project within Facebook. During the implementation of the project, the front-end development encountered great challenges, and the code became increasingly bloated and chaotic, which was difficult to maintain. They decided to throw away a lot of “best practices” and rethink the way the front-end interface was built. Hence React.

Design idea

1. Write predictable, customizable code

Predictable code.

What’s the biggest value of React?

• High-performance virtual DOM
• Server side Render
• Encapsulated event mechanisms
• Complete error message

Although every point is important enough. But React’s most valuable feature is its declarative, intuitive approach to programming.

Software engineering is not always about programming with arcane techniques. Instead, it is about writing understandable and maintainable code that is the key to quality and efficiency. Just think:

• A month later you go back and look at the code you’ve written and see if you can see at a glance what some variable, some if judgment means
• Is a new colleague who wants to add a small new feature or fix a Bug confident enough that his code doesn’t introduce any side effects?
• As you add functionality, your code can easily become more complex, and these problems can get worse, resulting in code that is difficult to maintain.

React claims that new colleagues can start working on new features even on their first day.

2. Define the user interface intuitively using JSX

First let’s look at two types of code for todoList functionality:

//Angular
<ul class="unstyled">
  <li ng-repeat="todo in todoList.todos">
    <input type="checkbox" ng-model="todo.done">
    <span class="done-{{todo.done}}">{{todo.text}}</span>
  </li>
</ul>
Copy the code

While it’s easy to see what this little template means, you can’t start writing code like this because you need to learn the whole syntax. Such as:

• You need to know the exact meaning of having tags like ng-repeat
• The “todo in todoList. Todos” seems to be part of the repeat syntax, and there may be other syntax as well
• You can see a data binding like {{todo.text}}, so what if YOU want to format the text (with a formatter)
• What data structures are needed behind the NG-Model?

React with JSX

//React
render: function () {
  var lis = this.todoList.todos.map(function (todo) {
    return  (
      <li>
        <input type="checkbox" checked={todo.done}>
        <span className="done-{todo.done}">{todo.text}</span>
      </li>);
  });
  return (
    <ul class="unstyled">
      {lis}
    </ul>
  );
}
Copy the code

As you can see, JSX doesn’t introduce any new concepts other than alternative HTML tags (in fact, HTML tags can be written entirely in JavaScript). Angular repeat is replaced here with a simple array method, map. Here you can use familiar JavaScript syntax to define the interface. There is no need for templates in your thought process, just to think about how to build the entire interface in code. This natural and intuitive approach directly lowers the barrier to learning React and makes the code easier to understand.

3. Simplified component model: Components are state machines

Component is not a new concept. It means the encapsulation of a separate function or interface for reuse or separation of business logic.

React understands interface components like this:

React treats the user interface as a simple state machine. When a component is in a state, output the interface corresponding to that state. In this way, it's easy to keep the interface consistent. In React, you simply update the state of a component and output the entire interface based on the new state. React is responsible for comparing the two interfaces and updating the DOM tree in the most efficient way possible.Copy the code

To understand:

For example, a component has two states: read only and edit.

A common idea might be to provide methods like beginEditing and endEditing to do the switch.

In React, you need to do setState({Editing: true/false}). Responsible for correctly presenting the current state in the output logic of the component.

This way, you don’t have to think about how the UI should be updated in the beginEditing or endEditing context, you just have to think about what the UI looks like in a particular state. Obviously the latter is more natural and intuitive.

Components are the basic unit for building user interfaces in React. Their interaction with the outside world is not only the state, but also the properties. In fact, the ** state ** is more internally maintained by a component, whereas ** properties ** are passed in externally when the component is initialized (typically data that the component needs to manage). React states that properties should be read-only and should not change once an assignment has passed.Copy the code

4. Every interface change is a complete refresh

The data model drives a two-tier programming model for the UI interface

The conceptual perspective seems intuitive, but in practice it is difficult to develop. Changes to a data model can cause simultaneous changes in the UI that are scattered in multiple corners of the interface. The more complex the interface, the more difficult it is to maintain this consistency of data and interface.

To maintain such dependency updates, developers sometimes have to trigger extensive interface refreshes, many of which are not really needed. One of the original points of React was that since the whole refresh must solve the problem of cascading updates, why don’t we just do it every time? Let the framework figure out which parts of the UI need to be updated. This sounds very challenging, but React does it. The way to do it is through the Virtual DOM.

Summary feeling

When I read this article and condensed it, I found that most of it was against Vue, lol.

JSX and Vue template rendering mode component thought communication thought rendering thought is about the same, according to the source code in some taste later

In my opinion, before the release of the three frameworks, most of the domestic front end, not cs professional background, more emphasis on UI, art direction, may be weak in data structure foundation.

However, all three frameworks address DOM performance and manipulation issues, templates and reuse issues.

React and Vue are neither superior nor inferior in my opinion. The development of Vue is more inclined to the old front-end design thinking, which is easier to accept and learn. React is likely to design its framework more from a back-end engineer’s perspective.

In the future, I may prefer to develop with Vue for small and medium projects.

For large projects, I think React is more suitable than Vue in terms of software process. Meanwhile, developers have higher requirements on object-oriented data structure and build pages based on logic.