Simple reactivity in React with MobX

Hello everyone, I’d like to share one of the most convenient ways to work with reactive data in a React environment using MobX.

This article focuses on diving into and getting acquainted with MobX in the React ecosystem. If that sounds useful and interesting, then keep reading :)

Working with reactivity in React and handling reactive data is, in my view, always a rather labor-intensive process. Let me explain why…

All state in React has to be wrapped in use hooks, and we need various React wrappers to manage re-renders. For example:

const App = () => {
  const [input, setInput] = useState('');

  useEffect(() => {
    // do something
  }, [input]);

  return (
   <>
     <input value={input} onChange={e => setInput(e.target.value)} />
     <Child />
   </>
  )
}

const Child = memo(() => {
  return <div>child</div>
});

In this snippet, we use useEffect to perform operations whenever the input state changes, and that state itself comes from the useState hook. The parent component is wrapped in memo() to avoid unnecessary re-renders.

So, what do we end up with?

All business logic and processes in our front-end application get nailed to React and described through hooks. But was React created for this?

React was designed to make working with the DOM tree easier and cleaner—not to contain business logic.

What’s the alternative?

That’s where MobX comes in, offering a straightforward and ergonomic way to handle reactivity, which is exactly what we need in a React application.

Let’s rewrite the example above, but this time we’ll use MobX:

class AppViewModel {
  input = ''  

  constructor() {
    makeAutoObservable(this);
  }

  handleInputChange = (e) => {
    this.input = e.target.value;

    // do something
  }
}

const App = observer(() => {
  const [model] = useState(() => new AppViewModel())

  return (
   <>
     <input value={model.input} onChange={model.handleInputChange} />
     <Child />
   </>
  )
})

const Child = observer(() => {
  return <div>child</div>
});

In this version, we’ve removed React hooks as much as possible, leaving only the useState call that initializes state just once. All state-handling logic lives inside the AppViewModel class, and as a result, React now concerns itself solely with the view layer.

Conclusion

Using MobX in React projects provides frontend developers with a whole set of tangible advantages:

1. Minimal boilerplate code. You don't need actions, reducers, or complex configuration—just declare observable properties and methods, which significantly reduces development time and makes code shorter and cleaner.

2. Precise property-level reactivity. MobX automatically tracks which components depend on specific fields, so only what actually changed gets re-rendered, without additional optimizations like memo or useCallback.

3. Simple integration with MVVM pattern. The Store class essentially acts as a ViewModel: business logic and state live separately from the React component, which is responsible exclusively for rendering. This approach improves testability and code readability. Also MobX has open-source libraries like mobx-view-model for simple MVVM pattern integration.

4. Low entry barrier. Thanks to its object-oriented model, MobX is understandable to developers accustomed to working with classes and methods; the "observable → reaction" concepts are easier to grasp than Redux's strict unidirectional data flow.

5. Flexibility and scalability. MobX allows multiple stores, supports both mutable and immutable patterns, and easily integrates into existing code without imposing rigid architecture. This helps gradually "decouple" business logic from UI without global refactoring.

6. High performance out of the box. The reactive dependency tree and lazy computations (computed) ensure fast UI updates without manual optimization.

7. Excellent Developer Experience. Hot reloading, clear DevTools, and a rich ecosystem of helper libraries (mobx-react-lite, React MVVM, etc.) make daily work comfortable.

As a result, MobX transforms the React + MVVM combination into an easily maintainable architecture: the UI remains "dumb" and predictable, while all logic is concentrated in testable ViewModel classes. This is exactly why MobX remains a sought-after tool when you need to deliver features quickly without drowning in boilerplate and without sacrificing performance.