Ask anything to MobX

MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses.

Michel, the author of MobX, is hosting this AMA to answer any questions you may have.

Hosted by:

Ask a Question

52 discussions

The Object.Observe spec was pulled from ECMAScript. Many people praised React/Redux as an escape from the Observable model. So generally, when people see "Observables", they tend to stray away, if not simply for the appearance of them falling out of popularity. How are MobX's Observables different? Why bring the observable model into the React ecosystem?

Observables are a very broad concept, and depending on the context they have a good or a bad name. Both the ES7 Object.observe and RxJS provide (different kind of) observables. Personally I'm happy that the ES7 proposal didn't make it, as the semantics where confusing at least. In MobX observables are really an implementation detail. In hindsight the @state might have been a better name for the decorator than @observable. Observability is a concept that is used internally by MobX to detect when stuff that can be derived from state is not consistent with the state itself anymore. When using MobX you shouldn't be bother anymore with wiring up and tearing down observable listeners. MobX abstracts away from exactly that. But since observables are used internally, MobX can establish very fine grained observers so that it can determine very precisely which derivations are out of sync. But in principle MobX is about reactivity, observability is just the means to get there, not a goal in itself.

An interesting difference with the ES7 proposal is that MobX observers are always triggered synchronously. This simplifies the semantics a lot and makes tracing and debugging easy; if you want to know why a derivation runs, just set a breakpoint and the stack will contain the change that triggered it. In the upcoming version the DevTools will even assist you in doing this.

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

Why is MobX called MobX, how did you come up with that name?​

Show all replies

Sounds cool!

Reply to this…

One of the core principles of Redux is that the state is read-only so that any updates to the state must occur in a simple function (reducer) that replaces the state rather than mutating it. This gives the organizational benefit of keeping all state management code in a concentrated place. Has this caused any drawbacks for understanding where and when the state might be updated since MobX allows for scattered mutations throughout an app? Is testing more difficult especially in complex applications that might be drawing data from multiple sources asynchronously? Also, would this account for extra ramp-up time for new members to the team? Thanks!

Show all replies

The decoupling is quite easy to explain: in Redux you need to connect to the relevant parts of your state. The more your state tree differs from the component tree, the more often you have to do this. If you want to get the best performance possible, you should even adjust your state tree to exactly your components needs (see this twitter thread and test repo. This means that if you organize your UI differently, your state has to be adjusted.

In a lesser form this also applies to reducers. Where an action in mobx that updates just a todo only needs about the todo (e.g. toggleTodo(todo) => { todo.completed = !todo.completed }), the reducers also needs how the todo relates to the rest of the state tree in order to reproduce a new state, so you get something like:

toggleTodoActionImplementor(state, todoId) {
  return {
     ...state,
     todoId: {
        ...state[todoId],
        completed: state[todoItem]
    }
  }
}

(some libraries make this easier of course)

So changing the state tree has a larger impact here (for example when changing from a todo map to an array or vice versa, the toggle action is affected by this!)


Controllers (basically a collection of action methods) in general don't relate to MobX. Like the above toggleTodo does nothing MobX specific. It would work with MobX observables and plain JS objects equally fine. The only MobX specific thing would be wrapping it in the future action decorator.

Controllers might use autorun to manage some side effects automatically, like sending data to the server, but you can also keep doing this 'by hand', explicitly.

Models do relate to MobX, they have a bunch of @observable and @computeds around. But again you can design them without MobX in mind and add the decorators as afterthough when you build the UI for example.

So because MobX is less opinionated and more flexible in how you structure your state, it is easier to decouple. Things like @observer work with all observables, regardless how you got them into your component. So if your component gets it's data from the context or even from a singleton in the closure, it will work anywhere in your component tree, without needing to change other parts of your application or restructuring the state tree.

Does that help?

Reply to this…

If you get hit by a bus, or lose interest in the project, will there be anyone who's active enough to keep the project going?

There are a few people in the open source community that are familiar with the code base and have contributed bug fixes etc.

Besides that MobX plays an crucial role in the work of 3 development teams at Mendix. So although new features are mainly developed for the community (for example at Mendix we don't use babel transpilation or react native), Mendix will keep at least the lights on if I would be hit by a bus :).

Reply to this…

What are MobX performance characteristics ? How bad does it degrade (if ever) as the number of observers increases, say, to a few hundreds ?

Show all replies

Thanks Michel :)

Reply to this…

Load more responses