Things we mush together because React wants us to

4 August, 2020

For the last year at Instinct, I’ve been working on a big consumer-facing React app that talks to an Elixir backend via graphql queries. Growing React apps seem to share a set of dependency problems (not the npm kind of “dependency”!), and some of them are the result of mixing conceptual models together.

We’re trying to represent and program many different things, often in the same code:

These are mostly interdependent, but React wants to handle all of them, whether in single components or in a layer cake of separate ones. React wants components to have colocated, or at least directly nested, state and markup, and fighting that can cause poor performance and confusing state loss.

We could settle on some questions to ask of our codebase, though, and look at the architecture through new lenses as the app grows: Which of these models can be separated? Which, if any, can be distinct, accessed with an API layer? Which are best modeled with state charts? Which, if any, can be moved outside the React app?