Still struggling with flux or relay, maybe Redux is more suitable for you


Heavy news, Redux 1.0 has been released, and it can finally be used in the production environment with confidence!

Still struggling with flux or relay, maybe Redux is more suitable for you

In this era of expanding end-to-end application technology, a large number of frameworks emerge every day, claiming to solve a series of ox x problems such as XYZ, and then they will not be mentioned for a period of time. But the developed application still needs maintenance! So when choosing a framework, don’t just focus on your own enjoyment, but also think about the difficulty and ease when others take over in the future.

Because the flux protocol itself is not detailed enough, officials have not given detailed instructions on how to do asynchrony and isomorphism, which are very common problems. There are also a lot of duplicate code in the store and view, and the rapidly expanding action. This will inevitably lead to a pile of “improved” wheels. There are some very bright lights, such as Redux, reflux, Marty. Reflux and Marty basically just remove the duplicate code and add some flexibility to the existing store and action, which is easier to use than the native flux. However, in general, they do not jump out of the thought of flux, and a large number of them are still implemented in the “traditional” mixin way. If the project is not very complicated, you can try it. As for relay, due to the need for back-end graphql support, the cost of switching between legacy projects developed with rest interfaces and large teams with front-end and back-end separation is a little high.

Now let’s talk about today’s protagonist redux. Redux evolved from flux. Later, inspired by elm, Redux got rid of the complexity of flux. Now it has become more and more independent, and even has an angular implementation. Recently, the team began to gradually migrate its old pure flux development projects to redux. Redux still adheres to fluxUnidirectional data flowStore is the single source of truthThese two points are omitted. Let’s talk about other feelings in the process of using redux.

Features and benefits

Clear documents and unified coding

Redux documents are very clear and detailed, which helps to unify the team coding style and saves a lot of time for entanglement and stepping on the pit. Don’t worry about where the Ajax requests are, just throw them all into action (general-purpose or middleware). Whether to use state or props? Props is used in all components, and state is only used in top-level components. Previously, for flexibility or compatibility, the provider of Redux providedProviderDecorator decorator andproviderTwo call usages, only recommended for nowProviderdecorator。 The design idea of Redux is very similar to that of Python:

There should be one, and preferably only one – obvious way to do it.

You will find that after using Redux, the code style of the whole team is relatively consistent. The last time you had this feeling was when the project was moved from the old jQuery component to react. What if you still struggle with some scenes? goRedux issuesAsk for an issue, and someone will reply soon.

State, State, State -> Store

The complexity of the front end lies in the view, and the complexity of the view lies in the state processing. State is complex because it includes the UI state, form status, and even the current URL, such as the data returned by Ajax, which tab is currently displayed, etc. Redux aggregates all these states into a large object, which is calledStoreYeah, it’s from fluxStore。 Redux only limits one application to oneStore。 singleStoreThe advantage is that all data results are centralized and convenient for operation. As long as it is transmitted to the outermost component, the inner component does not need to maintain the state, and it can be transmitted down from props through the parent. Subcomponents become exceptionally simple.


only oneStore, the first feeling is thisStoreWill the object be very large? In fact, large objects are not terrible. What is terrible is that the object processing logic is put together. As long as these processing logic are split according to the processing content, isn’t it OK?! Each split block processing logic is aReducer。 Take theseReducerEach piece of content in the is combined (using the import syntax of ES6) to form a completeStoreReducerJust a pure function, so it’s easy to test. mentionReducerI have to mention functional programming. The essence of reducer is to do object format conversion, which is too efficient to use functional operations.

(previousState, action) => newState

Because it is a pure function, it is very simple to combine multiple reducers. See。 By the way, it also removed the most criticizedwaitForSyntax.


Redux’s action is similar to that in flux. It is a carrier that expresses that the view wants to change the store content. Flux is unifiedDispatcherDistribute the action. Redux removes thisDispatcher, using thestore.dispatch()Method to pass the action to the store. Because all action processing will go through thisstore.dispatch()Method, Redux makes smart use of this and implements a middleware mechanism similar to koa and Ruby rack. Middleware allows you to intercept and insert code after the dispatch action and before the store. You can operate the action and store at will. It is easy to implement flexible log printing, error collection, API request, routing and other operations. Our team directly sends Ajax requests here based on the pre established action and the mapping between requests. From then on, we don’t have to worry about asynchronous data retrieval.

In addition to these, there are also those against the skyDevTools, you can make the application record and replay repeatedly like a video recorder.

Still struggling with flux or relay, maybe Redux is more suitable for you

Redux also has good support for homogeneous applications. The team is conducting research and sharing it after it is actually launched.

Inadequate or inconvenient

Of course, there are also some problems in the process of use. In fact, the main thing is the change in thinking.

Components should be as stateless as possible

This is also called the choice between smart component and dumb component. The development of component library should be made into dumb component as far as possible. This is very different from the traditional jQuery classes that commonly use imperative syntax for component development. If you write a dialog, the jQuery component usually, dialog.hide()method. However, Redux requires that the display or hiding should be treated as a props and controlled by external input. Redux requires the uniqueness of the store as a data source more strictly than flux, so components that were previously available are now found to be directly unavailable.

Rotation training and websocket request processing

The initiation of the request should be done in the action, but the pause / start status of the request should be placed in the store, which will increase some complexity, but ensure the data consistency. In fact, the idea that store is a single data source is not clear.


Official address:
Chinese documents:
Item list:
Isomorphism example:

By the way, I heardChinese documentsThe translation is not bad, even the Redux authorDan AbramovAll pushed, or you can have a look. If you have the energy to participate in the translation together, it’s ok if you don’t have the energy to give a star.

Still struggling with flux or relay, maybe Redux is more suitable for you

Original address