Elevator Pitch
MobX is a state manager that makes observable JavaScript objects. It’s a cool alternative for apps where Redux feels a bit too heavy. We have some great patterns showing how to use MobX to add new async ops- with all data, in progress, error state captured- to your app in just a few lines of code.
Description
Conventional wisdom tells us to use Redux for React- it scales really well and is ostensibly pretty intuitive after you’ve worked with it for a while- but some of us look at all the heavy boilerplate, thunkers and other exotic middleware, and other things already flying around in a basic todo app, and can’t start to image when things will start to make sense. MobX is a state manager that’s basically everything that Redux isn’t. It’s not functional or immutable, and pretty unopinionated about how you structure things. Instead it makes it very easy to build Plain Old JavaScript Objects (POJO’s?) that any React component can watch for changes and re-render accordingly with the addition of just a tiny decorator at the top of the class. Here will learn how MobX works, what a typical observable-enabled class looks like, and then dig into some battle-tested, highly-reusable MobX patterns for async operations, pageable lists, and change-tracking.
Notes
Technical requirements: projector
Why I can/ should talk about this: I’ve used MobX extensively in building Coach Messenger (https://play.google.com/store/apps/details?id=com.nudgecoach.nudgecoachmobile&hl=en) when we determined myself and the rest of the team just weren’t that into Redux. The greatest success was the building of reusable classes for common async patterns with deceptively large amount of states (once you factored in first load vs. subsequent refresh, error handling, what to do on logout, etc.) - refreshable lists, pageable lists, async operations, and others. We got it to the point where you could pass an API call to one of these generalized components and it would construct all of this state around it, and our stores became very simple and highly-testable as simply groupings of these higher-order components.
I became really interested in presenting highly-opinionated, specific patterns for building state from a real app after a couple of experiences at CodeMash 2018, seeing presentations that kept things very idealized, and talking to developers afterwards who felt very conflicted about what goes in Redux vs what goes in React state, etc. It seems like we could all learn something, regardless of library used, by sharing a bit of what it looks like when you’re forced to pick a way to do it because you need to ship and your app really needs all of these details in state that the simple examples gloss over.
The basic structure would layout how MobX works, setting up a basic example with an observable, action, computed property, and a React component observer. I’ll touch on a few minutes on how it compares to the structure of Redux. The bulk of the talk will be on the components we built - the refreshable list, pageable list, async write operation, with some introduction to the mobx-utils helper, which have contributed to the components we built with a Promise implementation whose progress you can actually observe. Also in the utils is a neat ViewModel component that takes any MobX-observable-enabled object and adds change tracking to it.