Navigation and Module Model
Navigation and Module Model
Section titled “Navigation and Module Model”The frontend favors a registry-driven module model because module availability is user-specific and can include hierarchical add-ons.
Why not static menu config per view?
Section titled “Why not static menu config per view?”A static per-view menu duplicates permission logic and drifts over time.
Why registry + providers?
Section titled “Why registry + providers?”- Single source of truth for module metadata
- Centralized filtering for user access
- Consistent output shape for sidebar, command bar, and handlers
Tradeoff
Section titled “Tradeoff”The model increases dependence on provider wiring and accurate module key management. That is acceptable because it keeps authorization and navigation logic centralized.