This close reading article is a combination of:

One was Gianluca Guarini’s “Things Nobody Will Tell You About React.” I translated it as “Things No One Will Tell You About React Before You Get into a Pickle.” This is because the author is clearly critical and disappointed about React.

On the other hand, Dan Abramov, a Facebook employee and Redux writer, responds to the above reply “Hey, Thanks for Feedback!” .

1 the introduction

Why did I choose this article?

Our team first identified React as the way forward in 2014, at a time when many people were still talking about how Angular (which was Angular 1 at the time) was such a forward-thinking framework that they had never even heard of React.

In less than three years, the React community has grown rapidly, with many fans of Angular, Ember, Knockout and other frameworks, both active and passive, coming to resemble React.

Now that React has prospered and doesn’t need to preach, it’s worth taking a moment to ask ourselves whether React is really a perfect framework. This week, we’ll take a look at what’s wrong with React.

2 Content Summary

Gianluca Guarini’s main joke is:

• The React project file organization specification is not unified. There are too many Starter Kits in the community (100+)
• Since React only cares about the View layer, developers are faced with the choice between Mobx and Redux, which brings a number of issues (reconfiguring build scripts, updating ESLint rules, etc.)
• If you choose Mobx, you will find that MOBx cannot guarantee that its store will not be updated externally (official advice is to use a special prefix).
• If you choose Redux, you’ll find that it takes a lot of repetitive code to do the same thing (which is why there are so many Redux Helpers in the community)
• Routing is also a pain in the ass, as the React Router is almost the only choice in the community, but the React Router updates too quickly and accidentally uses a deprecated API
• With JSX, there are a lot of unnecessary div’s or spans embedded
• To get started with the React application, you need to configure a lot of build tools and rules to see the effect
• .

Answered by Dan Abramov

• It’s not true that the Fiber architecture introduced in React 16.0 will require a complete refactoring of existing code, because the new architecture is backward compatible and over 30,000 components within Facebook can be painlessly migrated to the new architecture
• The lack of a unified scaffolding can be addressed by creating – React -app
• Redux and MOBx are not recommended for small applications that are just getting started
• React Router Updates too frequently? 1.0 was released in 2015, 2.0 in February 2016, and 3.0 in October 2016. Although 4.0 was released immediately after 3.0, the React Router had already announced plans for such an upgrade.
• .

3 intensive reading

The students who put forward their original views are: @rccoder @Turbe Xue @pines-cheng @an Yan @Tangcang @Huang Ziyi @Bin Bin @cisen @Bobo.

I am glad to see that many new students actively participate in the discussion of intensive reading, and every voice is a force for the development of the community.

React with difficulty

When we went around preaching React a long time ago, we emphasized that React was very simple because it had very few public apis. The entire Document on React could be read in an hour.

React is difficult to learn. Many of the students involved in the intensive reading have experience in using Vue (including the author of this week’s joke), so they will inevitably compare the difficulty of the two frameworks in their mind.

No comparison, no harm. The general point of view is that Vue is easy to use, documentation is clear, build tools are perfect, scaffolding is unified… As for React, although Dan did a lot of explaining in his article, he quoted @an Yan as saying that “it’s not that bad”.

Therefore, the difficulty in getting started with React is largely attributed to the rapid development of the ecosystem attached to React, not React itself. As a result, newcomers generally feel at a loss when they re-enter. While the official create-React-app alleviates this problem, it has yet to find a fundamental solution.

The myth of state management

In today’s front-end circles, saying React and not Redux is like saying Ruby and not Rails. There’s something missing.

Because React positions itself as a View layer solution, a proper state management solution is essential for medium and large businesses. From the earliest Backbone Model, to Flux, Reflux, Redux, Mobx and Redux-Observable, you have to marvel at how vibrant the React community is.

However, when you actually start working on a new project architecture, do you choose Redux or Mobx, wondering whether to package solutions such as DVA? @Tangcang thinks that Redux, MobX and React have their own strengths. Redux advocates freedom and has good scalability, but it also brings complexity. A simple asynchronous request can only be solved with middleware. Provides performance improvements, but is relatively closed, impedes business abstraction, and lacks best practices. How to choose? Determine based on specific scenarios and requirements.

It is not hard to see that to implement the React front-end architecture well, you need to be familiar with not only your own business, but also the features of various solutions and the appropriate business forms. In the React community, there will never be a standard solution.

Redux is not a universal solution

When Redux launched, it captured the hearts of many engineers with its cool Devtool and time travel features.

However, when you really start to use Redux, you will find that you need to learn many new concepts such as Reducer, Store, Dispatch, action, etc., and there are many basic problems without standard solutions. The most typical example is asynchronous actions. While Redux’s Middleware mechanism offers the possibility of asynchronous actions, it’s important to know thunk before dispatching a non-object action. Adding a Redux-Thunk middleware to Redux is a challenge.

Not only that, but the Redux community has never provided a perfect solution to form processing that is common in front-end engineering. There was the simple util tool Redux-form-utils, followed by the massive complex Redux-Form, and a set of hock-based solutions implemented by RC-Component. Without sufficient knowledge and research, how would you choose?

This does not mention redux-Saga and Redux-Observable, which are very popular recently. Although Dan said that if you don’t need them, you don’t need to know about them, but if you don’t know about them, how do you know if you need them?

React vs. Vue

Vue feels easy to get started with because it provides a way to introduce UMD from the start, which is consistent with traditional JS development practices, and Avalon has been preaching for years that people can quickly adopt a Vue that doesn’t rely on builds.

React introduced the concept of JSX, which could have been promoted by UMD. However, JSX was recommended for better DX, resulting in a high threshold for newcomers.

React + Mobx is roughly equivalent to a complex Vue, but that’s not a reason to ditch React. Why do people think Vuex is better for Vue than Redux? Because Vuex is simple and Redux is cumbersome, this has divided the two user groups.

A simple small company needs simple data flow, no compilation, and no framework for technical selection. They focus on development efficiency, but maintainability is not the first. This fundamentally leads to a mismatch between these two groups of people.

Vue solved this problem and helped so many developers, which is very commendable. However, we should not attack who is good and who is bad from the perspective of React maintenance, because from our perspective, most developers of small and medium-sized companies do not care.

React users collected a batch of high-end users, they continue to explore technology selection, to burst open source community vitality, if everyone turned to the Vue, died in the stall, the evolution of functional, responsive programming will temporarily from the grand unification of the framework is terminated, at least this is not conducive to technological progress, is also unlikely to happen. Vue does a good job in its own field and borrow React agile ideas to help more developers suitable for the scene, which should be the author’s goal.

Tip: How to fight gracefully in the open source community

The open source community has a lot of quarrels, and there are a lot of quarrels in the community. There is even a history of open source community quarrels maintained on Github. Although it is normal for technologists to argue, there are few convincing cases. In this case, Facebook employee Dan Abramov set a good example. It is rare to respond point by point to an aggressive article without evading it, without bullshit, and with restraint.

3 summary

React developers should not worry about Mobx being Vue friendly. This is a tradeoff for a particular business scenario. More and better data flow solutions will continue to emerge in the future, and the technology community will never stop optimizing the technology.

Mobx-state-tree, for example, is a bold attempt to combine Redux with MOBx. The author stated long ago that MOBx can also do time travel as long as certain development specifications are followed.

A final example: Android phones are getting better, and the experience is getting closer to Apple’s. As a high-powered user, switch to Apple. But as a Java developer, should you switch to the OC genre for this? With or without android, it’s all the same. Android and Apple are becoming more and more alike.

Things no one will warn you about before React

If you’d like to participate in the discussion, click here. There are new topics every week, published every Friday.