Mobx: Simple, scalable state management
github.com
github.com
It is one thing to put together a set of observations like the Flux architecture that makes a lot of sense and simplifies app development. It is entirely another thing, as we have seen in the past couple years, to implement an elegantly simple and clean expression of that. It is deceivingly simple but in my experience even though it seems to have a bit of magic behind it (which I generally dislike) Mobservable now MobX is probably the simplest and ultimate progression of state management for React and other like apps. It is the reason I stopped development on my own state management system. Once I envisioned how to remove even more boilerplate even more odd conventions I came to realize Mobservable achieved it all, and the performance was just as good too. It really deserves the attention of any serious app developer and it's not limited to React either.
0. http://stackoverflow.com/questions/32352982/how-to-put-metho...
On the other hand, Mobx also did take a bit of time to figure out its API, but once it was clear, it was very straight forward how to use it and explaining it to others was also painless. No need for extraneous action-creators/reducers ceremony and no opinionated way of what kind of data I can use, or gotchas when that data is mutated.
Action creators are also a mere convention and are not essential to Redux. You can dispatch action objects inline if you prefer. Reducers do add some ceremony, and I wrote up a little on the reasons here: https://news.ycombinator.com/item?id=11187727
Glad you found something you like though! No solution is perfect, and it’s all about the tradeoffs you care about.
We've introduced it to one of our project 4 months ago and our state management became as simple and easy as it should be with React. No boilerplate subscriptions, no helpers that modify normalized data, no endless re-renders on every state change and very easy to understand concept for new developers.
We literally stopped worrying about the state though it took some time to rewrite the app.
"With mutable data structures, it is trivial to guarantee that there is only one version of a certain domain object in memory."
I'd like to know how this mutable values can be tracked while immutable values can just equality check. I'm currently learning ClojureScript with few simple projects, and its immutability both pleases me and drives me crazy.
Though I can agree on his point that Flux (and Redux) do take over your application. I'd definitely like to use something else with my next React project if possible, and Mobx looks it could fit the bill.
Also, SurviveJS is a good React and Webpack book that's continuously expanded and adapted to use different libraries (like for Redux and Mobx). You should buy it!
You can also wrap some code into special autorun function, that will track what observable data was accessed, and when that data changes, that code will be called again.
But wait, there's more =) It works with arrays, objects and other types, check out the docs!
That statement refers to the fact that you loose (automatic) referential integrity when you start using Immutable data.
Take the following scenario: you have an app with Users and Tasks. Tasks can be assigned to users. When you express this using immutable data you have two problems. The first one is linking tasks to users. If you would link Task1 to Person1 and after that change the name of Person1, you would get a new person, Person1v2. However Task1 would still refer to the old, unmodified Person1, so then you have suddenly two versions of the same person in memory. A fresh and a stale one. In other words, you lost referential integrity.
Now the usual way to fix is, is to not use real references, but to normalize data and store only a key to the person. The effect of this is that you have to always lookup the person related to Task1 again from the state tree. If you have a reference (variable) to that person somewhere, make sure it is short-lived because you won't know if you are still referring to the correct one.
The second problem is that when you have correctly normalized your data and always do fresh lookups, you will still not know _when_ to make these lookups. If you have a TaskView that renders the name of the related Person, and the related person changes, the TaskView will not detect this automatically. The related person is not even a prop of the TaskView component so pushing a new state tree through your app won't repaint the TaskView if you are using PureRenderMixin (which is usually the purpose of using immutable state trees in the first place). For that issue there is a solution as well; you can introduce selectors (or lenses) that query the state tree to detect if the relevant person is changed. So now we already have three new concepts (no refs, normalization, lookups, selectors) to solve a problem that mutable data doesn't have in the first place.
By using mutable data and observing it using MobX these problems are solved (imho) more elegantly: references are never stale because if you would modify Person1, Task1 would still refer to the 'latest' person1, because it is still the same object. Secondly, because it is the same object, fine grained object observers can be established automatically for you, making sure the TaskView gets updated as soon as something relevant changes. This means that you have less concepts to learn and maintain (no copy-on-write, no need to assign a unique key to everything, no data normalization, no lookups, no selectors to make sure your views are always in sync with the state). That saves a significant amount of boring yet error prone work when your application's state model becomes more complex than the average Todo app.
So that is the long story behind that short comment. I hope it clarifies the statement!
I have an project coming up that's going to integrate several previously separate apps into one. I can't imagine how I would combine their state into one with Redux. With observables I could just get the app observe their state changes and affect changes in others without contained apps being aware of each other.
This approach enables our partners to write plugins that are not only simple to write, because they can just work with 'plain' javascript classes and arrays (and don't need to learn the whole, for example, redux architecture), but which are also really easy to integrate in our visual tools. Our UI stays always efficiently in sync with whatever mutations plugins make. In an architecture with explicit subscriptions, events or selectors this would be a lot harder to achieve.
If something is mutable in real life, such as a child's height, then each measurement (sample) is timestamped, and it'll not lose its validity for this timestamp. This is called valid time. Beyond this, the wall time of the entry may be recorded as well, called the transaction time in bitemporal terms. It is possible that the reading was erroneous or entry was fat-fingered, so a new tuple is created with the (now hopefully) correct weight with the same valid date but a new transaction date. So, again, a new, immutable, persistent entry was made.
Databases such as DB2 implement features of SQL:2011 such as temporal tables. They allow the storage of such immutable entries and provide the collapsed (temporally resolved) views. Also, PostgreSQL uses the implementation technique called MVCC which purposefully does the thing you seek to avoid: via Multiversion Concurrency Control, preserve the snapshotted relations as they were at the beginning of a transaction, to ensure Isolation of ACID in the face of concurrency.
To me it seems that it's perfectly okay and desirable for observables to stream immutable pieces of data, i.e. values, while not engaging in an overly early binding to an optimization strategy that sacrifices the temporal aspect at the earliest moment - especially in a tool that claims to be a version of Functional Reactive Programming in its one-sentence summary.
It is possible to have reducers (scan) that collapse a primary, immutable measurement stream into required temporal resolutions. For example, one such resolution may do away with both valid time and transaction time, just emitting changes, and maybe some 'last measured' or 'last updated' time. Some other reductions may yield analytics, for example, to visualize how often certain values change, or how often values are revised due to reading or entry error. Also, even the most elementary reductions such as key=child may carry with them the relevant timestamps.
Deeper analytics may apply some applicable smoothing of the data over time, e.g. a child's weight might be smoothed via LOESS or just cubic splines. Also, the velocity of weight gain may be modeled as the differentiation of the weight over time. We're walking into proper continuous time FRP: this differentiation might be performed via some proper numerical technique e.g. using a five point stencil with backward finite difference.
I used the child weight as an example, but it's quite similar if one implements game-like user interactions where timing matters a lot, or consistent views over financial data streams on a trading platform.
All in all, I don't immediately see how mutability would add utility in this context, but I'm not familiar with MobX constraints which is why I made more general comments which are not new to you but might be interesting to someone else.
Edit: I have been enjoying similar reactiveness using ractivejs but it hasn't managed to split the reactive data from the view logic.
With Flux/Redux I have control over when and how data is updated, but that is not the case here. What are the performance characteristics? Is there a limit to the number of observables before performance suffers?
There is also the question of routing and history. What is the best way to use observables in a single-page app along with routing and history (i.e working back button)?
The size and complexity of UIs have a natural limit because of screen size and usability, but the amount of data you use to generate a UI has essentially no natural upper limit.
Pete Hunt gave a talk on exactly this almost two years ago. https://www.youtube.com/watch?v=-DX3vJiqxm4
Just scan through my blog https://www.mendix.com/tech-blog/making-react-reactive-pursu... to see how naively fully re-rendering your application upon each change makes your application an order of magnitude(!) slower.
Data size isn't usually an issue for MobX. The reason for that is that it will automatically suspend all derivations which are not actively in use somewhere (in other words, not visible currently in the screen). We have full blown visual editors that have hunderd thousands observables in memory. Nonetheless they are fast enough to perform drag and drop actions using observables, where not only the dragged item is being moved, but also all the connectors connected to it, as they observe the item being dragged.
A full rerendering requires that all the functions be called. Indeed, there's a natural limit to how much data is updated on the screen (well, unless we use canvas or WebGL but I digress) but the render functions themselves may be expensive and wasteful to rerun, especially if there is inferrable knowledge that the nature of the change doesn't warrant a recalc in some branches. Even if it doesn't cause jitter, it may be wasteful on mobile battery.
Why do I think render functions may be expensive? Official React documentation steers people toward having stores that keep 'primary truths' rather than things that can be derived from them via pure functions; and it suggests that these calculations be part of the render functions. It works, it's functional and it's clean. But you potentially run a lot of calculations, depending on the domain. With plain FP, much of this will be wasted as causing no visible change. Not only this, but the needlessly executed render functions do generate virtual DOM snippets; and these snippets do get scheduled for DOM diffing. All these add up to what is, in my experience, a jank-inducing difference. I even introduced memoization, but just DOM diffing alone is significant on a sizeable app (which makes sense as there may be an order or two magnitude difference between VDOM elements that exist vs. ones that really may change).
With observables, e.g. reexecuting a calc or regenerating a DOM snippet, control is finer grained, without the manual and possibly erroneous performance optimization hinting approach known as shouldComponentUpdate. I had cases when blind function reapplication (memoized or not) caused jank on the desktop while observables were smooth even on the mobile.