Reprinted from: http://www.jianshu.com/p/0e42799be566


React+Redux is very refined, and is extremely productive when used well. But the biggest challenge comes from the functional programming (FP) paradigm. In the engineering process, architecture (top-level) design will be a huge challenge. Otherwise it could be a mess. At the end of the day, traditional frameworks versus React + Redux is OO versus FP programming paradigm.

Simply learning a technique does not build a global understanding and is difficult to engineer. Therefore, we must look at the following aspects:

  1. Learn what makes it unique. For example, the React component is the Pure Render function.
  2. Put the new technology in context. Place React in Flux and redux. To really see the data flow in one direction.
  3. Contrast to see the advantages. See the advantages over other solutions (Vue, Angluar, Adobe Flex).
  4. The challenge. There are no silver bullets in software.

1. React

1.1 uniqueness

  • Virtual Dom: another Virtual layer, middle layer, cache layer, boldly jumped out of the Dom constraints of the Web, to achieve a more ideal UI programming model: tree control organization, unified events, unified data transmission channel (props). Dom render to web, Navtive GUI systems is great, Learn once, Use Everywhere.
  • Light Component: The React Component emphasizes pure render and puts business logic into other subsystems, such as reducer in Redux.
  • The component state to be minimized is not passed to props over time, and cannot be computed from other props or stat.
  • A common design pattern was to create several stateless components that were designed to render data, and stateful components were built over them. Stateful components encapsulate all user interaction logic, and these stateless components are responsible for declaratively rendering data.
  • The design paradigm is data-driven components to render. In contrast to the OO paradigm, OO sometimes makes Compoent into a closed, complex class with too much state hidden in it for debugging to keep track of.

1.2 Place React in context

React’s Virtual DOM wants to build an ideal front-end model. What is the ideal front-end programming model? My personal four points:

  1. Ability to build basic UI: Whether it’s component dragging (VB) or writing tree XML description documents, you can quickly create intuitive UI interfaces
  2. Data Binding: Bind data to the data layer (Model) to present a UI with data
  3. User interaction: The user clicks, touches, the application completes the business logic, and feedback to the user, indicating a living UI
  4. UI layout: Organize and manage a UI, one UI calls another, die or hide.

React does a pretty good job of building a basic UI by writing JSX. JSX is a very good engineering tool, and when you first see it, you’re not going to like it. But always give something new five minutes! If you taste it, you’ll see that it’s much more cohesive, much more pragmatic to have computations and displays in one place, and you can even write CSS styles inline sytle in js files. Most importantly, it can blend XML-enabled components with JS calculations!

React performs initial data binding using the props protocol of the parent and child components. This is simple and efficient, props!

User interaction: The React component is considered to be a finite state machine. Interact with users and change their state. According to these states, the Render algorithm now calculates the appropriate data set to present to the user. The advantage of this is that the design paradigm is highly consistent.

UI layout, you may need to use react-Router, or write your own framework. This area has not been studied.

1.3 Compare other schemes

React, compared with other solutions, has prominent advantages of orthodoxy, lightweight, contractual and pragmatic:

  1. Orthogonal: In contrast to Vue, Angular has no template. A large Component is a template.
  2. Light: Compared to Abobe Flex or other UI systems, it is light and does not have a complex OO UI architecture, which also shows that React is just an adhesive layer for the target UI architecture.
  3. Covenant: Convention over Java ritual, which has been a trend since Rails. Such as Pure Render, minimize stateless state.
  4. Pragmatic: Use JSX to organize a tree structure for expressing controls, and use this.props to pass data

1. The four challenges

React is a data-driven UI Component architecture that is an open data-dependent, non-closed OO object. It has the following challenges

  1. The Render method can be large, and the Component displays the logic in Render all at once. There are usually two parts of the logical implementation, the initial data binding, and the algorithm after the user interaction.
  2. Render renders a ReactElement tree, but some of the components and UI elements in the tree have been moved forward due to calculations, which makes the tree look less complete and thus less intuitive.
  3. While it can be broken down into smaller components, building large components can be a challenge because all logic depends on external data, which is relatively unstable, and components lose the protection of their own boundaries and are not closed.
  4. As interactions become complex, component states become larger and larger, and the render global algorithm becomes more and more difficult to write.
  5. Passing in the behavior of the child component is also a non-explicit matter, often requiring a function of the parent component to be passed as a callback to the child component.
  6. Large components often have multiple pages. How do these pages exchange data is a big challenge

2. Talk about your understanding of Redux

2. 1 Uniqueness

  1. A data layer framework similar to Baobab. Better yet, introducing the Middleware system, there are several off-the-shelf plug-ins like Redux-thunk and redux-Promise that don’t make asynchronous requests. While it’s important to be flexible and independent, global design is also reassuring to use without worrying about loss of functionality and other risks.
  2. The application of IMmutable data in FP makes tracking data changes much easier. That is, time travel. This is good for locating complex problems.
  3. The return from reducer is the process of creating, updating, and deleting a tree data store. The tree structure does not need to be defined in advance. Meanwhile, Reducer is also a pure function, which corresponds to reactor’s render.
  4. Strong constraints (conventions) increase cohesiveness. Action, dispatcher and Store in Flux are scattered, which are required in hierarchical architecture, but their cohesion is not good, resulting in the ritual feeling of Java. Redux is a clear data layer, a store, updates dispatched to actions, the first half of which you can do whatever you want (middleware), and the second half of which you can reducer. The reducer constraint is do not change oldState, return newStatew, immutable.
  5. Different Actions: Actions in Redux are finely chopped, with a traditional action being sliced into three: Loading, GetSuccess, and GetError. So, in this sense, actions serve the UI, not the business logic unit.
  6. Redux applied FP extensively, and often encountered concepts such as Curry, Trund and promise in FP, which cost a lot to learn. Implemented in the Middleware layer, it is unfriendly to people without FP experience.

2.2 Place Redux in context

  1. Redux is a thin data layer. At the same time, the View is redux-react.
  2. In traditional MVC, you still have a controller that does the business logic. However, Redux cut a controller into two parts: Action and Reducer.
  3. In theory, Redux could also take the stores of stat from the React component, such as the names the user searches for. So, you can put the filtering algorithm in the selector. But the benefits are not great.

2.3 Comparison with other schemes

  1. In contrast to Baobab, which are both data management frameworks, Baobab provides cursors to allow you to update very deep data structures. Redux is done by selector, which is a little bit more obscure. But better than Baobab, data fetch can be done through Redux’s Middleware.
  2. Redux is more of a convention than Rails’ Controller, ActionRecord, and does not provide a routing-level controller or data access cursor.
  3. There are no more than 10 interfaces and very little code, but it’s completely different from previous MVC frameworks. Perhaps the biggest problem is that it didn’t get through with react- Route, which made engineering confusing.

2.4 the challenge

  1. The biggest challenges for Redux applications are more at the design level, how to design actions, how to design the state tree structure. We can only do this with very few clues (FP architectural ideas), which is a big challenge for teams without FP experience.
  2. Getting data from the stat tree via a selector function is obscure, and the code in that selector is considered business logic, which is placed in its own selector and not business-cohesive.
  3. The Middleware layer design: An action is an intent that is sent to the Middleware to fulfill that intent. But in doing so, actions are more ambiguous, one moment an object, the other a function. FP programming is also too intrusive.
  4. It is not designed in combination with Route, which makes people feel uneasy, and I do not know how to connect data and components under different routes.

3. Summary

React + Redux is a typical FP programming paradigm implementation, while most other frameworks are OO paradigm. React + Redux development depends on whether you have a good command of FP or a certain architectural ability. React alone does not require this. React is used as a view.

FP vs 3.1 OO

FP pros and cons
  1. The advantage of FP is that it does not have the complex ritual feeling of OO, and is abstract and structured along the idea of data structure + algorithm. If the top-level design is good, the code reuse is very high, the code quantity is small. For example, to generate a tree I use an iterative algorithm to generate it directly, whereas OO people tend to define an obscure class interface with a Composite pattern.
  2. The disadvantage of FP is also the disadvantage of process-oriented programming. Algorithms and data are global and coupled to each other, which often results in a strongly coupled system. It’s hard to evolve without a good top-level design.
  3. Some of the disadvantages of FP can be mitigated by convention and global understanding. “Convention over configuration” is also a major development direction for frameworks.
Advantages and disadvantages of OO
  1. The benefits of OO are divide-and-conquer, incremental evolution. At the same time, autistic, relatively clear semantics.
  2. The disadvantage is that it is very difficult to express some algorithms. For example, the command pattern can be troublesome to implement history rollback. This is why most of the gang of Four’s design patterns are difficult to understand. In addition, OO has always had a problem with algorithm reuse, which ruby is better at solving, and mixins are natural. And like C++ with multiple inheritance and generics, personally not the best feeling.

3.2 suggest

  1. React + Redux is suitable for those with FP experience or strong architecture ability, with fewer team members and strong ability. Otherwise use React + Angluar, or just use vue.
  2. Too much OO, too much Java ritual is really unnecessary. Through architecture design, FP has certain advantages in productivity. At the same time to deal with complex systems, can better commissioning, positioning problems. In the new era, it is worth trying.

Did this article help you? Welcome to join the front End learning Group wechat group: