D
D
Dmitry R2016-07-02 20:05:07
JavaScript
Dmitry R, 2016-07-02 20:05:07

Redux and MobX - pros and cons, when is it better to use what?

Recently, the project switched to Redux, I like everything, it's very convenient.
But now the new MobX beast is on the doorstep, it also manages the state of the application.
Has anyone used it and what are the pros/cons?
When to use which tool?

Answer the question

In order to leave comments, you need to log in

4 answer(s)
V
Vahe, 2017-07-08
@dmitrika

4 reasons to use MobX
I'm using MobX now because I can code 3 times faster than with Redux.
Redux relies heavily on functional programming principles:
Mobx is influenced by object-oriented programming and reactive programming principles:

M
Maxim, 2016-07-02
@maxfarseer

I must say right away that I have not used MobX, but if you are reading further, then you are interested.
The answer about the pros of redux for me personally is at the very end.
---
Before React, I wrote in angular, and even earlier in backbone. In angular development, I had places that I explained to myself: ok, this is how angular works (the digest is there, the scope is so tricky, etc.) - the fact was that not everything was transparent to me personally.
I started to understand React and rewrote part of the working project on React + Flux. In general, I liked it, but copying the same type of code was a little annoying. Redux appeared, which (this is important) solved my problem. AllHere I made a stop. I wrote a couple more internal projects - I liked it. Nothing bothers me. Everything is appropriate, the code is read well. If I go back to an old project, I quickly understand "how it works" and I can start solving the problem.
In the process of working with Redux, Graph QL appeared. Cool! Again, something new - I started to figure it out, and closed it - because it didn’t work out quickly, and along the way a simple thought came to me: why? I'm happy with how React + Redux works. Therefore, I did not delve into the saga, and for now I do not want to delve into MobX. Perhaps this is not correct, because I didn’t even look at them, but I spent my free time from “understanding the new technology” on the “junk” of technologies that I actively use.
Therefore, for myself, I decided - in the near future to sit exactly on a chair, not to jump on technologies and calmly do one application after another. Until there is some dissatisfaction with the current stack.
The main advantages of redux for me:
+ If you haven't touched the project for more than a month, it's very easy to remember what's what.
+ I write code. I don't delve into the new, I build up knowledge on the "old" => I write quickly
+ It is convenient to test
When to use :
- when you want to make a single-page (SPA) application from scratch
- when you want to gradually transfer the old project to the scheme: view (whole page, or some block) + API requests

B
bgnx, 2018-01-19
@bgnx

1) Mobx is best used when you don't want to use monstrous constructs to update some object that is somewhere deep inside the state tree, for example when you need to update a comment that is inside the "tasks" object's comment array, which is inside the tasks object's array of tasks "project" (the scheme is something like this

store = {
   projects: [
    ... , 
   {id: 'project1', tasks: [
       ... , 
       {id: 'task1', comments: [
           {id: 'comment1', text: 'some text'}
       ]} 
   ]}
]}

and somewhere in the comment component, having received the object {id: 'comment10', text: 'some text'} through props in the text input handler with mobx, you will only need to update one property - comment.text = e.target.value when with redux you need to create a separate reducer and write a construction there that will first create a new comment object, then copy the old properties and then write the text property with the new text, then create a task object and also copy its properties and create a new object array of comments and copies all the comments that were plus our new comment object, and then all this needs to be repeated with the project and tasks, and so on with each parent until we get to the top of the state tree.There is indeed a spread operator that facilitates this process of copying properties and array elements, but the constructions still turn out to be monstrous and the deeper the object, the larger they are.
2) Mobx is better to use when you want some objects to refer to each other. For example, we want to create a todo application, but so that we can create subtasks for a task and subtasks for subtasks in general, so that we get a kind of tree of subtasks. From the react side, there will be one component that will recursively call itself for all subtasks.
const Task = ({task})=> (
  <div>{task.children.map(subtask=><Task task={subtask}>)}</div>
  )

And now let's say you decide to limit the number of subtasks to one task. And I want to write something like this condition in the handler - if(this.props.task.parent.children.length > 10) return; that is, simply speaking, refer to the parent task object through the .parent property. With mobx it is possible just like in this example, but with redux it is impossible (because due to the fact that objects refer to each other and the need to return a new state object will cause a recursive re-creation of all objects) and there, to write tree-like interfaces, you need to normalize the store and pass the ID and write a bunch of extra code. And at the same time, it will not work in the handler to refer to the parent object, since this.props.task.

F
Fedor, 2017-06-10
@FedorJS

The fact is that Redux is positioned as a complete CQRS + ES architecture for development in a functional way for frontend programmers. Backend programmers are used to the more traditional OOP-style architecture that mobx requires. That is, mobx is vm (view-model) from mvvm.
It turns out that the preference for architecture and paradigm is the first pointer for choosing one or another library.
The second pointer appears when you start working with a lot of data and you don't need the CQRS architecture. Under such conditions, Redux begins to scare away due to immutability, and Mobx attracts due to data mutability.
And personally, I think that's it. The only thing I can add is that with Redux you can achieve what you want in exactly the same way as you can ruin everything with Mobx. I wrote on both and I know firsthand that everything is not as they say, everywhere there are nuances.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question