Interview with Max Stoiber and Sergey Lapin: Choosing a state management solution for React.js

On the eve of the HolyJS conference, we talked with Max Steuber (one of the organizers of React.js Vienna Meetup, the creator of the react-boilerplate, who took part in the creation of Carte Blanche) and Sergey Lapin (member of the HolyJS program committee) and discussed how to choose a state management solution.

Redux, MobX, Relay or another Flux implementation? Practical advice and best practices.
')

Max Stoiber

- Max, hello! First, introduce yourself briefly and tell about yourself.

- Hello! My name is Max Stoiber, I’m an Open Source developer, working for Thinkmill. We do all sorts of cool stuff like KeystoneJS, develop web and mobile applications, and contribute to improving User Experience.

- It sounds cool! Tell me how long have you been doing all this when you discovered React for yourself, and in which projects did you participate?

“Hmm, I think I'm with React for about 2.5 years now.” When I started, Flux was considered the hottest topic in the world! Perhaps the most famous projects in which I participated are KeystoneJS, react-boilerplate and sharingbuttons.io.

Flux to Redux

- I think that now readers have the impression of who is in front of them. As you know, our main theme today is “React Redux on long distances: is it needed in large projects?”. Let's start with what you think about the concept of Flux and what implementations you managed to try to date.

- I really love Flux! I think this is a great idea - to make the data flow unidirectional.

This makes it so easy to work with the state of the application and makes life easier that it’s hard to believe that it was once different. Flux perfectly scales for applications of any size, allows you to intuitively break work with the state in accordance with the business logic of different parts of the application. It is difficult to overestimate this concept when it is necessary to “split up” parts of a project and distribute them among team members. At first I used the original Flux, but switched to redux almost immediately after its release.

- What do you think about redux in general? How do you feel about writing a bunch of boilerplate code?

- I use redux everywhere and adore it. I do not mind writing boilerplate code, moreover, I really like that all the logic is described explicitly and no “magic” happens. Redux changed my approach to developing React applications. Now I am grouping files according to the principle of what features they implement. When I need to change or add some feature, I just look for the appropriate folder and see the whole picture right away without having to search the entire project and remember where I have what.

About working with State and about the future

- How do you work with the state? For example, do you normalize the data that comes to you from back-end'ov, expand Array in Map'y, do you use Immutable?

- Oh, it seems your site has a very technical audience. Yes, you said it right: these are the best practices at the moment. I can add only selectors. I use reselect so that my components can abstract from the structure of the state and receive data in a form convenient for them.

- OK, with Redux everything is more or less clear. Let's discuss two other Flux implementations: MobX and Relay. And also, what do you think about the future of state management solutions?

- I have no experience of using MobX in large projects, but it looks quite promising, and I have repeatedly seriously considered it as an alternative to redux. If we talk about Relay, then this is a great solution, but with one big drawback: your back-end must be in GraphQL format. To be honest, a recent survey only confirmed my feeling that the market of decisions on working with the state has already taken shape, and the situation is unlikely to change much in the near future.

If you don't like magic, then redux is your choice.

- If I came to you with a question: “Hi, Max! I am going to make a new large project and I don’t know which state management library to choose, ”what would you recommend?

- Good question. If your back-end can GraphQL, then you can take a Relay (or Apollo Client) without thinking. With MobX and redux, the choice is somewhat more complicated. If you like to experiment and are ready to spend a little time for your whole team to learn a new solution, then choosing MobX seems to be justified, at least I have heard a lot of good things about it lately. Well, if you don’t like “magic”, you are under tight deadlines, or you want to quickly launch your project in production, then redux is your choice.

- Well, thanks for your advice! I know that you will soon come to Moscow to the conference HolyJS. What are you planning to tell?

- I will talk about offline . Using this technology, web applications will be able to get closer to native applications. In short, ServiceWorkers allows the developer to determine what his application should do or the poor Internet, or lack thereof. This is a very young technology, so there are no well-established solutions, but sw-precache, sw-toolbox and webpack offline-plugin look promising.

- Max, thanks for your time! See you at the conference!

- Thank you for interesting questions, see you in Moscow.

Interview took @YuryDymov

Sergey Lapin

- Hello, Sergey. Please introduce yourself and tell readers about what you do?

- Hello! My name is Sergey Lapin. I am a freelancer, I do projects exclusively on React JS and I mainly use Redux. Now I am doing the third project on it. Concurrently one of the organizers of HolyJS and SPB Frontend .

Why Flux Redux?

- Tell me why Flux and Redux? Why did you choose this approach to create client applications?

- The main thing with which this approach is good is the unidirectional data flow. Any state of the system with this approach is determined by the sequence of these actions (actions). Theoretically, this means that if we give Flux this sequence, then we will get the desired system state at the output. But the most important thing is that simply by putting these actions into the console, it is easy to understand what is going on. This has a huge debug effect.

We cannot get this event log in traditional MVC / MVVP and other systems, because we implicitly change the model by tugging on certain methods. Also, models can influence other models, this all causes a cascade of UI changes, and it becomes very difficult to understand what depends on and maintain it all. Therefore, if you want to change the state, we beat our hands. Now, be so kind as to create an action and pass it through the Dispatcher, which is the only one in the system.

Redux also suggests thinking of the application as the initial state of a modified sequence of actions.

How is Redux better?

- Good. But how is Redux better than other Flux and State containers?

- It is important to understand that Redux is not exactly Flux. Its main difference is that in Redux there is no explicit Dispatcher and Store'ov. The vaults merged into one large vault. Also Redux can dispute actions (create events). It became less independent entities. But the most important thing is that the unidirectional data flow remains.

One of the key ideas of Redux is The Reducers. Nothing interacts with the state directly. Instead, each piece is copied, and then all the pieces are combined into a new state object. Reducers transfer their copies back to the root reducer, which “sticks together” copies together to form an updated state object. Then the main reducer transfers the state object thus obtained back to the storage, and the storage makes it a new “official” state.

If you have a small application, you can use only one reducer that makes a copy of the state object and its changes. If the application is large, then you may need a whole tree of reducer. This is another difference between Flux and Redux. In Flux, storages are not necessarily related to each other and they have a flat structure. In Redux, the reducers are in a hierarchy and it can have as many levels as needed.

This is not the only difference between Redux and Flux. Redux creator Danil Abramov wanted to improve Flux, but at the same time preserve the predictability that this architecture gives. He did it.

- Why do you prefer Redux, rather than other implementations of Flux, MobX?

Now Redux is already very popular, you can say - the mainstream: it has excellent documentation, a huge ecosystem. In a sense, this is the LEGO designer. Redux has a lot of extension points: Middlewares, Enhancers, HighOrderReducers, etc.

For example, Middlewares. If you take the usual Redux from npm, then there is no solution for asynchronous work with data. You give it an action, you get a new state and UI, for one "tick" everything is synchronous. But this is not the case in the real world, we have to go to the network, pick up something from the database and this may cause some more asynchronous behavior. Business logic is basically asynchronous. Here the middleware does the magic, they work basically one-on-one as in Koa.

There are many community solutions for working with asynchrony:

We want to dispute promises - Middleware. We want to show the progress bar everywhere in the application, when something is loading for a long time - Middleware. We want exception to send errors from users with the action log - well, you understand.

A similar story with Enhancers and HighOrderReducers - the central repository gives you a lot of control.

Experience with Redux

- You already have a great experience with Redux. What are its problems and limitations? What difficulties have you encountered in the project development process?

- For example, I had a project - a platform for training courses. This is an application on React, in which there are many widgets for working with images, graphs, graphs, etc. In essence, these are mini applications, each of which has its own logic, its own release cycle, and most importantly, its own state, which everyone else does not especially interesting.

Usually, with Redux and React, there are no performance problems, but if the nesting of components is large, then, after throwing all the changes through the central repository, you begin to feel a delay. As a result, I had to synchronize these states with Redux in a rather tricky way. There was a fun experiment with Redux inside Redux.

There is such a concept - containers and presentation components. For a long time, I believed that the intermediate state was evil. Components should be kept as clean as possible and stored in Redux. Now I do not think so.

For example, why any change in the form of dispatch to the top? Only the atmosphere is so warm ... An intermediate state is needed. I'm not a big fan of classes, so with the help of recompose I wrap stateless into a statefull component. This allows not to rewrite the existing code into classes.

- What mistakes do new developers often make in Redux?

- People forget that a reducer should always create a new object. A common mistake to forget is that spread does not make a deep merge:

const newNested = {...oldState.nested, ...newState.nested }; const finalState = { ...oldState, nested: newNested };

Also often a lot of logic is sewn into containers. It is better to take it to Action Creators: they are easier to assemble there and you can get the current state from Redux.
Better yet, normalize the state .

- Do you have any tips from the category of "Best Practices" for developing in Redux?

- First of all, do not blindly copy other people's projects. You can take some kind of boilerplate and quickly solve the problem, but then you need to figure out what you actually took. Throw out what is not needed, and understand how what you have left is working.

Since Redux is verbose, there is a temptation to save a couple of lines of code and put something out somewhere. Better not to do it right away. First, for sure there is an open source solution and it is better to take it than to create a bicycle. Secondly, the most repetitive patterns are traced over time, and this is a good way to identify the main candidates for refactoring.

Over time, you can outgrow certain approaches, throw out some middleware, use others. A year later, you may not know the project, although it will be the same Redux. This, I think, is the coolest thing in it - the ability to adapt to the requirements of the project.

HolyJS

- And tell me about the conference HolyJS. What are you doing there?
- I am in the program committee, we select and listen to reports for the conference, I will not speak myself.

- Thanks for answers!

Talked levashove

Also at the conference HolyJS ( registration ) you can listen to the following reports:

Source: https://habr.com/ru/post/313726/

All Articles