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.

Flux

"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.

Redux

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.

MobX

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.