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?