This article is from xiao Han’s blog. Welcome to tread on it

MVVM has become standard for more front ends

Last time I talked about MVVM, MVVM is actually a variation of MVC, which allows you to assign C to V and VM, and then you have components and stores, which allows you to write views to interact better, and data to serve better. John Gossman, the founder of MVVM, said so

The overhead of implementing MVVM is “excessive” for simple UI operations. For larger applications, he said, it has become more difficult to promote viewModels. Furthermore, he shows that data binding in very large applications can lead to considerable memory consumption.

MVVM for writing a blogging system or background management system is excessive, unnecessary, and cost memory. But for the development of a separate front end, and more and more user experience requirements and more and more computer memory, I personally feel that this sentence is outdated.

As a pursuit of front-end development, naturally more attention to user experience, and for the future, soon 2G memory notebook is relatively rare, release 200M memory it is difficult to burn a page.

React provides top-down functions such as state and props to express the state of a site, but on most sites, Redux or MOBx usually go back to being a VM.

Use Store to carry M’s pot

Mobx is back-end friendly

There are many reasons to love The Store.

After using MVVM for a long time, I found that one of the biggest benefits of MVVM is that it can’t be done.

In a project where the front and back ends are separated, store can easily resist some back-end language docking interfaces that are not strictly standardized or not comfortable with JS cooperation. Even if the back end is not modular, we can still implement a complete modular data set with Mobx, and finally use the Store to provide the most comfortable data for the component, and it will be fun to develop the component.

So we take the data from the store, we update the data with the store, we just put the data in the store.

Use Store instead of State

Why store instead of state, you can read this article for three reasons why I use store instead of setState.

The main content of the article is as follows

1. SetState is asynchronous

2. SetState causes unnecessary rendering

3. SetState also triggers some unimportant life cycles.

In fact, using MOBx to control data is very cool, very consistent, makes data management very easy. And more importantly,

Mobx is friendly to product managers

The global state management mechanism keeps the data in the outer layer, we just call it in a variety of ways. We can easily restructure the business by changing how data is called to meet the needs of the product.

About writing components

Finally, React as V.

The first thing you do with React is tell yourself that you should get used to expressing your site in a new way. This is why React has a steeper learning curve than Vue. React expects users to describe and express sites in a new way, while Vue has a higher affinity for templates.

Before React, we also wrote websites to describe websites, but it was very low. We used HTML to describe websites

React describes websites in a different way, using stateful and life-cycle components to describe websites. I think when you understand this layer, you will find a new sense of front-end and improve your level qualitatively. Just like I make fun of the back end every day, you should not care about business, your vision should be on the data, how to better provide data. The same goes for the front end, where the focus should be on how to manage data, express UI and interaction, rather than how to get the business done.

Building a component library

Loosely speaking, there are only two types of components, business components and UI components.

UI components are business-neutral components that help designers solve problems.

Business components encapsulate product functionality and help product managers solve problems.

The React UI component library is a must. Without the React UI component library, the ability to write pages would drop 70 or 80 percent. Most front-end users don’t understand the UI well enough, but you should do it actively.

Functional components and tool-like components

React everything is a component, routing is a component, components are not UI, components can be anything, js everything is an object, functions are first-class citizens, so this is easy to understand. React makes complex and varied UI interfaces easier to express.


Pull away if you can

Split components, whether reusable or not, by data and functionality

A wrong example

<Page>
 {this.renderSearch()}
 {this.renderFilter()}
 {this.renderList()}
</Page>Copy the code

A good example

<Page>
  <Search/>
  <Filter/>
  <List/>
</Page>Copy the code

As few parameters as possible

However, more optional parameters can be used to support more configurations

Dynamic routing

The react-Router V4 feature ditches the old static route gridlock and caters to the essence of React where everything is a component.

React deprecated API

Reduce the use of componentWillMount componentWillUpdate. This is the essence of getDerivedStateFromProps.

To optimize the

When the above can be done, you will find that the development becomes easier and easier, more and more smooth, and then arrogant to deformation, you will feel that the requirements of the product may not be complex enough, the design drawing is too boring, the data from the back end is quite good. At this time need to consider a very key problem is optimization, optimization or early consideration, but for powerful computer computing, small optimization may not cause sensory user experience, but ensure good optimization habits, sooner or later will have a qualitative leap.

Reduce the rendering

React provides a shouldComponentUpdate if possible to determine whether it should render

Reduce the computation

In many cases calculations do not need to be in render, resulting in unnecessary calculations

Pure component

The lower down the component the more it needs to be a PureComponent

Common component library

The essence of React is to use common component libraries to improve the development efficiency of the entire project. However, this is based on good coding habits, high-performance coding habits, and long-term adherence to encapsulating components and the pursuit of user experience.

Summarize the experience of improving efficiency

Finally, when it comes to vision, I think most people’s vision is not wide, because they can only see the immediate interests.

To name a few chestnuts:

  1. For example, writing the component library takes 1.4 times as long as it should, but next time it takes 0.5 times as long as it should. In fact, with proficiency in packaging, it may take only 1.1 times as long to write a component library, but the benefits are improved levels, simplified business, and improved efficiency.
  2. Using store instead of state makes product business easier and easier to write, even though it’s just a matter of getting used to managing and building a complex data system.
  3. Spending a day fixing WebPack can more than double your development update time. Of course, I would spend the day even if it was 0.2 times faster.
  4. Norms are also important, and best practices are important, and these gains in efficiency are harder to show. The word “best practice” sounds like a definitive definition of what is best. Yes, I like people who don’t follow best practices, but who have a good grasp of what best practices mean.
  5. As for procrastination, everyone has it. I procrastinate sleeping until 1:30, but when it comes to writing code, I can be strict with myself and others. It can be regarded as the craftsman spirit as a programmer.

All tragedies happen because of the incompetence of the people involved. This sentence looks very vulgar in the elimination of all kinds of factors, down to human factors, but careful aftertaste is very profound.

Finally, I hope that all readers can practice what they do in accordance with better practices and norms, and timely correct problems, so as not to push to the point of irreparable.

Refer to the article

There are three reasons why I use Store instead of setState

React Combat: Design patterns and best practices