What would be the benefits and tradeoffs of moving to mobx instead of mst?

[1mike12]

The more I use mst the more frustrated I get. It looked really great in the toy examples but with a slightly more complicated real world scenario I find myself getting tripped up everywhere.

Everything I see on vanilla mobx seems really great.

Things I get:

• No strict Id in one place on the tree errors and having to manage references
• Using classes
• Better performance

The things I would lose:

• Replayability*
• Hot reloading *

But in reality there's ways to add both replayability and hmr with some extra work from what I read.

For anyone who's done both for RN, what are things in missing?

[jamonholmgren]

I’m playing with MobX by itself on a side project. I’m not missing that much, but then I’m also using Firestore as a back end so it does a lot of the heavy lifting.

I’m more than happy to rethink using MST as our primary state management system, but whatever approach we take should be well vetted. So that’s one reason I’m doing this side project with just MobX.

[1mike12]

oh I wasn't suggesting to replace ignite w/ MST, I think it's really well proven. I was just drawn in by the allure of vanilla mobx after briefly looking at it and had to mentally pump the brakes because I thought, it can't all be good, there must've been a reason you guys went with MST

[1mike12]

Can you speak to the things that you are missing compared to MST?

[Kiura]

I was thinking the same, mobx seems to be the best of both worlds and I believe you can have typescript.

[jamonholmgren]

Primarily, the things I'd miss are the structure, references, async actions/flows, onPatch / onAction, and I'm just overall used to MST so it's how I think. Still thinking it through.