4 ms·
Redux always returns a brand new state. This will cause all consumers to rerender and react will update the dom only if there is a change. But with Mobx its mor
by vijaybritto 6y ago
Redux always returns a brand new state. This will cause all consumers to rerender and react will update the dom only if there is a change. But with Mobx its more granular and the updates are atomic. This isn't a problem in apps where there is a single team working on it. But when you work in enterprise apps where different parts are worked on by different teams state updates to redux can be costly. This is not a limitation of Redux but a human problem that occurs inevitably. I've seen this in 3 different large scale projects. It starts well but after a year or so when people move out/in this bites us.
This can be enforced with strict rules, eslint plugins and infra but they are expensive as hell.
EDIT: 'This will cause all consumers (with incorrect mapStateToProps configuration) to rerender'
- jamil7 6y agoUnderstood, this is the reason I suspected and have spent considerable time in the past optimising state updates to forms in React and Redux projects so can imagine how this would become an issue in much larger teams than the ones I was working in.
- tga 6y agoWhen using Redux, components are supposed to select small parts of the state tree, and then they only rerender when those change. It is absolutely not the case that all components render on each unrelated update of the global state, that would be crazy. https://react-redux.js.org/next/api/hooks#useselector https://react-redux.js.org/next/api/hooks#useselector It is true that all of the selector functions need to run on each change, but those are supposed to be really small pure functions and their performance should be negligible, compared with everything else that normally happens in an app. Edit: It is absolutely possible to affect performance with Redux, especially on a large app — for example if hundreds of selectors need to run for every keystroke in a textbox.
- jamil7 6y agoYeah this is correct, I think what the OP was getting at was the fact that Redux requires a little more discipline as it's less opinionated than MobX.
- vijaybritto 6y agoYes you are correct that we can use useSelector to optimize selectors for Redux and I even implemented this hook in an interview on the whiteboard :D. And yeah components are supposed to select only what they need in mapStateToProps and mapDispatchToProps. But I have seen a couple of instances where this is not followed and the developer chooses to use the entire state object passed to the component. This was fixed quickly and all developers got a short doc on the do's and dont's of Redux. This is what I mean by the extra work around redux library and not the concept itself. Also its a fairly common to see developers pushing multiple micro updates like keystrokes to redux making it slow down. This gets filtered in the reviews but it misses out sometimes. I'm guessing this to happen in many other projects too unless I'm missing out on some major update on the tooling around redux. These problems are not because of the approach but in the implementations. I hope you get what I mean by cost in my opinion above.
- tga 6y agoAgreed then, Redux does give you enough rope to get into trouble, especially when used indiscriminately.
- mosdl 6y agoYou still have to run the selectors for all components on each change and check if their result has changed and if so, update the component props. So the more components, the more memory/cpu you waste on each redux update. So now you have to use something like reselect to start caching results...
- jordic 6y agoAlso it'so easy to start making new components dependent on the store, and ending with reusability.