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:

  1. It takes a query function. This lets you keep a central group of queries on your data, rather than spreading them all over your components.

  2. It exposes a React context that includes your 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.

    function Person({person}: {person: Person}) {
      const {state, query} = useAppContext<AppState, AppAction, QueryFn>();
      const pets = query(state, {type: 'getPersonPets', personId:});
      return (
          {Pets: { =>", ")}}
  3. It creates a poor man's version of something David Nolen talked about recently: programming environments that retain their context. It automatically saves your blob of state to 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.

  4. It exposes 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.

Maximizing overall speed

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).

Part of Mary Rose Cook’s research to build software quickly