I’ve read this answer, reducing boilerplate, looked at few GitHub examples and even tried redux a little bit (todo apps).
As I understand, official redux doc motivations provide pros comparing to traditional MVC architectures. BUT it doesn’t provide an answer to the question:
Why you should use Redux over Facebook Flux?
Is that only a question of programming styles: functional vs non-functional? Or the question is in abilities/dev-tools that follow from redux approach? Maybe scaling? Or testing?
Am I right if I say that redux is a flux for people who come from functional languages?
To answer this question you may compare the complexity of implementation redux’s motivation points on flux vs redux.
Here are motivation points from official redux doc motivations:
- Handling optimistic updates (as I understand, it hardly depends on 5th point. Is it hard to implement it in facebook flux?)
- Rendering on the server (facebook flux also can do this. Any benefits comparing to redux?)
- Fetching data before performing route transitions (Why it can’t be achieved in facebook flux? What’s the benefits?)
- Hot reload (It’s possible with React Hot Reload. Why do we need redux?)
- Undo/Redo functionality
- Any other points? Like persisting state…
