Two-headed boy With pulleys and weights
I've been making a lot of prototypes in React. For a new Automations feature we're working on at Airtable. And for some of my Build Code Faster experiments.
As a result, I've been looking for ways to build prototypes in React more quickly.
One helper I've built is Direct React which lets you edit the styles of your React components using a UI.
Another helper is a new, tiny library I wrote: Substantiate.
Mostly, Substantiate is just a good old useReducer
hook. A way to create a blob of state on which you can call mutators. But it adds some properties:
query
function. This lets you keep a central group of queries on your data, rather than spreading them all over your components.state
, your dispatch
function, and your query
function. This means you can materialize these items in any component without having to pass them down through the component hierarchy.localStorage
and reloads it on refresh. This means that after a code change your UI state will be restored and you won't have to do a bunch of clicking and typing to re-create it.state
, dispatch
and query
at window.substantiate
. It's often much faster to figure out the system state by poking around on state
than by running a debugger or printing things out. And if you need to make any quick edits to the system state, you can use dispatch
, or even hot edit state
.In programming, there is a focus code quality. The idea is, if you don't prioritize quality, though you might be able to build faster now, you'll slow down later.
A better focus is on build speed over the length of the project. This helps put programming wisdom into the context it needs. Advice like, "Write tests", or, "Don't duplicate code" becomes more useful once you think about the build arc of the project. Like, "Will this project last long enough for tests to pay off?"
Substantiate prioritizes speed now over speed later. For example, you'll need to work harder than normal to build reusable components because every component that materializes query
or dispatch
is tied to the project and is going to be harder to test.
But it also aims to keep the project viable longer term speed by centralizing the domain logic (the dispatch
and query
functions).