Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce a state management library #1091
This issue is part of a frontend code review, see #1083.
Components, which communicate with APIs, must also change their state and render their logic and child components. Components also do more than just one thing, which do not help with clarity and readability of the components (#1087). This technique is not at all suited for future front end codebase improvements and for implementation of new functionalities.
A state management library can, if designed properly, help with readability, clarity and possible future performance issues. Also any further changes and improvements will not be that much difficult, if done properly and when is #1087 resolved.
A few good state management libraries exist In the React.js ecosystem, so own implementation isn't necessary.
"Vanilla" library, the first one, who started all the Flux state management. The library requires a lot of boilerplate and knowledge of other libraries to achieve a performant app.
Probably the most used one. The library took all the good things from the Flux, except for a need for a lot of boilerplate. Also heavily realies on the Immutability data collections, such as Immutable.js library.
Lately a lot of hype surrounds this library. Principe of this state management library is entirely different than Flux's or Redux's. Behind the scenes the library does a little bit of magic, so it is not as predictable as Redux or Flux, where developer has to do almost everything by himself, but thanks to the magic is the code really clean, app performs really well and the library doesn't require so much boilerplate. Even author of Redux, Dan Abramov, shared his impression.
So these are possible options to choose from, if somebody has another tip for a state management library, feel free to share! My current pick, thanks to clarity, readability and not so much boilerplate, would be MobX, but I'm always to open to suggestions.
referenced this issue
Jul 7, 2016
I'm familiar with Flux and Redux (which is like the industry standard today). I think Redux would be safe bet but it is very verbose.
I haven't used MobX - will have a look at it. Some first comments:
Have the same first impressions, MobX looks really nice. My only concern is whether it is still predictable which is a strong point of Redux, as well as some really nice tooling around it (https://github.com/gaearon/redux-devtools). But from the code perspective, MobX seems more elegant.
MobX has also interesting tools around (https://github.com/mobxjs/mobx-react-devtools) but not that powerful.
MobX has more Stores that have observable properties and it does a little magic in passing these stores to React components. I don't know how the re-rendering after change is done but D. Abramov says it is fast :)
@Ishirak: Do you have view about MobX? Maybe I understanded something incorrectly.
As @vasek17 said, MobX has also interesting tool for debugging: mobx-react-devtools. As for predictability, in the latest version MobX introduced whyRun utility, which helps in development – it can show why specific component needs to re-render itself and under which circumstances will re-render again.
But what really MobX does well is clean and elegant solution for a state management library. It also performs extremely well thanks to a little bit of "magic" behind the scenes, even without developer's optimalization. And even then is predictable, requires a little of boilerplate and its author really takes care of the project. For these reasons I'm in and I'd like to use it in our codebase.