Module Registry Service
Component Detail
Description
Fetches the enabled module set for the current user's tenant from the backend bootstrap response and exposes it as a Riverpod provider consumed throughout the app. Each area registers its navigation items, home widgets, and deep link routes against its area ID; the service ensures disabled modules are never mounted.
module-registry-service
Sources & reasoning
The Module Registry Service is the runtime backbone of the multi-tenant module toggle architecture. It is the reason new organizations can onboard with different capability sets without code changes, and it is the direct driver of home screen assembly for both role variants. Without it, every screen would require org-specific conditional logic.
No source references — this artifact was included based on reasoning alone (see above).
Responsibilities
- Fetch and cache the tenant enabled module set from backend bootstrap
- Expose enabled module state as a reactive Riverpod provider
- Accept area registrations for nav items, home widget factories, and deep links
- Resolve implicit module dependencies declared in the registry
- Notify all consumers when the enabled set changes
Interfaces
getEnabledModules() → Set<String>
isModuleEnabled(areaId: String) → bool
registerAreaNavItem(areaId: String, role: Role, item: NavItem) → void
registerAreaHomeWidget(areaId: String, role: Role, factory: WidgetFactory) → void
registerAreaDeepLink(areaId: String, route: String) → void
getHomeWidgets(role: Role) → List<WidgetFactory>
getNavItems(role: Role) → List<NavItem>
refreshFromBootstrap() → Future<void>
Relationships
Dependents (5)
Components that depend on this component
Related Data Entities (6)
Data entities managed by this component