Redux in Pieces
Last July I noted down my thoughts on Redux with some hints of the concerns that eventually led to Immuto.
I've since rediscovered my love of observable and computed via MobX, which is like the good parts of Knockout.js made even better by a very careful, thoughtful implementation.
Even so, this is not the same thing as abandoning immutability and purity. There's nothing stopping you using those techniques within a system of observables. Indeed bidi-mobx abstracts away all mutation and allows entire UIs to be declared from pure expressions. The data transformation is carried out by objects called adaptors that contain pairs of pure functions between View and Model representations. Only the user gets to do mutation!
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.
Eventless - XAML Flavoured
About four years ago, being so taken with data modeling approach used in Knockout.js, I wanted to recreate it for C#. At the time I wasn't actively using C# so I never got to really use it and left it alone.
But in the last year and a half I've written a few view models for a WPF application. The first time I did it I couldn't believe how primitive and laborious it was in comparison. So I started idly messing with Eventless in my spare time - mostly deleting stuff - to make it XAML-friendly.
Just like Knockout, and now MobX, it makes the process delightfully simple. You just declare stuff and it works!
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?