json-mobx - Like React, but for Data (Part 2)
This is a follow-on to MobX - Like React, but for Data, in which I noted the parallels between MobX and React.
computed"renders" a "view" of some data, and automatically updates when the source data changes. Like a React component, except generalised to cover any data, not just Virtual DOM.
observableis like the
setStatefacility in stateful React components, except that its automatic ability to notify
autorun) observers works by spooky "action at a distance" and so doesn't have to take place inside one component.
But this still leaves one major feature of React unaddressed, and that is reconciliation. What is this about, and how can it be useful in a more general way in MobX?
Box 'em! - Property references for TypeScript
This concerns quite an abstract, simple building block, but it is a neat tool for use with React and MobX. In MobX there's a utility
observable.box (docs). But I don't want to use that create all my properties and have to put
.get() after every read access. I want to use the cool
@observable decorator and just fetch my properties directly, and assign new values with
=. What I need is a way to box a property. Oh, and it better be statically type checked in TypeScript.
For the overall idea, see the project page, or just look at the takeaway:
MobX - Like React, but for Data
Catching up on blogged opinions about MobX and where it fits in (especially in relation to Redux), I see much confusion. There is a suspicion of it arising from fear of mutability. It has none of the frameworky ceremony of Redux, and that seems to cause anxiety in some.
Even its defenders seem a little apologetic, like MobX is okay despite the heresy of allowing data to be mutable and object-oriented. The great Basarat even humorously welcomed me to the dark side!
I'm fine with being on the edgy team. You'll usually find me in my leather jacket and shades, posing on my parked Harley Davidson and chewing on a matchstick, intimidating the townspeople. Why? I don't have to explain myself to you, lady.
What's good about Redux
Redux is based on series of really simple what-if questions:
- What if all the data in your app was immutable?
- Okay, now it's stuck. But what if there was only a single solitary mutable variable holding the complete state for your entire app? To change any bit of state, you just assign a slightly different immutable tree to that variable.
- And what if the only way to mutate the state was to create a POJO describing a high-level action, and dispatch it through a single giant processing system, describing the change to make?
A number of interesting advantages follow from sticking to this discipline. It's ideal for ReactJS. You can log everything your users do and replay it, stuff like that. You can store the state snapshots, or just the actions, or both. You can recover your app by loading in an old snapshot and then playing the recent actions to bring it up to date. If you want to know the complete story of how your application ended up in the state it's in now, you've got it. And aside from these nice capabilities, it's worth remembering a lot of bugs arise from fiddling with mutable state at the wrong time. Who needs that?