Organize by responsibility
A large React application becomes difficult when components own fetching, transformation, mutation, layout, and every possible error state at once. I prefer boundaries that make each responsibility visible.
Route-level code coordinates. Domain modules own business operations. Presentational components render stable inputs. Shared UI primitives stay deliberately boring.
State should have a home
Server state belongs close to the data access layer, URL state belongs in the URL, and ephemeral interaction state belongs in the component that owns the interaction. Global state is reserved for genuinely cross-cutting concerns.
This structure makes deletion easier. A feature can leave without taking half the application with it.
The test
If a developer can explain where a value comes from and who is allowed to change it, the architecture is doing useful work.
A practical ownership map
Route components should coordinate data loading and navigation. Feature modules should own commands and domain-specific view models. Shared components should receive explicit props and avoid reaching into feature state. This is less about folder names than about keeping change local.
flowchart TD
A[Route] --> B[Feature container]
B --> C[Domain query or command]
B --> D[Feature view model]
D --> E[Shared UI components]
C --> F[API and server state]
State placement in practice
An open modal is local interaction state. A selected filter that should survive a refresh belongs in the URL. A list fetched from the server belongs in a cache or route data boundary. A permission is server-owned data, even if the UI uses it to hide a button.
function OrdersPage() {
const searchParams = useSearchParams();
const status = searchParams.get("status") ?? "open";
const orders = useOrders({ status });
return <OrderTable orders={orders.data ?? []} loading={orders.isLoading} />;
}
The component stays understandable because it does not also own mutation retries, toast policy, cache invalidation, and permission calculation. Those concerns have a home where they can be tested independently.
The maintenance test
I try to change a feature in three ways: add a field, change an error state, and remove the feature. If each task requires edits across unrelated global modules, the architecture is leaking. Good structure makes the common change easy and the dangerous change visible.