What is MobX?
Who uses MobX?
Why developers like MobX?
Here are some stack decisions, common use cases and reviews by companies and developers who chose MobX in their tech stack.
The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.
Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.
By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.
We are always building new features and replacing old code at StackShare. Lately we have been building out new features for the frontend, and removing a lot of old jQuery code (sorry jQuery but it's time to go).
As we've moved towards the above tech, its really made smashing out new features and updating legacy code super fast, and really fun!
Frontend choice was basically pre-ordained to be React. Seems like a strong choice on merits alone, plus I needed to learn it to stay current. I never liked Redux.js from the first time I tried to work with it, but a mate had recommended MobX and after watching a few videos I felt like I could fit the mental model of hit in my head. Using Material-UI which is a great timesaver and make sure I throw a few bucks their way every month via the open source collective.
Defaulted to Rails with PostgreSQL just because that's where my past strength as a dev had been. First prototype was in Go but was struggling a bit with the quality of libraries I needed so I went back to old faithful.
As soon as TypeScript was supported by default in Create React App I ported everything over. That combined with swagger code gen has given me really good type safety from the API boundary and above. I semi-regret the Go/Rails decision because I miss the type safety despite pain points with libraries.
I will probably look to flip back to Go gradually (probably via lambda) at a point where it makes sense for the business.
Some of our existing pages use MobX however we decided to stop using MobX for new work for a few good reasons:
- It forced us to use an experimental language feature (decorators)
- We went all-in on GraphQL and Apollo to manage our data and local state.
For all the places where we don't store state in Apollo Client, we use plain old React and hooks (
useContext). Our first choice in state management it to have all state stored in Apollo keeping local state accurate by using mutation updates, client resolvers, and local cache.