
MobX – Simple, scalable state management for React - gedy
https://mobxjs.github.io/mobx/index.html
======
Lazare
I wrote a very large app in Knockout back in the day, and ran into significant
problems with Knockout's computeds and the two way data binding.

It was great to start with, but as the app got larger and more involved,
performance started to suffer (from all the different observables and computed
triggering and retrigger on a change), memory leaks started to creep in, and
eventually I started noticing weird glitches where bits of the UI wouldn't by
entirely in-sync. Worse, there was very little I could do to fix it, because
the bug was deep in Knockout's "magic". My models had correct data, but
sometimes my UI would _not_.

The lesson I picked up from that was that that sort of magic was bad news, and
for my next major project I used React, and when I needed state management I
eventually ended up with Redux. I won't lie: There's been some pain points,
there's a lot less hand holding, more boilerplate, etc. But performance has
been amazing and there's been no issues where something other than my poor
coding has caused a bug. Redux code is very, very deterministic: You state
looks like X, then you have an event Y, and now your state looks like Z. That
state is fed into your component hierarchy, and DOM elements come out the end.
If you don't like the result, you can quickly narrow it down to being a bug in
your render methods, your reducers, or your actions. No magic.

MobX...looks great. But it looks great in the specific ways that Knockout
burned me in the past. Does anyone have any input on that? If I go all-in on
Redux and write a very large and interconnected app, I have confidence that:

1) Writing all the reducers and selectors will be pretty big pain

2) Once I do it it'll work just as smoothly as a hello world app will.

If I go all in on MobX, it looks like it'll be easier to write, but...how's it
going to run? Saying "inspired by Knockout" gives me distinctly mixed
feelings, seeing as how I started using React to get _away_ from Knockout. :)

~~~
mweststrate
The _idea_ is very much like knockout and meteor, but the reactivity
implementation is completely different. First all it is generic and not
designed for just the UI. MobX is completely glitch free and synchronous and
has explicit distinction between computed values and reactions (side effects
like updating the DOM). More important, MobX determines the right execution
other of derivations on the fly, preventing issues with 'double runs' which
were a common issue in for example Meteor. These design decision are based on
research of common issues with knockout and meteor (like the ones you
described) and analyzing what is the root cause of these issues. For that
reason you also won't find two way binding in MobX

In practice it turns out to work very well for large apps and many people use
it that way
([https://twitter.com/_ericelliott/status/766812933804269568](https://twitter.com/_ericelliott/status/766812933804269568))

~~~
rpedela
> MobX is completely glitch free

MobX looks interesting but I am a little concerned that you are claiming it is
bug-free.

~~~
nightski
I don't believe he meant glitch in the sense of bugs but rather in FRP terms.
I.e. temporarily inconsistent state.

~~~
mweststrate
yep that was the glitch I was referring to indeed :)

------
megalomanu
Mobx is a blessing ! I work on React only since a few months, I have a ton of
subjects to learn, a ton of libraries to learn to how to use them. I really
don't have time to learn a complex library like Redux. I tried, and learned
its principles, but I soon saw that it would totally transform my existent
codebase into a large cream cake with some boilerplate code everywhere. I come
from Java world, which is often mocked (especially by the JS community ...)
for its abstract-factory-factory, but Redux is not irreproachable for that !
Compared to Redux, MobX is a breath of air. It's very simple, very efficient,
and contrary to Redux, not opiniated. It's easy to integrate it in an existing
app. At the beginning, I only used MobX in a complex part of my app. I added a
store, some instructions, and voilà. Then I added it everywhere, part by part,
incrementally. Everything works, my code is simple, anybody, even a beginner,
can understand it. MobX seems to be directly integrated in React.js, linked to
the React core.

~~~
diggan
I haven't used Moxb but I've used Redux a lot the last 6 months, building
mobile apps and also a rewrite of our frontend at Typeform.

I'm not sure how Redux could be considered complex, the API is very small and
the ideas are small as well. There is really not much to learn with Redux.
Redux is like literally 100 lines of code if you remove comments and simple
sanity checks.

Also, not sure what you mean with boilerplate? What kind of boilerplate do you
have when using Redux? Would love to see an example of that.

~~~
tptacek
Redux isn't conceptually complex, but I found it hard to get started with. The
trouble I had wasn't the ideas, which are very clear, but in trying to predict
which parts (composing reducers, passing state to components) would be
animated by Javascript magic, and which were plain-ol-Javascript.

I found myself straining a little to memorize code snippets to get things
started.

Once up and running, it's a breeze, though of course I agree with the common
sentiment that it's too easy to overuse, and native React state too easy to
underuse.

~~~
cageface
It gets really hairy when you have to weave in asynchronous actions and things
like react-thunk or react-saga. By the time you've wrapped your head around
those concepts as well the whole React stack doesn't feel quite as much like
the breath of fresh air it does when you first start using it.

For my next Resct project I intend to go as far as I can with simple container
components before I start pulling in the whole Redux toolkit.

~~~
sotojuan
This is why Ryan Florence (react-router, React Training) just made his keynote
speech at the React Rally conference about people overusing Redux and not
learning or wanting to use plain old React.

In his trainings he constantly sees people trying to rush React and asking him
about Redux (which he doesn't cover).

~~~
tptacek
This is also a drum that Dan Abramov (who created Redux) has been beating.

------
mweststrate
Online courses: Introductoin by LearnCode.academy:
[https://www.youtube.com/watch?v=_q50BXqkAfI](https://www.youtube.com/watch?v=_q50BXqkAfI)

More in depth: [https://egghead.io/courses/manage-complex-state-in-react-
app...](https://egghead.io/courses/manage-complex-state-in-react-apps-with-
mobx)

~~~
rwieruch
Adding some more:

Refactor a Redux Application to use MobX [http://www.robinwieruch.de/mobx-
react/](http://www.robinwieruch.de/mobx-react/)

Large MobX React Application [https://github.com/rwieruch/favesound-
mobx](https://github.com/rwieruch/favesound-mobx)

------
njpatel
I've been using this recently for a pretty complex SPA and it's been great.

It's clear what's happening, without a tons of boilerplate code, and it has
some nice dev tools as well (trace element updates & events, great for
debugging). It also has very useful error messages in development mode (which
is a godsend).

On top of that, I think the docs are pretty good, they seem to be quite active
on GitHub and, from every piece of the puzzle that comes together to make a
2016 web frontend (react, web pack, babel, flow, ui kit, etc, etc), it's given
the least trouble for me so far.

------
ericclemmons
I was able to rebuild a week's worth of Redux work in MobX within a day. And
that's having never used it before.

What's crazy is how MobX is able to update React child components without
updating the parent first. It knows which properties are accessed in each
component, and ensures only the ones that rely on the changed data are
updated.

I'd say give it a shot the next time you have a component with internal state.
Not having to worry about the reducer or how the component gets updated is
refreshing.

~~~
pauldotknopf
> It knows which properties are accessed in each component, and ensures only
> the ones that rely on the changed data are updated.

This is what blew me away. I understood that "computed" values were doing
this, but when I saw that the react components were using it as well, I was
sold. I have been in componentWillReceiveProps with redux too much, trying to
improve rendering performance. With mobx, out of the box, you get 100% exact
render updating.

