MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses.
Michel, the author of MobX, is hosting this AMA to answer any questions you may have.
Object.Observe spec was pulled from ECMAScript. Many people praised React/Redux as an escape from the Observable model. So generally, when people see "Observables", they tend to stray away, if not simply for the appearance of them falling out of popularity. How are MobX's Observables different? Why bring the observable model into the React ecosystem?
Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!
💬 Ask programming questions without being judged
🧠 Stay in the loop and grow your knowledge
🍕 More than 500K developers share programming wisdom here
❤️ Support the growing dev community!
One of the core principles of Redux is that the state is read-only so that any updates to the state must occur in a simple function (reducer) that replaces the state rather than mutating it. This gives the organizational benefit of keeping all state management code in a concentrated place. Has this caused any drawbacks for understanding where and when the state might be updated since MobX allows for scattered mutations throughout an app? Is testing more difficult especially in complex applications that might be drawing data from multiple sources asynchronously? Also, would this account for extra ramp-up time for new members to the team? Thanks!