Context
Several CMS feature areas expose list and detail views on separate routes (e.g. content, monetization plans).
Historically, list pages duplicated orchestration logic for pub/sub events, modal handling, navigation, and lifecycle actions, leading to inconsistent UX and unclear ownership.
A shell-based composition pattern is already in use in production (e.g. content, plans/monetization) but had not been formally documented, creating ambiguity for future modules.
Decision
Adopt a shell-based composition pattern for list and detail views:
- List routes render a single shell entrypoint.
- The shell owns cross-cutting orchestration concerns (events, modals, navigation).
- List modules own collection rendering and data access.
- Detail views render only on dedicated detail routes.
- List and detail responsibilities are strictly separated.
All new list/detail modules must follow this pattern unless superseded by another ADR.
Consequences
- Predictable and consistent list/detail UX across the CMS.
- Clear ownership boundaries between orchestration, collection logic, and item views.
- Reduced duplication of event wiring and lifecycle handling.
- Slight indirection cost due to enforcing shell boundaries.
Notes
- This pattern reflects existing production usage.
- Detailed structure and invariants are documented separately.
- Alternative interaction models require a new ADR.