From Ember to React, Part 2: Baby, Bathwater, Routing, etc.
Abstract: Last time, which was too long ago, I explained why Ember is terrible and must be burnt to the ground. This time I'll begin to explain why it's not actually all terrible and we should run back into the burning building to rescue the good parts. This will lead us to answer the question: can React Router be used with MobX?
From Ember to React, Part 1: Why Not Ember?
Abstract: We just replaced our entire Ember codebase with a new one written in React, TypeScript and MobX. It was a pretty engrossing couple of weeks. THIS IS OUR STORY.
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.
- A
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. - An
observableis like thesetStatefacility in stateful React components, except that its automatic ability to notifycomputed(andautorun) 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?