5 reasons why you should forget about Redux in React applications
I have been working with React for almost 3 years, used both Redux and MobX, and I have a question by now. Why do the vast majority of front-end developers continue to firmly believe that Redux + Redux Saga + Reselect + 100500 other libraries that make life easier is the best solution to date? I will give 4 arguments in favor of using MobX instead of Redux in the next project.
Let's save 2 pieces of code that do the same thing. Here's what the reducer looks like in Redux:
To change the state, you need to call a function called action in Editors terminology:
And in most cases (not always, but these are the “best practices” that are used on many projects) you will need to write such a boilerplate :
Then it will be necessary to initialize the store (this will need to be done once, but still):
And throw our initialized gate further into the application through the provider (also a one-time operation):
Now you can perform some operations with data in your components:
It turns out that in the case of Redux, in order to change the data in your storage, you must call some functions that will create a new state object ... Personally, for me, this sounds like complete nonsense. Let's take a look at the same functionality performed by MobX. Our side:
And then you can use it in the component:
Yes, that's right, instead of some functions that modify objects, you can use the classic OOP approach, with classes, their properties and methods. Don't be afraid of the decorators (@) inside, they just add the functionality needed to track data changes. By the way, a similar approach, with classes, for data storage is used in Angularjs (Screen taken from here angular.io/start/data ):
To see this, just look at the examples above. And now, instead of writing an endless boilerplate, you can finally focus on writing the business logic of the application, which is good news.
If you look at the examples above, you can see that in the case of MobX I did not use a pure component and this is not an error. You just do not need to use any optimization in this case, because your component will only be re-rendered when the data that you use in it changes. And yes, you can forget about Pure Components, shouldComponentUpdate, and what else do you use in these cases. Ideally, your every component that is not HOC and uses some data from the storage should be observable and then you will forget about problems with optimization forever.
Anyone who uses Redux should know firsthand that a lot of “wonderful” libraries come with it. And it’s good if it’s just a thunk, or maybe it’s so, the developers will follow the path of thelight of darkness and want to use Redux Saga, Reslect and a bunch of strange libraries that make your code not only slower, but also more difficult to understand. And to finish some minor functionality or find a bug in this work will be incredibly difficult and long. MobX is the ultimate solution == not requiring additional libraries, will deprive you of all these charms, so with it the business logic of your application will be clean, like a baby's tear.
UPD Thanks MaZaAa
setState has a number of drawbacks (a brief translation of the article which can be read in the original here ):
This can lead to unexpected behavior:
On the screen above, the alert should have been 2, but since setState is asynchronous, it comes later.
a. It is rendered even if the new value == the old value
b. There are situations when changing state does not lead to any change, for example, when we have conditions for displaying state in which. On the screenshot below, a click occurred when the data was rendered, although the data should not be rendered due to the fasle: condition
. Sometimes the data that setState updates does not play a role in DOM rendering at all (for example, timers). And all the same, the component is being rendered.
There are components that use hooks / methods of component life cycles and in this case, not only an extra renderer will occur, but these events (hooks) will be called every time at the same time, which can lead to strange behavior.
Using MobX will protect you from these shortcomings, because you can completely abandon setState:
If you disagree with something or I don’t understand something, give counterarguments in the comments. Link to the sandbox from which screenshots from MobX are taken: codesandbox.io/s/mobxreact-s7db5 , with Redux: codesandbox.io/s/oj7px08qy9
MobX lets you write cleaner and cleaner code
Let's save 2 pieces of code that do the same thing. Here's what the reducer looks like in Redux:
To change the state, you need to call a function called action in Editors terminology:
And in most cases (not always, but these are the “best practices” that are used on many projects) you will need to write such a boilerplate :
Then it will be necessary to initialize the store (this will need to be done once, but still):
And throw our initialized gate further into the application through the provider (also a one-time operation):
Now you can perform some operations with data in your components:
It turns out that in the case of Redux, in order to change the data in your storage, you must call some functions that will create a new state object ... Personally, for me, this sounds like complete nonsense. Let's take a look at the same functionality performed by MobX. Our side:
And then you can use it in the component:
Yes, that's right, instead of some functions that modify objects, you can use the classic OOP approach, with classes, their properties and methods. Don't be afraid of the decorators (@) inside, they just add the functionality needed to track data changes. By the way, a similar approach, with classes, for data storage is used in Angularjs (Screen taken from here angular.io/start/data ):
MobX lets you write less code
To see this, just look at the examples above. And now, instead of writing an endless boilerplate, you can finally focus on writing the business logic of the application, which is good news.
Third, performance optimization
If you look at the examples above, you can see that in the case of MobX I did not use a pure component and this is not an error. You just do not need to use any optimization in this case, because your component will only be re-rendered when the data that you use in it changes. And yes, you can forget about Pure Components, shouldComponentUpdate, and what else do you use in these cases. Ideally, your every component that is not HOC and uses some data from the storage should be observable and then you will forget about problems with optimization forever.
Fourth - Less Dependencies
Anyone who uses Redux should know firsthand that a lot of “wonderful” libraries come with it. And it’s good if it’s just a thunk, or maybe it’s so, the developers will follow the path of the
UPD Thanks MaZaAa
The fifth reason - the ability to abandon setState
setState has a number of drawbacks (a brief translation of the article which can be read in the original here ):
1. It is asynchronous.
This can lead to unexpected behavior:
On the screen above, the alert should have been 2, but since setState is asynchronous, it comes later.
2. setState leads to unnecessary component renderers:
a. It is rendered even if the new value == the old value
b. There are situations when changing state does not lead to any change, for example, when we have conditions for displaying state in which. On the screenshot below, a click occurred when the data was rendered, although the data should not be rendered due to the fasle: condition
. Sometimes the data that setState updates does not play a role in DOM rendering at all (for example, timers). And all the same, the component is being rendered.
3. setState is not suitable for all cases.
There are components that use hooks / methods of component life cycles and in this case, not only an extra renderer will occur, but these events (hooks) will be called every time at the same time, which can lead to strange behavior.
Using MobX will protect you from these shortcomings, because you can completely abandon setState:
If you disagree with something or I don’t understand something, give counterarguments in the comments. Link to the sandbox from which screenshots from MobX are taken: codesandbox.io/s/mobxreact-s7db5 , with Redux: codesandbox.io/s/oj7px08qy9