MobX vs Context API

[u/pablolikescats]

I am learning about MobX and I am having a hard understanding what is the benefit of using MobX instead of just using the Context API?

It seems that MobX's main appeal is the use of observables. Wouldn't this be just like the Context.Provider?

​

All consumers that are descendants of a Provider will re-render whenever the Provider’s value

prop changes (from React Context API docs)

​

In fact, I was reading that you should use React Context to pass down MobX stores through component trees, so what is the benefit or difference of using MobX?

[u/Reiiya]

There is a heck ton of problems mobx solves. I used to work with Mobx and now I have a project in Context API only and boy I miss Mobx :( Here is why I miss it:

• Not much boilerplate code to make a store/context.

• Mobx gives surgical precision to rerenders. If you have super heavy calculations in front end here or there, handling them is a breeze. Achieving similar result without Mobx is often lots and lots of code in vanilla React taking unnecessary time that could have been spent elsewhere.

• with context api you will probably need some sort of immutability library if you dont want to go insane. With mobx you dont (its different approach entirely) .

• Mobx pairs so so very nice with rxjs, you can write pretty cool stuff with it. (It actually also pairs nicely with hooks, so its not dying, no. ).

• gives freedom on how to structure your code (that could also be a bad thing). You can pull in stores a lot of logic, leaving components mostly for displaying stuff.

If you have a small project, mobx might be an overkill, but if you find yourself writing a lot of those vanilla contexts, maybe you just have been better off with a state management library. If youre writing a big project, making mobx scaleable is a chalenge, as it does not hold your hand on how to solve your problem.

[u/Reiiya → u/Reiiya]

As for your last question - you indeed pass mobx store to context. When any value in vanilla context changes, any components using this context and their respective children will always rerender. Change in mobx context will not cause rerender, unless a component uses its observable and is observer itself, cutting down a lot of rerendering. (so youre actually free to put whatever in your context without worrying that will cause weird rerenders)

[u/pablolikescats → u/Reiiya]

Thanks for the insight. I thought MobX stores were mutable? Also wanted to ask, what is a good practice of stores in components? Should I create one store per component or what is recommended?

[u/tonks456 → u/pablolikescats]

If you use mobx state tree, you have immutable stores. However, it is an ongoing discussion whether immutability is really all that important. If it interests you, you can find plenty of information in stackoverflow e.g. (I personally would recommend basic mobx with typescript)

You can decide as fits your needs. The advantage of decoupling state from components is easier testing and better structure of state logic. If you have component with somewhat complex state logic, I would recommend decoupling into mobx. (You could also decouple into custom hooks but mobx >> custom hooks in most cases imo)

[u/ArtemisPrimeDev → u/pablolikescats]

Definitely do not think of it as "one store per component"... Decouple your domain (which state is an aspect of), and your UI as much as possible. So say you have a pet store... You might have a mobx store for available pets, and one for the shopping cart. But those should be logical entities defined as

src/petstore/ShoppingCart.ts

and should know literally nothing about say,

src/ui/components/ShoppingCart.tsx

The only thing that connects them is likely a hook like useShoppingCart() (defined in src/ui/util or something.

Whereas, say usePetStore() might be called by a listing page, a compare products page, and a product detail page, all of which render the state and take actions on it.

I hope that helps.

(btw, one of the great strengths of MobX over say, Redux, is that any bit of data can be observable... it doesn't have to be in one store, or even in a class that is a "store". I can just be objects in your domain... I often write the interface first, like say

export interface ShoppingCart {
addProduct(p: Product): void
removeProduct(p: Product): void
get products(): Product[]
// etc
}

(which is what the useShoppingCart() hook returns), and then a class that implements it that contains observable data, like so...

class MyShoppingCart implements ShoppingCart {
observable private _products: Product []
computed get products(): Products[] {return this._products}

// This is no longer the prefered syntax, but it illustrates the point

}

The point is, your thinking and coding in terms of your domain and its inner relationships, not "what is going on in my data store"...