Frontend Data and State Patterns

Frontend patterns describe how the Arda single-page application fetches data and manages client-side state. They are the counterpart to the backend layer patterns under persistence, service, and api: where those govern how a Kotlin module owns and serves data, these govern how the browser client consumes that data and organizes the React state built on top of it.

These pages describe a target state — the intended design the frontend is moving toward, not the shipping implementation. Maturity is proposed until the target state is the shipping state.

📍 Why these patterns exist

The SPA solves data and state surface-by-surface today, and the same problem has accreted many answers: three coexisting state systems (Redux + redux-persist, ~15 contexts, and 40+ direct localStorage call sites), the same concern (auth, sidebar visibility) stored two or three ways at once, and — on the data side — ~27 hand-written client functions, 4+ parallel fetch stacks, and ~9 distinct client caches. Each page in this section replaces one axis of that sprawl with a single contract. See each page’s Current state section for the specifics.

📄 Pages in this section

State and Context Conventions — how to scope React context and state: place a provider at the narrowest file-path level that contains all its consumers, keep each context atomic, expose it only through hooks (never a raw context object), and persist through useLocalStorage rather than raw localStorage.

🔗 See also

Design Pattern Index — the parent catalog of architectural patterns.
Frontend Application Architecture — the broader Next.js / React / BFF stack these patterns sit inside.