There's never been a better time to be a React or React Native engineer. The React 19 release feels like a watershed moment, and the React Compiler is coming hot on its heels. Its release will be yet another watershed moment for the community. But we still have to find ways to keep our heads above water as these changes make their way downstream.
Personally, I'm fielding lots of questions about MobX-State-Tree and React. People are asking me: "Should I use MobX-State-Tree with React 19?" or "Should I use MobX-State-Tree if I want the React Compiler?".
MST is still a great choice for React in 2025
The answer is yes; MobX-State-Tree remains a great companion to React. But I'll be honest - towards the end of 2024, I was concerned the React Compiler would leave observable libraries like MobX and MobX-State-Tree in the dust. These days, I'm much more optimistic.
We have some work to do before MST is fully compatible with the React Compiler, but that work has been de-risked. There is a clear path forward. My plan is to publish a React hook that implements the observer behavior for MobX-State-Tree before the React Compiler is put into general availability. If you want to use the hook today or follow along during development, (see the MST/compiler demo repository). For some more in-depth discussion, see my interview on Coding with JP, where we talked about the problem in depth, the path forward, and some thoughts on open source stewardship in general.
State management and modern React
I'm not the only state management library maintainer thinking about these things. Daishi Kato wrote a post about the React Compiler Era and what it means for Zustand, Jotai, and Valtio.
My two cents
I still love MobX-State-Tree, and state management libraries have become a special interest for me. But as React matures, more and more projects can get by without a third party state management solution. To me, this is a good thing for MobX-State-Tree. When MST users are people who really and truly need what MobX-State-Tree provides, we can hone the tool for its purpose, rather than expand it out beyond the scope of what makes it awesome.
My outlook is really inspired by Daishi's aformentioned post. For example:
"Aside from render optimization with selectors, the biggest benefit of Zustand is that its state exists outside of React. This is something React state with Context cannot address, so Zustand will continue to have a role."
This is something I wrote about in our React Context vs. MobX-State-Tree comparison article. React Context, Reducer, and State all directly rely on React. It gives them advantages (especially when it comes to React Compiler), but it also makes it harder to bring your state solution outside of React.
MobX-State-Tree doesn't depend on React at all. It doesn't even depend on browser runtimes. That makes it ultra portable. You can share MST types, trees, and utilities across frontend and backend code. You can move data all around your backend in Node, Deno, Bun, or any other JS server runtime, and then send it along to a frontend with ease. You can use it as a data modeling and validation tool without ever running npm install react.
The strength of the atom model lies in its declarative nature and composability, enabling the creation of a data flow graph for managing complex state.
Just like writing is thinking - the act of data modeling is also thinking. If you write clearly, you think clearly. If you have tools to model your domain and data clearly, you will build good software.
MobX-State-Tree, like Jotai, provides you with tools to express complex state as a tree, or as many trees, and conceptualize your application domain in a concrete way. When you undertake this exercise, you will understand your work better, and MobX-State-Tree will reward you with TypeScript annotations, runtime type safety, and a host of utilities for application development that mature applications often require. MobX is the engine, and MST is the luxury car around that engine.
Valtio has two main aspects. First, it bridges the gap between mutable and immutable state.
MobX-State-Tree has the same benefit here as Valtio. The code you write in MST looks a lot like object oriented code at first. But under the hood, it's quite functional. And while you can write actions that look like they directly mutate state: it's all syntactic sugar over a functional core that provides you with immutable snapshots, and JSON patches. When you use MobX-State-Tree, you can reason about your state as though it were mutable, but get the kind of functional programming guarantees and goodness that you want with immutable data.
Use MobX-State-Tree
Or don't! I'm a developer, not a cop.
I've said it in many discussions around the internet - I think state management is a well defined solution space in React these days. There are many good reasons to use any of the existing state management libraries. And I would be pretty trusting of new ones as well. The kinds of people who are writing new state management solutions are huge state-nerds, and they probably did a good job.
So at this point in the history of software engineering, your choice of state management comes down primarily to personal preference. What syntax, history, community, or logo vibes with you the most? Pick it and enjoy.
But if you really want my opinion? I think you should use MobX-State-Tree in 2025 and beyond. We will make sure it keeps working with React, even if we have to play a little catch up now and then. ;)