Jim Nielsen’s Blog
Theme: This feature requires JavaScript as well as the default site fidelity (see below).

Controls the level of style and functionality of the site, a lower fidelity meaning less bandwidth, battery, and CPU usage. Learn more.

Remix, React, and State

I was reading Josh Comeau’s article “Why React Re-Renders” and this sentence got me thinking:

React's “main job” is to keep the application UI in sync with the React state. The point of a re-render is to figure out what needs to change.

In React, a simple component tree might look like this (borrowed from Josh’s incrementing counter example):

    <BigCountNumber />

Whenever a piece of state changes, React reconciles the old state with the new state and figures out where in the component tree it needs to re-render UI elements.

What that means — and what might not always be immediately obvious — is that if you don’t store and modify your application’s state in React, then React won’t be of much use to you. React needs state to be useful.

React state, however, is ephemeral: it lives and dies with the browser tab unless you persist it somewhere. That means it’s up to you to keep React state in sync with your application’s data, i.e. the source of truth.

To reframe Josh’s statement: React’s main job is to keep its state in sync with your application’s user interface but not your application itself. That’s up to you.

React makes it easy to fetch data, store it as state, and render UI from it. But as soon as you need to pull that state back out of React, persist it to a database somewhere, and then synchronize/validate it back into your application — well, you’re on your own.

Hand drawing of a browser on the left, a server + database on the right, and a network in between them. It has the word “YOU” connected to the network transaction happening, indicating you are responsible for syncing state between React and your application.

Enter Remix: Remix handles the full state lifecycle for you while React is an implementation detail to reconcile state with the DOM.

Whereas React’s job is to keep its own ephemeral state in sync with the UI (on the client), Remix’s job is to keep your application’s state — server logic, database data, etc. — in sync with the UI across the network (on both the client and server).

Hand drawing of a browser on the left, a server + database on the right, and a network in between them. It has the Remix logo connected to the network transaction happening, illustrating how Remix helps keep application state in sync from client, across the network, to server + database.

For illustration purposes, it’s almost like you can think of Remix’s component structure as a tree where your client-side components (which are implemented in Remix today with React) get wrapped in <Server> and <Network> components. When needed, and through the use of Remix conventions, state changes in nested components (i.e. nested routes) propagate all the way up through your client-side application, across the network, and to the server, where the state change is handled and then reconciled back through the entirety of your application — from database to server to client and back again, all across the network.

        <BigCountNumber />

A change to state in <BigCountNumber> can propagate all the way back up to the server for persistence, then be validated back down into itself through the use of Remix’s data conventions (e.g. loaders and actions). You don’t have to think of your React app as a separate and distinct entity that must be kept in sync with something else.

Because Remix handles state changes like this end-to-end, React becomes an implementation detail for reconciling state changes in the DOM at the level of the browser. In theory, any other “view layer” framework can take over this job (and probably will in the future).

In this way, using React state in a Remix app becomes reserved for ephemeral state that can die with the browser tab, e.g. state needed to produce effects in the UI.