Why should I use MobX State Tree over vanilla MobX? It seems like any time I read about MobX, MST is mentioned in the same place. Is anyone actually using just MobX by itself?
Probably too general of a question...
Why should I use MobX State Tree over vanilla MobX? It seems like any time I read about MobX, MST is mentioned in the same place. Is anyone actually using just MobX by itself?
Probably too general of a question...
Actually, MST or MobX State Tree is a very descriptive name if you think about it.
MobX is fast, but doesn't provide any organizational structure out of the box, therefore centralized operations like taking snapshots of the whole state, restoring the state from the snapshot, auto synchronizing separated stores, time travel or hot reloading are either not possible or up to developer to support.
MST supports all of the above mentioned (and more) out of the box by organizing separate stores into a single tree of interactive and interacting nodes.
Central in MST (mobx-state-tree) is the concept of a living tree. The tree consists of mutable, but strictly protected objects enriched with runtime type information. In other words, each tree has a shape (type information) and state (data). From this living tree, immutable, structurally shared, snapshots are automatically generated.
However all of this comes at some cost and MST in general is somewhat slower than pure MobX. So if you do not need those features, do not hesitate to use just MobX.
Yes, many people use "vanilla" MobX -- it has immense value all by itself. The core concept of leveraging "observable" state is the killer feature of MobX. For me, using it along with React, it has enabled me to fearlessly handle large amounts of connected data in the browser, without worrying about "refresh" issues or "calculated value" issues.
The extra layer of "MST" just adds more (opinionated) structure. ( good if you like being told what to do ;) It is more like a "Redux"-style state manager, where state transitions are clearly defined, and things like time-travel are possible. For me, MobX by itself solves a lot of problems, and I suggest that anyone new should stick to "vanilla" MobX, and not even think about MST until you really appreciate what you are getting from MobX itself.
MobX offers transparent, point state management in place. Simple, efficient, and direct.
But Redux has loads of mindshare, so MST.
MST wraps the core MobX reactive engine in the Flux pattern: indirect, non-specific, and requiring massive boilerplate. None of the claimed benefits translate to programmer effectiveness.
If it were my call, I would go with MobX or, if I love boilerplate, Redux, which will have more tooling.
I'm not gonna go lengthy comparison.
En bref, MobX is unopinionated util lib, while MST is an opinionated solution built on top of MobX.
If you're new to MobX, just use MST. Get comfy to its concepts first, then you decide on your second project :)
Bare MobX is incredibly flexible and can be used very creatively. But you got to understand what you're doing with it. It's a bit like black magic, powerful, but need to be really careful.
I am using MST for react native app. MST references are also very handy to define the data model. I choose MST over mobx for references feature.
It is generally recommended to use MobX State Tree (MST) instead of vanilla MobX when you need a more structured and opinionated approach to data modeling, better performance, or features such as snapshotting and time-travel debugging. However, if you don't need those features, you may find that vanilla MobX is sufficient. Additionally, if you have an existing MobX application, there may not be any need to switch to MST.
© 2022 - 2024 — McMap. All rights reserved.