Angular schrittweise umstrukturieren

Angular Refactoring & Migrations

Refactor Angular codebases in small, behavior-preserving steps without mixing broad architectural migrations into unrelated feature or bugfix work.

1. Incremental refactoring boundaries

• Keep refactoring scoped to the task at hand. Before changing structure, ensure existing tests pass (or add characterization tests around the user flow).
• Untangle fat components step by step:
  1. Extract pure calculations into computed() signals, pure pipes or helper functions.
  2. Extract HTTP calls and data transformation into a typed domain/data service.
  3. Extract complex local coordination or multi-stream state into a component-scoped facade/service.
  4. Split self-contained UI sections into focused child components with explicit inputs and outputs.

2. Bridging NgModule and standalone code safely

• In hybrid codebases, respect the existing module boundaries:
  • A standalone component can be imported into an @NgModule's imports: [...] array (never declarations).
  • An @NgModule-declared component can be used by importing its exporting module into a standalone component's imports: [...].
• Never convert an entire feature module to standalone, @if/@for control flow, or Signals inside a targeted bugfix or feature PR unless explicitly requested.

3. Safe Angular and RxJS upgrades (when tasked with an upgrade)

• Check package.json peer dependencies (@angular/*, typescript, rxjs, zone.js, @angular/material, @ngrx/*) and use official Angular CLI schematics (ng update / ng generate @angular/core:...) where applicable.
• Replace deprecated RxJS signatures (such as toPromise() -> firstValueFrom/lastValueFrom, positional subscribe(next, error, complete) -> observer object) and verify build, template typecheck and tests after each step.

Before you finish

• Every refactoring step preserves observable behavior and passes template typecheck and tests.
• Standalone and NgModule imports/declarations remain valid without unsolicited mass conversion.
• Breaking changes, schematic steps or peer-dependency requirements are documented clearly.