Separate the Shell From Features
Navigation, workspace switching, notifications and global commands belong to the application shell. Customer, billing and support logic belong to feature folders with explicit routes and adapters.
7 minute read · Updated 2026-09-05
A frontend structure that keeps business features separate while preserving one design system.
A maintainable React admin separates application shell, feature routes, domain adapters and reusable UI primitives. Pages compose approved patterns; components do not fetch arbitrary data or encode business authorization.
Navigation, workspace switching, notifications and global commands belong to the application shell. Customer, billing and support logic belong to feature folders with explicit routes and adapters.
A component should receive a stable record shape rather than know whether data came from REST, GraphQL, local mocks or a third-party SDK.
List pages should share search, filters, table, pagination and states. Detail pages should share identity, actions, summary, related records and activity. Repetition at the pattern level is consistency; copied component source is debt.
The interface may hide or disable unavailable actions, but the API must enforce authorization independently. Treat UI permissions as communication, not security.
Prefer feature-level data hooks or adapters. Visual components remain easier to test when they receive typed data and callbacks.
Keep server data in a data-query layer and reserve client global state for genuine cross-route interface state such as current workspace or user preference.
Use a small set of intentional layouts. Authentication, focused workflows and dense operations may need different shells while sharing tokens and components.