Two years of using mobx for state managment

I’ve been using react for a long period of time now and have always leaned on finding an alternative to redux which would have less boiler plate and be cleaner and simpler to read. Few years back when i had to build an entirely new product from scratch, i took the opportunity to test out mobx and redux for a sample application and surprisingly, i found mobx to be way more simpler and logical in the way it approached the problem. After many considerations and discussions on scalability, reliability, ease of use, adaptability and grading them, we adopted mobx for state management. Its now been well over 2 years since we adopted mobx and i thought it would be a good idea to share my experience on this state management library and how well it worked out for us.

Major tenets:

  • Scalability
  • Reliability
  • Easy of use
  • Adaptability

Note: At the moment of writing this, you might be interested in checkout out mobx-state-tree too which further enhances mobx capability. Click here for the philosophy of mob-state-tree.

This blog is not about teaching mobx but showing you how the application looks and how easy it is to scale and add changes

The package structure we use might look familiar to your standard web application with the addition of Stores that mainly handles the entire application data. In simple terms though, these store are just classes calling api’s and storing application data in models.

Look at defining data stores example to know more on how stores are structured in mobx.

Below is a sample of how stores and model look like for a dummy twitter api call loading tweets.

Domain store:

Domain store which would handle all your api calls. In a complex application you could have multiple stores combines together which calls various sets of dependencies and defines error and pass scenarios for api calls.


This defines the Model which will be used by all your jsx files. This will ideally do all the field mappings and even if api responses changes in future you just need to map the changed fields.


This is the main tweetView which renders the tweet.

Straight out of the box you would observe the sheer simplicity of the code interms of clarity and lack of boilerplate. Using @ anotations handles all the linking and binding and the best part is, its performant and scales well and also has smaller size when compared to redux and combinations of addons which goes along with redux just to reduce the complexity.

What we observed:

Having multiple stores for each of service clearly works and scales well. Its easy to adopt and many of our new developers have observed that they were able to make changes to the system easily.

  • One of the huge benefits of mobx with respect to performance is that rendering is kept to absolute minimum. Mobx precisely tracks dependency trees and maps whats changed
  • Clarity of code — Just looking at the code clearly justifies the intent. Most of our team who had to at times work on UI were easily able to analyze the code even though they had minimal front end understanding.
  • No additional libraries needed to be added to normalize data into any form or handle any complex data structure.

Did we miss immutability:

Not at all. In-fact, we never saw any scenarios yet which would require us to have immutable states. I do not want to talk about wether immutability is a good attribute to have or not, but my observations had been that i did not need it, at-least for most of the applications i’ve built. Unless i see a specific use case where i feel that immutability makes sense, i do not feel a need for it. I have a contrarian view on immutability and i do believe quiet a few people have these views as well. Here’s a good thread in stack overflow to read on this.

What’s something i missed from redux-

My experience with redux had not been too much but i’ve worked with it good enough to understand its nuances. I would say that since its very opinionated it enforces a certain way of doing things. Mobx is not opinionated so developers have to make sure that they set a design in place for others to follow.

Though i hear predictability and tracking changes is much easier due to immutable data sets, i have not yet faced these problems with mobx and am able to track changes on the application fairly easily as well.


Since most of the logic sits in your store and models. Testing becomes super simplistic. Especially if you test your stores and models you would mostly cover all major use cases for your application.

In case of complex applications with multiple store and many api calls, i was able to mock all of these apis to return different scenarios and test my business logic. I took the opportunity to write a small library which could be used with jest to mock multiple levels of api’s. Here’s my writeup on how to use it. Click here for link to the npm package.

If you enjoyed this article, do show your support with a clap. Would mean a lot and it helps other people see the story too.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store