Why not replace mobx with zustand/recoil/jotai?

[Kiura]

I am curious why not replace mobx with something like zustand or alternatives that work better with typescript?

Or at the very least why not use classes-based mobx rather than type.model() approach?

Another question, why do we need to use mobx-state-tree? isn't mobx capabilities enough to handle all state-related features?

Great boilerplate, BTW!

[frankcalise]

Hey @Kiura , hope you don't mind but I moved this over to the Q&A Discussion area for visibility since it is less of an issue.

We internally here at Infinite Red use MST primarily, so that's why it is in our boilerplate. We are discussing alternatives as the days go by, but this boilerplate is mainly for us, but we're happy to pass it on to the community as well! So when we get over to possibly picking an alternative that we like, it would change then.

You could (and likely should 😉) adapt the boilerplate to your liking/needs and use whatever state management library you see fit. In fact, we'd welcome it and appreciate it if you wrote your steps over on the Ignite Cookbook to help others!

[Kiura]

Hey @frankcalise, Thanks for moving the "issue" to the right place!

Thank you for the explanation of why MST is used in the boilerplate. However, would be nice to know the answer to the other 2 questions too 😅️ maybe you or someone else can address those:

1. Why not use classes-based mobx rather than type.model() approach?
2. Why do we need to use mobx-state-tree? isn't mobx capabilities enough to handle all state-related features?

I did change the state management library, but the problem with that is it is a little inconvenient whenever I try to upgrade the boilerplate. For now, I reverted back to MST, as it does the job, but it would be nicer to have a first class typescript citizen :)

Also, I had no idea there was a cookbook, I will definitely contribute if I decide to go back to another state management library.

[ryskin]

I'm not a @frankcalise but I question without an answer a long time, so I would answer for him if you don't mind.

1. Why not use class-based MobX rather than the types.model() approach?

• MST builds on top of MobX and provides a more structured approach to state management. While class-based MobX is powerful and flexible, it lacks certain features that are beneficial in large-scale applications. Here are a few reasons why MST's types.model() approach is preferred:

• Structure and composition: MST allows you to define your application state using a tree-like structure, where each node represents a model. This hierarchical structure makes it easier to manage complex state interactions, relationships, and composition of models.

• Snapshot and reconciliation: MST provides built-in support for taking snapshots of your state and reconciling them. This can be useful for features like time-travel debugging, server synchronization, or undo/redo functionality.

• Action-based state transitions: MST encourages the use of actions to modify state. Actions provide clear intentions and better traceability, as they are explicitly defined and managed within models. This makes it easier to reason about state transitions and track changes.

• Middleware and plugins: MST offers middleware and plugin support, allowing you to extend its functionality. This can be useful for features like persistence, routing, serialization, or dev tools integration.

2. Why do we need to use MobX-State-Tree? Isn't MobX capabilities enough to handle all state-related features?

• While MobX is a powerful state management library, MobX-State-Tree enhances its capabilities by providing additional features and structure. Here are a few reasons why MST is used alongside MobX:

• Immutable data structures: MST leverages structural sharing and immutability to optimize performance and make state updates efficient. It minimizes unnecessary re-renders by only updating the parts of the state that have changed, which can be particularly beneficial in large applications.

• Structural typing and static analysis: MST integrates well with TypeScript and provides static typing for your state models. This enables better type safety and helps catch potential errors during development, allowing for more robust code.

• Time-travel debugging: MST's built-in support for snapshots and reconciliation allows you to easily navigate and inspect past state versions. This can be immensely helpful in debugging and understanding the state flow of your application.

Developer tools and ecosystem: MST has its own set of developer tools and an active ecosystem around it.

[ilterugur]

I've used mobx-state-tree over 2 years and I actually love it but its type system is making things very hard especially on circular model dependencies. Nowadays, I'm planning to use to zustand on my new projects with "zoov" (for module system like mst) & some other integrations that provide features of mst. @ryskin @frankcalise is there any performance benchmarks or some explanation about mst vs. zustand/jotai? Which is more performant?