We improve Redux

Hello, Habr! I present to your attention the translation of the article " Redesigning Redux " By Shawn McKay.
Should state management cause problems today? Intuitively, developers see the hidden truth: state management is much more complicated than it should be. In this article, we will discuss a few questions that you are sure to ask yourself:
Do you really need a library to manage the state?
Did Redux deserve popularity? Why or why not?
Can we think of a better solution? If yes, which one?

Is the library needed to manage the state?

The front-end developer is not the one who simply moves the pixels from side to side; the true art in knowing where to store the fortune. This seems complicated only at first glance.
Let's look at the possibilities that React provides to us:
We improve Redux
the initial configuration of the Redux application (the left screen).

Many developers, immediately after the first step, stopped in bewilderment. What is thunk ? compose ? Is the function capable of this?
It is believed that Redux is based on the configuration of the composition. The setting should be similar to the example on the right.

2. Simplify the

Redux Reducers can use switch designs far removed from those we used to use.

Given that the resellers find a match by the type of action, we can make each reviser a pure function that takes a state and action. You can shorten the action and only transfer state and data.

3. Async /Await without Thunk

Thunk is widely used to create asynchronous actions in Redux. In many ways, thunk is more like a smart hack than an officially recommended solution. How it works:
You pass the action, already as a function, and not an object.
Thunk checks every action that it is a function.
If everything converges, thunk calls this function and passes some of the stop methods to it: dispatch and getState.
Really? Is it thus necessary to typify simple actions as an object, function or even a Promise?

Is it possible to use async /await, as in the example on the right?

4. Two types of actions

Think about it, there really are two kinds of actions:
Reducer action : runs the editor and changes the state.
Effect action : starts an asynchronous action. It can cause a reducer action, but the asynchronous function is not able to directly change the state.
The ability to distinguish between types of actions will bring more benefits than the use of "sleds."

5. No more variables holding the action type

Why is it customary to separate action creators and résumers? Can one exist without the other? How to change one without changing another?
The action generators and résouzurs are two sides of the same coin.
const ACTION_ONE = 'ACTIONE_ONE' This is an additional side effect of the separation of action generators and riders. Handle them as a single whole and there will be no need for large files with export types.


6. Reductors are action generators

Combine Redux elements according to their purpose, and you will get a simple template.

In the end, following this scenario, The producer can become the generator of actions .

Use the naming convention, and the following items will be fairly predictable:

  2. If the renumberer is called "increment", then the type will be "increment". Even better, we will designate as "count /increment".  
  3. Each action sends data via payload.  


Now with the help of count.increment we can create an action generator directly from the editor.

Good news: we can improve Redux

These problematic parts were motivated to create Rematch .

Rematch serves as a wrapper around Redux, giving developers a simplified API.

Here is the complete code example with Rematch:

I've used Rematch in production for the last few months. And what I think:
I've never spent so much time managing the state.
Redux does not disappear and does not have to. Learn this library with a smaller learning curve, a smaller boilerplate and less mental overhead.
Try Rematch and find out whether you like it or not.
Put a star to let us know about others.
+ 0 -

Add comment