New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a state management library #1091

Closed
Ishirak opened this Issue Jul 6, 2016 · 6 comments

Comments

Projects
3 participants
@Ishirak
Copy link
Member

Ishirak commented Jul 6, 2016

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.

@vasek17

This comment has been minimized.

Copy link
Member

vasek17 commented 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:

  • I don't mind some magic when it is predictable and not so hard to debug.
  • MobX looks it would play well with TypeScript (they even have "official" React TypeScript boilerplate)
  • It looks very clean and elegant
@borekb

This comment has been minimized.

Copy link
Member

borekb commented Jul 7, 2016

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.

@vasek17

This comment has been minimized.

Copy link
Member

vasek17 commented Jul 7, 2016

MobX has also interesting tools around (https://github.com/mobxjs/mobx-react-devtools) but not that powerful.
The key part (performing actions) is not opinioned in MobX so it can done "the Redux way".
It differs after an action is performed - Redux usually works with one single JS object as an application state which is passed via props to React components. After any change the root component is recursively re-rendered (but thanks to immutable objects only affected components need to re-render.

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.

@Ishirak

This comment has been minimized.

Copy link
Member Author

Ishirak commented Jul 7, 2016

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.

As for actions, MobX introduced @action decorator in the 2.2.0 version. Actions help with clarity a lot, especially in strict mode.

In strict mode, MobX will throw an exception on any attempt to modify state outside an action.

MobX 2.2: explicit actions, controlled mutations and improved DX

This means, that every state change has to be made in the actions. So in the one JavaScript class, in one place, there are @observable values and @actions, which modify these values. On the other hand, Redux needs to specify reducers, actions and for clarity even constants. Another benefit of MobX actions is that an actions is wrapped in transaction – it doesn't matter how many changes of observable values an action handles, only after all of the changes are made, then MobX starts its "magic" process of evaluating all the necessary steps to re-render @observer components.

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.

@vasek17

This comment has been minimized.

Copy link
Member

vasek17 commented Jul 7, 2016

❤️ MobX
2.2 update looks really nice

@borekb borekb removed the discussion label Jul 7, 2016

@Ishirak Ishirak added the in progress label Sep 12, 2016

Ishirak added a commit that referenced this issue Sep 12, 2016

Ishirak added a commit that referenced this issue Sep 13, 2016

Ishirak added a commit that referenced this issue Sep 13, 2016

Ishirak added a commit that referenced this issue Sep 13, 2016

Ishirak added a commit that referenced this issue Sep 14, 2016

Ishirak added a commit that referenced this issue Sep 14, 2016

Ishirak added a commit that referenced this issue Sep 14, 2016

Ishirak added a commit that referenced this issue Sep 15, 2016

[#1091] Split logic of BulkActionPanel and Filter into a separate com…
…ponent, which is connected to a new MobX store.

Ishirak added a commit that referenced this issue Sep 16, 2016

Ishirak added a commit that referenced this issue Sep 17, 2016

Ishirak added a commit that referenced this issue Sep 18, 2016

@Ishirak Ishirak referenced this issue Sep 18, 2016

Merged

Introduction of MobX #1119

1 of 2 tasks complete

@Ishirak Ishirak added in review and removed in progress labels Sep 19, 2016

Ishirak added a commit that referenced this issue Sep 21, 2016

vasek17 added a commit that referenced this issue Oct 5, 2016

vasek17 added a commit that referenced this issue Oct 5, 2016

[#1091] Used mobx strict mode.
Reverted use of mobx for local component state due to incompatibility with strict mode.

vasek17 added a commit that referenced this issue Oct 5, 2016

vasek17 added a commit that referenced this issue Oct 6, 2016

@vasek17 vasek17 closed this in #1119 Oct 6, 2016

@vasek17 vasek17 removed the in review label Oct 6, 2016

@borekb borekb added significant and removed in review labels Oct 6, 2016

@borekb

This comment has been minimized.

Copy link
Member

borekb commented Oct 11, 2016

🚢 Shipped in 4.0-alpha1.

@borekb borekb added this to Done in 4.0-alpha1 May 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment