- There was always a point when the application state became very complex and very hard to handle.
- Timetravel is easy.
- But with MobX I think you would need some consistent way of serializing your state.
- Edit: By the way, I think it is very uncommon to render thousands of components.
- So with redux i would need to pass the data to my react components, along with actions to mutate them.
reddit: the front page of the internet
@acemarke: Interesting MobX vs Redux artificial benchmark scenario: . Suspect Redux perf could be heavily improved, though.
I’m also curious if these benchmarks were performed in a fully production build, or in a dev setup, and in particular whether the Redux DevTools were active while the code was being run.
Is the source code for this demo available? Seems like it’d be a nice benchmark playground.
When I first understood Redux I was delighted. State is normalised. Zero redundancy. Views are created using Reselect. Makes so much sense. SQL Databases work similar for a good reason: It’s the best way to handle complex data.
So with redux i would need to pass the data to my react components, along with actions to mutate them.
With mobx i just pass my data object to the component, and the relevant actions to mutate just that piece of data, are right along side it.
For someone like me that comes from an OO background, it’s just the most sensible way to structure things.
Just @action, useStrict(true) and manage state like you would in Flux (through actions, it just happens that they’re in the mobx store itself) and you’ll never deal with unexpected state mutations.