Understanding MobX and when to use it.

[AriaFallah]

Recently having used MobX, I'm trying to reason about why I'm really using it, and trying to truly understand the pros/cons vs redux and cycle.

For redux, I think that it comes down to the fact that most people do not need the number one thing redux has to offer, extreme predicability and extreme testability, because their apps are not complex enough. Thus, when they're writing a bunch of reducers, dealing with extra verbosity, and having trouble grasping the new concepts, only to not reap the benefits, they feel like redux isn't all that useful.

For cycle, I feel like the same way you've written in your docs, most people don't need the complexity and power that RxJS brings to the table over the more simple API MobX provides. MobX also lets you stick to the OOP style that most people are familiar with unlike Cycle, which heavily favors pure composable functions.

Basically MobX lets you write your code as you normally would without forcing you to adopt and learn many new paradigms, and moreover, abstracts away the need to understand your view rendering logic. I think the real power of MobX is the fact that it's just easy.

However, this also makes me wonder.

Redux, ignoring its other limitations and its verbosity, will allow you to write an application that you are familiar with from top to bottom. If you put in the work, it'll be easy to get 100% coverage in tests, and to reason about piece by piece how your program flows.

Cycle despite being more complex, following different paradigms, and needing you to understand RxJS ultimately seems more powerful than MobX if you grasp everything about it.

Do you think the above is accurate?

Also, where do you think MobX fits in when your application grows to be very complex? Like I said above MobX's appeal to me is that it provides similar results to the more complex libraries all while keeping it simple and easy to learn. But when should one pick MobX over Redux or Cycle when they're fully committed to learning and accommodating the complexities of either library? While MobX seems just as capable, the alternatives seem more advantageous if you invest the large amount time necessary to understand them. Is this accurate as well?

An obligatory thank you for writing the library. I'm using it, and enjoying using it. This isn't a critique or anything, but just a deeper dive into understanding its place among other available tools.

[hnordt]

I don't know Cycle and I have no interest learning it now, so I'll give my opinion on Redux vs MobX.

I've been using Redux since it was released. It's very predictable and testable, but takes a lot time to write a full module, because it needs a lot boilerplate.

Of course you can write helpers to help with less boilerplate, but it still needs boilerplate.

I'm sure you can archieve the same predictability and testability with MobX if you implement it the right way. MobX doesn't force you to implement it in a specific way, you have freedom.

You can even use the same structure as you would use with any Redux app: https://github.com/mobxjs/mobx-react-boilerplate/issues/8

I'm using MobX now because I can write code 3x faster than with Redux, but my codebase still is predictable and testable.

In the end of the day Redux and MobX are just concepts. Choose Redux if you want to have full control over dispatching actions and transforming state. Go with MobX if you prefer to don't manually handle action dispatchments and state transformations.

I think that implemented in the right way, MobX is a natural evolution of Redux, you can trust MobX to manage your state, you just tell what you want, instead teaching MobX how to do it.

I think the main difference between Redux and MobX is that for Redux you need to "teach" how to dispatch actions and transform state, for MobX you just trust that MobX will do a good job, you just tell MobX "do it", and MobX does.

(it's just my personal opinion after using both libraries/concepts in production)

[AriaFallah]

I've had basically exactly the same experience as you, and I think we've reached the same conclusion.

Although I am curious, how do you test your MobX application?

That's actually what caused me to write this in the first place. I was wondering how testing MobX was different from testing Redux.

Redux is built on the reducers, has time travel and everything is explicit, which is what I think is the only true advantage it has over MobX. This is also it's disadvantage as well interestingly.

So given all that how do you match the predictability of Redux with MobX in your testing?

[hnordt]

@AriaFallah I'm not an expert with testing, but just try to create your functions as pure as possible, for example:

class MessageStore {
  // bad
  markMessageAsRead = message => {
    if (message.status === 'new') {
      fetch({
        method: 'GET',
        path: `/notification/read/${message.id}`
      }).then(() => message.status = 'read')
    }
  }
  // good
  markMessageAsRead = message => {
    if (message.status !== 'new') {
      return Promise.reject('Message is not new')
    }
    // it's now easily mockable
    return api.markMessageAsRead(message).then(() => {
      // this is a pure function
      // you can test it easily
      return this.updateMessage(message, { status: ' read' })
    })
  }
}

Redux is just javascript, just follow some of the concepts, for example, actions in Redux are the same as MobX, the only difference is the state transformation, for transforming state, create pure functions and pass data around.

[amsb]

I've enjoyed the aromas emanating from the melting pot of ideas in JavaScript front-end development, but with such a smorgasbord it can be hard to decide what to eat. Redux is built on solid theoretical foundations with a simple essence and a growing community of experienced developers that makes it an extremely compelling candidate for many projects.

That said, my foray into using it left me with a project that felt disjoint in its organization. In particular, I felt this way when coming back to my small project after an absence and needed to mentally trace the thread of logic for an asynchronous action through multiple functions and files. I fully admit that this experience probably reflects my deficiencies more than that of the tools, but nevertheless I was curious to explore a different balance which led me to MobX and my mobx-reactor experiment.

In many ways, my experiment effectively replaces the suite of redux+redux-saga+immutablejs+reselect with MobX (and my library) in a way that is perhaps appropriate for some projects due to their size/scale/velocity/etc. What I learned in doing this is that I ultimately exchanged explicitness (i.e. verbosity/boilerplate) and disjointness (a positive in the context of testability and a negative in the context of organization) with tight organization and bit of implicit "magic" (via MobX managing updates through observables).

One of the things I really appreciate about the Redux approach is the single stream of application events that occur in the form of actions dispatched through a single application store and processed by middleware which furnishes similar opportunities as available during request/response processing of traditional application servers.

[capaj]

@AriaFallah

Redux, ignoring its other limitations and its verbosity, will allow you to write an application that you are familiar with from top to bottom. If you put in the work, it'll be easy to get 100% coverage in tests, and to reason about piece by piece how your program flows.

You write it like this is a quality that only Redux has. I have to disagree. There is no obstacle at getting 100% coverage for mobX powered app. In fact it is easier to achieve since the amount of code is smaller than with Redux.

[AriaFallah]

@capaj Ah okay that's good to know.

Like I said above, I haven't done much testing with MobX. I assumed that Redux, where you have to write everything out explicitly, would be easier to test than MobX because there's less magic, but, as you point out, perhaps MobX is easier to test because that magic helps eliminate a lot of boilerplate that made sense anyways so you need to test fewer parts of your code.

Regardless, the whole point of the post is to get perspectives like yours. I'm not trying to peddle everything in the main post as fact like one would in a medium post. I created it as a result of curiosity and confusion about the concepts of MobX and how it stacks up against the other more popular libraries.

[PhiLhoSoft]

Some input:

• I know a bit Redux, as I wanted to introduce it to our project. I actually rewrote it in ES5, which made me look into its code (not so big) and to understand how it works. I like the ideas, well explained by Dan Abramov. I finally dropped the idea, partly because of boilerplate, mostly because using a single store of immutable data would be too foreign for my co-workers (and perhaps even for me! I appreciate the ideas, but I have little experience with these fields).
• I use RxJS in our application, although I can't say I totally master it... Vast API surface! Indeed, as @mweststrate told in a reply (in HN or similar, I can't recall), you can do things similar to MobX in RxJS, but it is a bit convoluted... And as said in the docs, you can freely mix and match both libraries, one for time-driven streams (managing events, etc.) the other for state / data management.
• I introduced successfully MobX in our application: it adds little boilerplate and feels natural to use. Works well in ES5. What is nice is that it doesn't ask you to structure the application around it! I used it for a specific usage: managing state in each controller (AngularJS) to handle various conditions to disable controls (toolbar buttons, dialog buttons, others) depending on various factors (user input, state of data, waiting for data, etc.).

Testing was not a problem (unlike RxJS parts!): I just have variables, I verify they have the right state on given conditions. That's all.
OK, it changes some things: instead of doing ctrl.observedVar = true for a quick test, I have to set up the variables on which observedVar depends to do the test. Logical.
Also, Jasmine is a bit lost with special MobX objects: its isEqual works well with them, but if the values differ, it reports something like "got { name: (getter) } instead of { name: "foo" }", needing a bit more work to see what went wrong.

Overall, experience with MobX is very good.

[hnordt]

@capaj @PhiLhoSoft

Would be awesome if you share some of your testing approaches with MobX.

[hellectronic]

@AriaFallah @hnordt Do you have concrete questions in regard to testing?

[capaj]

@hnordt I have an article on mobx recipes in the making. Will include some samples and showcases on testing. Give me 1-3 weeks, I'll post it then.

[PhiLhoSoft]

Well, as I wrote, testing wasn't much specific. At least in my use case. I added MobX in a very local way (controller level) in an existing AngularJS 1 application, to replace part of the code.
Not using it as a central store, as it would have been too disruptive. We have already some unit tests (made with Jasmine, run with Karma, classical in the Angular world), not enough because of deadlines and so.
But well, the updates I had to do to accommodate the introduction of MobX were minor, as explained above. That's the beauty of MobX: it is quite transparent... And not opinionated, so we can use it outside of React, in a non pervasive way, my way and not in the way envisioned by the project.

[Keats]

@AriaFallah posted a short video to some info: https://www.youtube.com/watch?v=83v8cdvGfeA

[AriaFallah]

@Keats haha yeah, but I figured that since I was just summarizing the information here and not as much in depth I wouldn't promote it myself. I appreciate you posting it though 😄 .

I have to thank @hnordt and @capaj for providing me with a lot of the insight I had in this thread to be able to make the video.

[yelouafi]

IMO the most fundamental difference between Redux and MobX, from a conceptual POV, relates to the update logic.

In Redux, a Reducer encapsulates all the possible ways in which a piece of state can be updated. i.e. you can't (directly) update that piece of state from outside. And the overall state/reducers is organized around this notion of update logic.

In MobX, the state is managed inside observables, but observables act like free slots which accept data from the outside. So in order to tell how the state held by an observable is updated you need to look to all the actions that update that observable.

Typically some (maybe all, depending on the case) of the update logic can be inside a domain class, making observables private and exposing only getters for observable values and the set of actions that update the private observables. But still the update logic will be spread across multiple actions.

So depending on the case: either Redux or MobX will feel easier. I don't think it's related to the size of an application but more to how complex is the update logic. if a domain class can encapsulate all its update logic, and if the overall behavior of the class can be easy to reason about, then effectively MobX will feel easier than Redux (talking about the models not specific implementations).

However if the update logic of the app is such that it can't be encapsulated inside the domain class (e.g. you can't call the class method directly from you UI callback, or the called action will lead to cascaded calls to other actions in other domain classes), then Redux model will feel more suitable here.