julien
c8e2fba13e
Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
1.7 KiB
1.7 KiB
Use Angular standalone components without NgModules
- Status: accepted
- Date: 2026-04-26
Context and Problem Statement
Angular historically required all components, directives, and pipes to be declared inside NgModules. Angular 14 introduced standalone components as an opt-in. Angular 17+ made them the recommended default and they are required for the esbuild-based application builder. How should the application be structured?
Considered Options
- Standalone components (no NgModules)
- NgModule-based architecture
Decision Outcome
Chosen option: "Standalone components (no NgModules)", because they are the Angular-recommended default since v17, provide explicit per-component dependency declarations, and are required for the esbuild application builder.
Positive Consequences
- Each component explicitly declares its own
imports— dependencies are visible and not hidden in a shared module. - Better tree-shaking: unused imports in one component don't affect others.
- Aligns with Angular's long-term direction.
Negative Consequences
- Slightly more verbose component decorators — each component lists its own imports rather than inheriting from a module.
Pros and Cons of the Options
Standalone components (no NgModules)
- Good, because explicit dependency declarations per component.
- Good, because required for the esbuild application builder.
- Good, because Angular-recommended default since v17.
- Bad, because more verbose decorators.
NgModule-based architecture
- Good, because familiar pattern for developers coming from Angular < 14.
- Bad, because deprecated direction; incompatible with the modern application builder.
- Bad, because shared module patterns hide dependencies.