Întrebări de interviu Angular

Apoi intră în detalii

• Nu mai scrii standalone: true — e implicit. Fiecare componentă importă exact ce folosește template-ul (alte componente, pipe-uri, RouterLink), deci dependențele sunt explicite și tree-shakable.
• Configurarea la nivel de aplicație stă în app.config.ts, ca providers: provideRouter(routes), provideHttpClient(...) doar dacă îl configurezi etc.
• O bibliotecă veche care exportă doar un NgModule poate fi pusă direct în imports la componentă; providerii de modul trec prin importProvidersFrom().

import { bootstrapApplication } from '@angular/platform-browser';
import { App } from './app/app';
import { appConfig } from './app/app.config';

bootstrapApplication(App, appConfig).catch((err) => console.error(err));

Apoi intră în detalii

• [disabled] leagă o proprietate DOM; pentru ce există doar ca atribut (ARIA, colspan) folosești [attr.aria-label].
• [(x)] („banana in a box”) e doar zahăr sintactic pentru [x]="v()" + (xChange)="v.set($event)". Cu un semnal pasezi semnalul însuși, fără paranteze.
• Expresiile din template trebuie să fie ieftine și fără efecte secundare; citirea unui semnal ca count() e în regulă, o metodă grea rulează la fiecare verificare.

<h2>{{ user().name }}</h2>
<img [src]="user().avatarUrl" [attr.aria-label]="user().name" />
<button [disabled]="saving()" (click)="save()">Save</button>
<input (input)="query.set($any($event.target).value)" />
<app-toggle [(checked)]="notifications" />

Apoi intră în detalii

• Faci track după un id stabil și unic (track user.id); $index doar pentru liste statice; track pe obiectul însuși înseamnă că fiecare refetch distruge și recreează DOM-ul.
• Face parte din limbaj: fără importuri de NgIf/NgFor. @for expune $index, $first, $last, $even, $odd, $count.
• @if (user(); as u) dă un alias tipizat, non-null. Din v21.1 mai multe @case pot împărți un bloc, iar @default never; (v21.2) face dintr-un caz uitat al unui union o eroare de compilare.

@if (tasks().length) {
  <ul>
    @for (task of tasks(); track task.id; let i = $index) {
      <li>{{ i + 1 }}. {{ task.title }}</li>
    }
  </ul>
} @else {
  <p>You have no tasks.</p>
}

Apoi intră în detalii

• Nu poate fi reatribuit din template; se recalculează când se schimbă ce citește.
• E util în @for pentru o valoare per element (de ex. prețul final după reducere).
• Logica reală rămâne în clasă, ca computed(); @let e pentru lizibilitate, nu pentru reguli de business.

Apoi intră în detalii

• [class] acceptă string, array sau obiect; [style] acceptă string sau obiect, iar unitățile se pun în binding (.px, .%, .rem).
• [ngClass]/[ngStyle] sunt varianta veche; v21 are migrările ngclass-to-class și ngstyle-to-style.
• Pentru elementul gazdă al componentei folosești metadata host ('[class.is-loading]': 'loading()'), nu @HostBinding.

Apoi intră în detalii

• Pipe-urile sunt standalone și se importă ca orice dependență (imports: [DatePipe]); unul custom e o clasă cu @Pipe și transform().
• Pentru că verificarea e prin referință, un pipe pure nu rulează din nou dacă modifici un array pe loc.
• O metodă apelată din template rulează la fiecare verificare; pentru calcule specifice componentei preferă computed(), iar pipe-urile păstrează-le pentru formatare reutilizabilă. Evită pure: false.

Apoi intră în detalii

• Un input() este un semnal read-only: îl citești cu value() și derivi din el cu computed() — fără ngOnChanges.
• input.required<T>() face dintr-un binding lipsă o eroare de compilare; transform: numberAttribute / booleanAttribute transformă max="10" sau un simplu atribut readonly în tipul corect.
• Copilul nu poate face set() pe propriul input. Dacă trebuie să schimbe valoarea, emite un eveniment și lasă părintele să decidă sau folosește model().

export class StarRating {
  readonly value = input.required<number>();
  readonly max = input(5, { transform: numberAttribute });
  readonly rate = output<number>();

  protected readonly stars = computed(() =>
    Array.from({ length: this.max() }, (_, i) => i + 1),
  );
}

Apoi intră în detalii

• Folosește model() când valoarea aparține cu adevărat ambelor părți, ca la un toggle, un stepper sau un input custom.
• Folosește input() + output() când copilul doar propune, iar părintele decide (validează, confirmă, salvează pe server).
• În two-way binding pasezi semnalul însuși (notifications), nu valoarea lui (notifications()).

Apoi intră în detalii

• select primește un selector de tag, atribut sau clasă ([card-title]); <ng-content /> fără select prinde tot restul, iar în interior poți pune conținut fallback.
• Capcană: conținutul proiectat e creat de părinte chiar dacă copilul îl ascunde cu @if. Pentru conținut cu adevărat lazy, pasezi un <ng-template>.
• Proiecția e pentru markup flexibil (layout-uri, carduri, dialoguri); input-urile sunt pentru date pe care componenta le formatează singură.

Apoi intră în detalii

• Dependențele sunt urmărite automat: ce semnale citește funcția devin dependențe, fără abonamente de gestionat.
• Semnalele compară cu ===: items().push(x) nu anunță pe nimeni; folosește update((list) => [...list, x]).
• Regulă practică: tot ce se poate calcula din altă stare e un computed(), nu un al doilea semnal ținut sincronizat. Expui starea cu asReadonly().

export class Counter {
  protected readonly count = signal(0);
  protected readonly double = computed(() => this.count() * 2);

  protected increment() {
    this.count.update((c) => c + 1);
  }
}
// template: {{ count() }} · {{ double() }}

Apoi intră în detalii

• Nu folosi un effect ca să copiezi un semnal în altul: asta e un computed() (sau linkedSignal() dacă trebuie să fie și editabil).
• Nu încărca date dintr-un effect: nu ai anulare, iar răspunsurile vechi pot câștiga cursa. Folosește httpResource() / resource().
• Trebuie creat într-un context de injecție (constructor sau câmp), se distruge odată cu componenta, iar onCleanup curăță timerele înainte de următoarea rulare.

Apoi intră în detalii

• Citirea unui input.required() în constructor aruncă eroare, pentru că părintele nu l-a legat încă. Cu input-uri semnal rar ai nevoie de ngOnInit: un computed() sau httpResource() citește input-ul când e gata.
• inject() nu merge în ngOnInit sau într-un handler de click — e în afara contextului de injecție (eroarea NG0203).
• DestroyRef merge și în servicii, directive și funcții reutilizabile, ceea ce ngOnDestroy nu poate. Pentru acces la DOM după randare, folosește afterNextRender().

export class Clock {
  readonly now = signal(new Date());

  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Apoi intră în detalii

• @Service() este echivalent cu @Injectable({ providedIn: 'root' }): creat la prima injecție și tree-shakable. Cere inject() — DI prin constructor e eroare de compilare.
• @Injectable rămâne valid (cod existent, biblioteci pentru versiuni mai vechi). Dacă pui serviciul în providers la o componentă, primești câte o instanță per componentă, nu una pe aplicație.
• inject() merge și în guards, resolvers și interceptors funcționale și evită apelurile lungi super(...) la moștenire.

@Service()
export class CartService {
  private readonly _items = signal<CartItem[]>([]);
  readonly items = this._items.asReadonly();
  readonly count = computed(() => this._items().length);

  add(item: CartItem) {
    this._items.update((list) => [...list, item]);
  }
}

Apoi intră în detalii

• loadComponent: () => import('./home-page') pune pagina într-un chunk separat, descărcat doar când e vizitată ruta; loadChildren face la fel pentru un feature întreg.
• Ordinea contează — câștigă prima potrivire — deci wildcard-ul '**' stă la final. routerLinkActive adaugă o clasă pe link-ul activ.
• Folosește routerLink, nu href: href reîncarcă toată aplicația.

Apoi intră în detalii

• Capcană: navigarea de la /products/1 la /products/2 refolosește aceeași instanță a componentei; codul care citește id-ul o singură dată (de ex. un snapshot în ngOnInit) afișează date vechi.
• Parametrii sunt string-uri în URL, deci un transform ca numberAttribute îți dă un număr real.
• Din v22 rutele copil moștenesc implicit params și data de la toți părinții (paramsInheritanceStrategy: 'always').

@Component({ templateUrl: './product-page.html' })
export default class ProductPage {
  readonly id = input.required({ transform: numberAttribute }); // :id
  readonly tab = input<'specs' | 'reviews'>('specs');           // ?tab=

  readonly product = httpResource<Product>(() => '/api/products/' + this.id());
}

Apoi intră în detalii

• Observable-ul e cold: nicio cerere nu pleacă până nu se abonează cineva (subscribe(), firstValueFrom(), pipe-ul async).
• Pentru citiri reactive într-o componentă, httpResource() dă value(), isLoading() și error() ca semnale și anulează cererile vechi; pentru scrieri (POST, PUT) apelezi HttpClient.
• Genericul get<T> e doar o aserțiune de tip, nu validare. În v22 Fetch e backend-ul implicit; preocupările transversale (token, erori) merg în interceptors funcționale.

Apoi intră în detalii

• Semnalul-model este sursa de adevăr — fără copie internă, fără patchValue: model.set(data) umple formularul, iar formularul scrie direct în model.
• Starea fiecărui câmp e semnale: f.email().invalid(), touched(), errors(); tot formularul e și el un câmp (f().valid(), f().submitting()).
• Afișează erorile doar după touched() și validează întotdeauna și pe server — validarea pe client e UX, nu securitate.

export class LoginForm {
  readonly model = signal({ email: '', password: '' });

  readonly loginForm = form(this.model, (p) => {
    required(p.email);
    email(p.email);
    minLength(p.password, 8);
  });
}
// template: <input [formField]="loginForm.email" />

Apoi intră în detalii

• @placeholder se afișează înainte de trigger (necesar pentru on viewport / interaction / hover), @loading în timpul descărcării, @error dacă descărcarea eșuează.
• Capcană: dacă o componentă din defer e referită și altundeva în același fișier (în afara blocului), e încărcată eager și chunk-ul se pierde.
• prefetch on hover descarcă din timp și randează mai târziu — bun pentru acțiuni „la un click distanță”.

@defer (on viewport) {
  <app-comments [postId]="post().id" />
} @placeholder {
  <div class="comments-skeleton"></div>
} @loading (after 100ms) {
  <app-spinner />
}

Apoi intră în detalii

• Fără zone.js, un setTimeout sau un subscribe() care schimbă un câmp simplu nu actualizează UI-ul. Soluția e un semnal (sau toSignal() / pipe-ul async).
• O componentă OnPush e verificată doar când un input primește o referință nouă, are loc un eveniment în ea, se schimbă un semnal pe care îl citește sau e marcată pentru verificare — altfel subarborele ei e sărit.
• ChangeDetectionStrategy.Eager este vechiul comportament „verifică mereu” (Default e deprecat); ng update îl adaugă unde e nevoie.

Apoi intră în detalii

• Testează comportamentul pe care îl vede utilizatorul (text, click-uri, output-uri emise), nu detaliile private de implementare.
• Input-urile se pot da ca semnale cu inputBinding(); output-urile se urmăresc cu outputBinding() și vi.fn().
• Pentru HTTP folosești provideHttpClientTesting() și HttpTestingController în loc de un server real; serviciile și store-urile cu semnale se testează cu TestBed.inject(), fără DOM.

it('shows the right number of stars', async () => {
  const fixture = TestBed.createComponent(StarRating, {
    bindings: [inputBinding('value', () => 3)],
  });
  await fixture.whenStable();

  const stars = fixture.nativeElement.querySelectorAll('button');
  expect(stars).toHaveLength(5);
});

Apoi intră în detalii

• Dacă setezi un semnal într-un effect ai o rulare în plus, un moment în care ținta e învechită (un render cu valoare greșită) și un graf de dependențe greu de urmărit.
• Efectele nu sunt sincrone: setezi un semnal de 3 ori și efectul rulează o dată, cu valoarea finală. Efectele de componentă rulează în change detection; cele din servicii root, ca microtask-uri.
• Dependențele sunt dinamice: contează doar semnalele citite la ultima rulare. Folosești untracked() pentru citiri care nu trebuie să redeclanșeze efectul.
• Un effect are nevoie de context de injecție (constructor sau inițializare de câmp) ori de un injector explicit; altfel primești NG0203. Pentru timere și listener-e folosești onCleanup.
• HTTP dintr-un effect e un semnal de alarmă: nu ai anulare, deci răspunsurile pot veni în altă ordine. Pentru asta există resource / httpResource.

readonly firstName = signal('Ana');
readonly lastName = signal('Pop');

// ✗ effect used to synchronise state
// effect(() => this.fullName.set(this.firstName() + ' ' + this.lastName()));

// ✓ derived state
readonly fullName = computed(() => this.firstName() + ' ' + this.lastName());

// ✓ effect: reactive world → outside world
constructor() {
  effect(() => localStorage.setItem('name', this.fullName()));
}

Apoi intră în detalii

• Înlocuiește tiparul fragil semnal + effect: fără rulare în plus, fără render cu valoare veche.
• Forma lungă (source + computation) îți dă valoarea previous, deci poți păstra alegerea utilizatorului dacă încă există în lista nouă.
• Un set() manual e valabil doar până la următoarea schimbare a sursei; apoi câștigă computation.
• Din v22.1, opțiunea set interceptează scrierile, de exemplu ca să limitezi o cantitate la stocul disponibil.

Apoi intră în detalii

• resource primește un abortSignal în loader; httpResource trece prin HttpClient, deci se aplică interceptorii; rxResource primește un stream Observable și se comportă ca switchMap.
• Dacă params întoarce undefined, statusul e idle: loader-ul nu rulează. În v22 poți și arunca ResourceParamsStatus.IDLE / LOADING și poți înlănțui resurse cu ctx.chain().
• hasValue() e type guard; defaultValue elimină undefined; parse validează sau mapează răspunsul (de ex. DTO → model, Zod).
• Resursele sunt pentru citire. Scrierile (POST/PUT/DELETE) merg prin HttpClient, apoi faci update() local pe resursă (optimist) sau reload().

readonly userId = input.required<number>();

// a new id → the old request is cancelled, a new one starts
readonly user = httpResource<User>(() => '/api/users/' + this.userId());

// template:
// @if (user.isLoading()) { <app-spinner /> }
// @if (user.error()) { <button (click)="user.reload()">Retry</button> }
// @else if (user.hasValue()) { <h2>{{ user.value().name }}</h2> }

Apoi intră în detalii

• debounced() întoarce un Resource: value() se actualizează după ultima schimbare, iar isLoading() e true cât timp utilizatorul încă scrie.
• E experimental în v22. Alternativa clasică e toSignal(toObservable(query).pipe(debounceTime(300), distinctUntilChanged())): trei conversii pentru un singur debounce.
• wait poate fi o funcție, de exemplu fără întârziere când câmpul e golit.
• În Signal Forms există o regulă dedicată debounce(path.field, 300), iar validateHttp are propria opțiune debounce.

import { httpResource } from '@angular/common/http';
import { debounced, signal } from '@angular/core';

export class UserSearch {
  readonly query = signal('');
  readonly search = debounced(this.query, 300);

  readonly users = httpResource<UserDto[]>(
    () => '/api/users?q=' + encodeURIComponent(this.search.value()),
    { defaultValue: [] },
  );
}

Apoi intră în detalii

• toSignal() fără initialValue are tipul T | undefined; requireSync: true merge doar dacă sursa emite sincron (de ex. un BehaviorSubject).
• toObservable() emite asincron (printr-un effect) și doar ultima valoare dacă semnalul e setat de mai multe ori în același tick — nu e un stream de evenimente.
• takeUntilDestroyed() fără argument merge doar în context de injecție; în rest îi dai explicit inject(DestroyRef). Pentru cleanup fără RxJS folosești DestroyRef.onDestroy().
• Păstrezi RxJS pentru websocket-uri, combinarea stream-urilor de evenimente, retry/backoff și politici de flattening (switchMap, exhaustMap…). Semnalele nu au noțiunea de timp.

Apoi intră în detalii

• Alegerea operatorului e alegerea unei politici de concurență; cea greșită produce bug-uri reale: comenzi duble cu mergeMap pe butonul de plată, salvări pierdute cu switchMap la autosave.
• mergeMap acceptă o limită de concurență, de ex. mergeMap(upload, 3).
• Pui catchError în pipe-ul interior: după operatorul de flattening, prima eroare completează stream-ul exterior și căutarea „moare”.
• Cu semnale, httpResource și rxResource îți dau deja semantica switchMap pentru citiri.

// the last one wins; errors handled INSIDE, so the stream survives
query$.pipe(
  debounceTime(300),
  switchMap((q) => this.api.search(q).pipe(catchError(() => of([])))),
);

files$.pipe(mergeMap((file) => this.api.upload(file), 3)); // parallel, max 3
patches$.pipe(concatMap((patch) => this.api.save(patch))); // in order
submit$.pipe(exhaustMap(() => this.api.login(this.credentials()))); // ignore double clicks

Apoi intră în detalii

• Din v22 componentele fără changeDetection sunt OnPush; comportamentul vechi e ChangeDetectionStrategy.Eager (Default e deprecat). ng update adaugă Eager unde e nevoie.
• O componentă OnPush e verificată doar la o referință nouă pe input (===), la un eveniment în ea sau în copii, la un semnal citit în template, la pipe-ul async sau la markForCheck(). Altfel tot subarborele e sărit.
• Mutarea unui array primit ca input (push) nu schimbă referința: folosești update-uri imutabile.
• markForCheck() e soluția de urgență pentru callback-uri vechi; detectChanges() e sincron și rar necesar.

// ✗ works with zone.js, NOT zoneless + OnPush
// now = new Date();
// setInterval(() => (this.now = new Date()), 1000);

// ✓ a signal schedules change detection by itself
export class Clock {
  readonly now = signal(new Date());

  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Apoi intră în detalii

• viewChild caută în template-ul propriu al componentei; contentChild caută în ce a proiectat părintele (de ex. un container Tabs care își descoperă copiii Tab).
• contentChildren se uită implicit doar la copiii direcți; pentru potriviri mai adânci folosești descendants: true.
• read alege ce primești: ElementRef, TemplateRef, ViewContainerRef, o directivă sau (v22.2) Injector-ul copilului.
• Capcană: un query după tipul unei componente în clasă o face eager, deci nu mai e separată într-un chunk de un bloc @defer.

Apoi intră în detalii

• Dacă pui ng-content într-un @if, ascunzi DOM-ul, dar componentele proiectate există deja și ciclul lor de viață a rulat deja.
• Sloturile numite folosesc select (tag, atribut, clasă); ngProjectAs proiectează mai multe elemente într-un slot fără wrapper.
• Contextul trimite date înapoi: $implicit ajunge în let-item. Fără o directivă cu ngTemplateContextGuard, variabilele let- sunt any.
• Un template vede injectorul locului unde a fost declarat; din v21.2 [ngTemplateOutletInjector]="'outlet'" îl face să folosească injectorul locului unde e randat.

@Component({
  selector: 'app-collapsible',
  imports: [NgTemplateOutlet],
  template: `
    <button (click)="open.set(!open())">Toggle</button>
    @if (open()) { <ng-container [ngTemplateOutlet]="content() ?? null" /> }
  `,
})
export class Collapsible {
  readonly content = contentChild(TemplateRef); // created only when opened
  readonly open = signal(false);
}
// <app-collapsible><ng-template><app-heavy-report /></ng-template></app-collapsible>

Apoi intră în detalii

• Semnul unei god component: date any[], flag-uri isProductTable, 30 de input-uri și cunoștințe de domeniu în shared/.
• Template-urile de celulă sunt găsite cu contentChildren() pe o directivă; ngTemplateContextGuard tipizează let-row ca T în loc de any.
• Comportamentul îl dai ca funcții (trackBy, displayWith, compareWith), ca să nu trebuiască să știe componenta forma datelor.
• O greșeală de tipar în cheia unei coloane devine eroare de compilare, nu o coloană goală în producție.

Apoi intră în detalii

• Un registru de loader-e () => import(…) face din fiecare widget un chunk lazy separat.
• inputBinding('title', () => …) e reactiv, spre deosebire de vechiul setInput() pe care trebuia să-l apelezi din nou la fiecare schimbare, plus subscription-uri manuale la output-uri.
• ComponentFactoryResolver a fost eliminat în v22: dai clasa direct lui createComponent.
• Pentru toast-uri și dialoguri în afara arborelui folosești funcția createComponent() cu un EnvironmentInjector, apoi appRef.attachView() ca să intre în change detection, și o distrugi tu.

private readonly vcr = inject(ViewContainerRef);

private async render(type: WidgetType) {
  const component = await WIDGET_REGISTRY[type](); // lazy chunk
  this.vcr.clear();
  this.vcr.createComponent(component, {
    bindings: [
      inputBinding('title', () => this.config().title), // stays in sync
      outputBinding('remove', () => this.removed.emit(this.config().id)),
    ],
  });
}

Apoi intră în detalii

• Alegi scope-ul după durata de viață: starea de feature în providers pe pagină sau rută (moare odată cu ea), starea globală (user, coș, temă) într-un @Service() root.
• Datele de pe server stau într-un httpResource în store; starea care trebuie să supraviețuiască unui refresh sau să poată fi trimisă ca link stă în URL (query params + input()).
• O componentă dumb poate avea stare UI locală și poate injecta lucruri de UI (ElementRef, DestroyRef), dar niciodată servicii de date sau router-ul — altfel nu mai poate fi reutilizată sau testată ușor, iar o listă de 50 de carduri face 50 de cereri.
• NgRx SignalStore merită când echipa vrea convenții, plugin-uri și devtools, nu din oficiu.

Apoi intră în detalii

• @Service() (v22) e echivalent cu providedIn: 'root', e tree-shakable și permite doar inject(). autoProvided: false te obligă să-l pui în providers.
• inject() e mai bun decât DI prin constructor: fără lanțuri super(…), merge în guards, interceptori și factory-uri și permite funcții reutilizabile injectX(). Are nevoie de context de injecție (altfel NG0203).
• useClass, useValue, useFactory, useExisting și multi: true pentru array-uri de tip plugin; optional, self, skipSelf, host modifică căutarea.
• viewProviders nu sunt vizibili pentru conținutul proiectat; EnvironmentProviders (provideX()) pot sta doar la nivel de aplicație sau rută, nu într-o componentă.

Apoi intră în detalii

• Întorci true/false, un UrlTree sau un RedirectCommand (redirect + opțiuni de navigare, ca replaceUrl); din v22.2 poți și arunca un RedirectCommand.
• Resolver: pagina apare cu datele gata, dar navigarea așteaptă, iar o eroare o anulează. httpResource: navigare instantă, loading-ul și eroarea sunt stare în UI.
• Cu withComponentInputBinding(), datele rezolvate, params și query params ajung ca input()-uri.
• Guard-urile sunt UX, nu securitate: și API-ul trebuie să verifice autorizarea. canDeactivate protejează modificările nesalvate.

Apoi intră în detalii

• Atașezi token-ul doar pentru API-ul tău (verifici URL-ul), niciodată pentru host-uri terțe.
• Ordinea contează: cererile trec prin interceptori în ordinea din listă, răspunsurile se întorc în ordine inversă.
• Apelezi inject() la începutul funcției, nu în callback-uri RxJS precum catchError, care rulează mai târziu, în afara contextului de injecție.
• Folosești HttpContextToken pentru metadate per cerere (de ex. să sari peste bara de loading) în loc de header-e false. Și httpResource, și validateHttp trec prin interceptori.

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const token = inject(AuthStore).token();
  if (!token || !req.url.startsWith('/api')) return next(req);

  return next(req.clone({ setHeaders: { Authorization: 'Bearer ' + token } }));
};

// app.config.ts
provideHttpClient(withInterceptors([authInterceptor, errorInterceptor]));

Apoi intră în detalii

• @boundary (v22.2, developer preview) are blocuri @error (let e = $error; let reset = $reset), opțional cu condiții when — câștigă prima potrivire.
• @boundary prinde doar erori de randare, nu erori din handler-e de evenimente sau din cod async — acelea ajung tot la ErrorHandler.
• provideBrowserGlobalErrorListeners() trimite window.onerror și promise-urile respinse netratate către ErrorHandler.
• Un interceptor ar trebui să arunce eroarea mai departe (throwError(() => err)) după reacția transversală, ca apelantul să poată reacționa și el. Erorile de validare nu sunt excepții: stau în errors() din formular.

@boundary {
  <app-price-widget [price]="price()" />
  <app-recommendations />
} @error (let e = $error; when e instanceof PermissionError) {
  <p>You don't have access to this widget.</p>
} @error (let e = $error; let retry = $reset) {
  <app-error-card [message]="e.message" (retry)="retry()" />
}

Apoi intră în detalii

• Fără copie internă: model.set() actualizează input-urile, iar tastarea actualizează modelul — fără patchValue / valueChanges.
• Regulile între câmpuri folosesc valueOf() în validate; cele condiționale, when, hidden, disabled (câmpurile hidden și disabled nu se validează); regulile reutilizabile, schema() + apply().
• validateHttp trece prin HttpClient (deci se aplică interceptorii) și are opțiunea debounce în v22; validateAsync merge cu orice resource. pending() e true cât timp rulează.
• Erorile de la server din submission.action pot fi întoarse cu un fieldTree, ca să ajungă pe câmpul potrivit.
• Migrarea poate fi treptată cu SignalFormControl și compatForm; Reactive Forms tipizate (nonNullable, getRawValue()) rămân valide pentru codul existent.

readonly model = signal({ username: '', password: '' });

readonly signup = form(this.model, (p) => {
  required(p.username);
  minLength(p.password, 8, { message: 'At least 8 characters' });
  validateHttp(p.username, {
    request: ({ value }) => '/api/username-available?username=' + value(),
    debounce: 400,
    onSuccess: (res: { available: boolean }) =>
      res.available ? undefined : { kind: 'taken', message: 'Username taken' },
    onError: () => ({ kind: 'network', message: 'Could not verify' }),
  });
});

Apoi intră în detalii

• Input-urile opționale ca disabled, invalid, touched sunt completate automat de formular — le declari doar pe cele pe care le folosești. În v22, un output touch anunță că utilizatorul a atins controlul.
• Controalele boolean implementează FormCheckboxControl, cu checked în loc de value.
• Un CVA are nevoie de patru metode (writeValue, registerOnChange, registerOnTouched, setDisabledState) și trebuie să apelezi tu onChange; dacă uiți onTouched, nu mai merge „arată erorile după touch”.
• Interoperabilitate în v22: Signal Forms poate lega CVA-uri, iar formularele template/reactive suportă FormValueControl, deci un singur control le poate servi pe amândouă în timpul migrării.

Apoi intră în detalii

• Dacă referi o componentă deferred în clasă (de ex. viewChild(HeavyChart)) sau altundeva în template, devine eager.
• @placeholder apare înainte de trigger (și e elementul observat pentru viewport / interaction / hover fără țintă); @loading (after 100ms; minimum 500ms) evită pâlpâirea; @error tratează o descărcare de chunk eșuată.
• when se declanșează o singură dată; mai multe trigger-e se combină cu SAU.
• Noutăți: on viewport({ rootMargin: '200px' }) (v21), on idle(500) (v22). Cu SSR, trigger-ele hydrate on … dau hidratare incrementală, activă implicit în v22.

@defer (on viewport; prefetch on idle) {
  <app-comments [postId]="post().id" />
} @placeholder (minimum 300ms) {
  <div class="comments-skeleton"></div>
} @loading (after 100ms; minimum 500ms) {
  <app-spinner />
} @error {
  <p>We couldn't load the comments.</p>
}

@defer (on interaction; prefetch on hover) {
  <app-share-dialog />
} @placeholder { <button>Share</button> }

Apoi intră în detalii

• Vitest e runner-ul implicit din v21 (@angular/build:unit-test); Karma e deprecat. Folosești vi.fn() pentru spioni pe output-uri și vi.useFakeTimers() în loc de fakeAsync.
• Schimbarea semnalului legat actualizează input-ul ca într-un părinte real — nu mai ai nevoie de setInput().
• Store-urile cu semnale sunt cel mai ușor de testat: TestBed.inject(), apelezi metode, verifici computed()-urile. Efectele rulează asincron, deci le forțezi cu TestBed.tick().
• Testezi comportamentul prin DOM sau prin harness-uri, nu câmpuri private. TestBed.createDirective() (v22.2) testează o directivă fără componentă-gazdă scrisă de mână.

beforeEach(() => {
  TestBed.configureTestingModule({ providers: [provideHttpClient(), provideHttpClientTesting()] });
  api = TestBed.inject(ProductsApi);
  http = TestBed.inject(HttpTestingController);
});

afterEach(() => http.verify()); // no unexpected requests

it('maps DTO → Product', async () => {
  const result = firstValueFrom(api.get(1));
  http.expectOne('/api/products/1').flush({ id: 1, name: 'Mouse', price: 99, stock: 0 });
  expect(await result).toEqual({ id: 1, name: 'Mouse', price: 99, inStock: false });
});

Apoi intră în detalii

• Dependențele sunt dinamice: la fiecare rulare lista de producători se reconstruiește din ce s-a citit efectiv, deci un semnal citit doar într-o ramură if inactivă nu declanșează nimic.
• Egalitatea oprește propagarea: versiunea crește doar dacă valoarea nouă nu e egală (implicit Object.is). Un computed al cărui rezultat nu se schimbă nu-și trezește consumatorii; { equal } personalizează asta pentru valori recreate de la server.
• Consecință: mutația (items().push()) nu anunță pe nimeni, pentru că referința și versiunea rămân aceleași. Imutabilitatea nu e stil, e felul în care graful detectează schimbarea.
• Effect-urile sunt asincrone și programate odată cu change detection (view effects înainte de verificarea componentei lor, root effects înaintea tuturor componentelor). Semnalele nu sunt un mecanism de evenimente și nu ordonează în timp efectele secundare — acolo e teritoriul RxJS.

const a = signal(1);
const b = signal(2);
const sum = computed(() => a() + b());
const product = computed(() => a() * b());
const result = computed(() => sum() + product()); // diamond

a.set(5);
b.set(3);  // push: versions bump, nothing is recalculated yet
result();  // pull: sum, product, result run once each, with consistent values

// equality cutoff: a new array with the same content does not propagate
const ids = signal<number[]>([], {
  equal: (x, y) => x.length === y.length && x.every((v, i) => v === y[i]),
});

Apoi intră în detalii

• Template-ul e un consumator reactiv: când se schimbă un semnal pe care l-a citit, Angular marchează acel view pentru refresh (ca markForCheck), iar change detection ajunge doar la componentele afectate.
• OnPush compară input-urile prin referință (===): dacă muți un obiect primit printr-un input, copilul nu se actualizează — aceeași regulă de imutabilitate ca la semnale.
• Bug-ul clasic: un câmp simplu setat în setTimeout, subscribe() sau un callback de bibliotecă externă (WebSocket, Maps) — „se actualizează doar după ce dau click undeva”. Soluția e un semnal sau toSignal(); markForCheck() e ieșirea de urgență pentru cod vechi.
• detectChanges() e sincron și rareori necesar (măsurători, teste); markForCheck() e varianta asincronă recomandată.

// ✗ worked with zone.js, does nothing zoneless + OnPush
export class Clock {
  now = new Date();
  constructor() {
    setInterval(() => (this.now = new Date()), 1000);
  }
}

// ✓ the signal tells Angular what changed
export class Clock {
  readonly now = signal(new Date());
  constructor() {
    const id = setInterval(() => this.now.set(new Date()), 1000);
    inject(DestroyRef).onDestroy(() => clearInterval(id));
  }
}

Apoi intră în detalii

• Întâi inventarul: câmpuri simple setate în callback-uri asincrone, subscribe() în câmpuri, biblioteci care așteaptă NgZone.onStable. Angular 21 aduce un instrument de analiză (onpush_zoneless_migration, prin serverul MCP al CLI-ului, ng mcp).
• Migrezi întâi componentele frunză, feature cu feature: scoți Eager, muți starea în semnale / toSignal(), review și teste. Fiecare PR e mic și reversibil.
• Până la final păstrezi provideZoneChangeDetection({ eventCoalescing: true }) și polyfill-ul zone.js; apoi le scoți pe amândouă și urmărești bug-urile de tip „se actualizează doar după un click”.
• Se schimbă și testele: fakeAsync are nevoie de zone.js, deci treci la await fixture.whenStable() și fake timers din Vitest.
• În echipă: o regulă de lint/review ca tot codul nou să folosească semnale pentru starea din template și un checklist scurt în template-ul de PR, ca zona migrată să nu regreseze.

Apoi intră în detalii

• Ții starea la cel mai jos nivel care are nevoie de ea (componentă → feature → global) și o ridici doar când apare un consumator nou. Starea unei pagini e furnizată pe rută sau pe componentă, nu în root, ca să nu „rămână lipită” între vizite.
• Datele de la server sunt un cache, nu starea ta: le ții în httpResource/resource și reîncarci după scrieri. Și URL-ul e stare (filtre, paginare).
• Reguli care scalează: expui semnale read-only (asReadonly()), o singură sursă de adevăr cu restul derivat, fără store-uri care se injectează circular — de obicei semn că lipsește un facade sau că un concept e pus greșit.
• Cu SignalStore, doar metodele apelează patchState, rxMethod se ocupă de fluxurile asincrone (cu catchError în stream-ul interior), iar signalStoreFeature elimină codul de loading/error copiat. Bibliotecile pot coexista cu un NgRx Store existent.

Apoi intră în detalii

• Tag-uri pe două dimensiuni: scope (cine cu cine vorbește: scope:shop, scope:shared) × type (direcția dependențelor: feature → ui / data-access → util). Constrângerile din ambele se aplică cu AND.
• Un singur API public per feature/bibliotecă (un barrel doar la graniță, niciodată în fiecare folder); importurile adânci și importurile statice ale bibliotecilor lazy sunt încălcări.
• Granularitatea e un compromis: biblioteci mici pe domeniu și tip dau grafuri nx affected înguste și cache hit-uri; o bibliotecă shared uriașă face ca fiecare PR să afecteze tot repo-ul.
• Muți în shared doar ce e generic, stabil și deja folosit în mai multe feature-uri („regula lui trei”); componentele de domeniu folosite și în alte părți rămân în feature-ul care le deține și sunt exportate prin API-ul lui public.

'@nx/enforce-module-boundaries': ['error', {
  depConstraints: [
    // scope: who may talk to whom
    { sourceTag: 'scope:shop', onlyDependOnLibsWithTags: ['scope:shop', 'scope:shared'] },
    { sourceTag: 'scope:shared', onlyDependOnLibsWithTags: ['scope:shared'] },
    // type: which way dependencies flow
    { sourceTag: 'type:feature', onlyDependOnLibsWithTags: ['type:feature', 'type:ui', 'type:data-access', 'type:util'] },
    { sourceTag: 'type:ui', onlyDependOnLibsWithTags: ['type:ui', 'type:util'] },
    { sourceTag: 'type:util', onlyDependOnLibsWithTags: ['type:util'] },
    // ui never reaches data-access, not even transitively
    { sourceTag: 'type:ui', notDependOnLibsWithTags: ['type:data-access'] },
  ],
}],

Apoi intră în detalii

• Clasă abstractă în loc de interfață: o interfață dispare la compilare, deci ai avea nevoie de un InjectionToken separat; clasa abstractă e și tipul, și token-ul.
• Erorile fac parte din contract: adaptorul traduce timeout-urile/503 într-o eroare de domeniu, deci nicio componentă nu vede vreodată HttpErrorResponse.
• Câștigul se vede la testare: regulile de domeniu ca funcții pure, use case-urile cu un adaptor in-memory și o singură suită de teste de contract rulată pe fiecare adaptor.
• Varianta pragmatică: un domeniu pur pentru regulile care contează, un port doar unde ai (sau vei avea) mai multe implementări, restul în structura obișnuită data-access/ui — iar straturile le impui prin lint.

// application/task-repository.ts — the PORT (type + DI token)
export abstract class TaskRepository {
  abstract list(): Promise<readonly Task[]>;
  abstract save(task: Task): Promise<void>;
}

// infrastructure/http-task-repository.ts — the ADAPTER (HttpClient + DTO mapping)
@Injectable()
export class HttpTaskRepository extends TaskRepository { /* … */ }

// app.config.ts — the COMPOSITION ROOT
providers: [{ provide: TaskRepository, useClass: HttpTaskRepository }]

Apoi intră în detalii

• Motive valide: multe echipe cu ritmuri diferite, organizații foarte mari, o migrare strangler fig dintr-o aplicație veche, produse separate sub aceeași experiență.
• Angular trebuie să fie singleton cu strictVersion, ideal exact aceeași versiune peste tot: două runtime-uri înseamnă componente care nu pot intra în arborele shell-ului și servicii cu două instanțe. Un remote pe alt major se izolează ca Web Component sau iframe.
• Tratezi exposes-urile fiecărui remote ca API public cu semver; comunici prin URL, apoi evenimente tipizate, apoi câteva servicii singleton partajate — niciodată un store global comun (asta e un monolit distribuit).
• Planifici costurile din prima zi: timeout și fallback per remote, un manifest per mediu, numele și versiunea remote-ului în fiecare eroare logată, e2e pe combinația din producție.

Apoi intră în detalii

• Atributele sunt mereu string-uri: input-urile numerice/booleene au nevoie de numberAttribute / booleanAttribute, iar obiectele/array-urile merg doar prin proprietăți.
• Evenimentele nu fac bubble și nu sunt composed: asculți direct pe element. Folosești nume specifice pentru output-uri (ratingChange, nu change).
• Folosești ViewEncapsulation.ShadowDom ca CSS-ul paginii-gazdă să nu intre; tematizezi prin variabile CSS și ::part().
• Grupezi widget-urile unei echipe într-un singur bundle (un createApplication(), mai multe apeluri define()), folosești un tag diferit de selectorul componentei și nu refolosești un element distrus — creezi altul.

Apoi intră în detalii

• Prerender cu parametri cere getPrerenderParams; PrerenderFallback.Server (implicit) îți permite să prerandezi top N produse, iar restul la cerere. Fiecare URL e o randare completă la build.
• Modul Server înseamnă un proces Node: TTFB e cel puțin cât cel mai lent API apelat la randare, CPU per cerere și stare la nivel de modul partajată între utilizatori.
• Codurile de status corecte contează pentru SEO: setezi 404 prin RESPONSE_INIT în loc de un soft 404; cache-ul e pe rută — public, s-maxage doar pentru conținut identic, private, no-store pentru HTML personal.
• În v22 configurezi allowedHosts (sau NG_ALLOWED_HOSTS): un host necunoscut primește 400, ca protecție SSRF. Dacă nimeni nu poate opera un server Node, folosești Prerender cu outputMode: 'static'.

Apoi intră în detalii

• Spre deosebire de un @defer obișnuit, conținutul final e deja pe ecran, deci poți amâna și deasupra fold-ului fără layout shift.
• hydrate never doar pentru conținut cu adevărat static: nu e adnotat, deci nimic nu e redat. Păstrezi @placeholder: trigger-ele hydrate sunt ignorate la navigarea pe client.
• withIncrementalHydration() e deprecat, iar withEventReplay() e redundant față de implicit; opt-out-ul e withNoIncrementalHydration().
• Nu împachetezi componente de câțiva KB: chunk-ul și cererea în plus costă mai mult decât economisesc. Folosești stări CSS (:active, :focus-visible) ca utilizatorul să vadă că click-ul s-a înregistrat.

<app-product-header [product]="product()" />  <!-- hydrated at bootstrap -->

@defer (hydrate on interaction) {
  <app-gallery [images]="product().images" />  <!-- JS only at the first click -->
} @placeholder {
  <div class="gallery-skeleton"></div>         <!-- shown on client-side navigation -->
}

@defer (hydrate on viewport) {
  <app-reviews [productId]="id()" />           <!-- below the fold -->
} @placeholder {
  <div class="reviews-skeleton"></div>
}

@defer (hydrate never) { <app-footer /> }      <!-- static HTML forever -->

Apoi intră în detalii

• @if (isPlatformBrowser(…)) într-un template nu aruncă eroare, dar Angular aruncă DOM-ul de pe server pentru acel bloc și îl reconstruiește — un layout shift. Preferi @defer sau afterNextRender.
• Cauze de mismatch: manipularea directă a DOM-ului (innerHTML, appendChild), HTML invalid (<div> în <p>), scripturi externe, un CDN care șterge comentariile (NG0507) și valori ca Date.now() care diferă între platforme.
• Serverele zoneless nu văd async-ul tău (fetch, SDK-uri, timere): folosești resource() sau PendingTasks, altfel HTML-ul pleacă gol și browserul cere datele din nou.
• Scurgeri de stare: variabilele la nivel de modul și obiectele din useValue sunt comune tuturor utilizatorilor procesului Node; folosești servicii sau useFactory.
• În echipă: un build SSR în CI, un checklist de review și ngSkipHydration permis doar ca patch temporar și documentat.

Apoi intră în detalii

• Încărcare: rute lazy, @defer pentru conținutul greu de sub fold (niciodată elementul LCP), injectAsync() pentru servicii grele folosite rar, NgOptimizedImage cu priority pe imaginea LCP, importuri țintite verificate cu source-map-explorer.
• Randare: OnPush + semnale, track pe un id stabil, derivări în computed() în loc de metode în template; pentru zeci de mii de rânduri, virtual scroll din CDK sau paginare — OnPush reduce cât de des randezi, nu cât de mult.
• Main thread: calculele continue de peste ~50 ms (parsare, filtrări mari) merg într-un Web Worker; transferi ArrayBuffer-uri în loc să copiezi date uriașe.
• Controlul regresiilor: budgets în angular.json care pică build-ul, o verificare de performanță pe paginile cheie la fiecare release și un responsabil pentru cifre.

Apoi intră în detalii

• bypassSecurityTrust* e legitim doar pentru conținut pe care îl construiești și îl controlezi (un URL de embed dintr-un id validat). Un pipe generic „safeHtml” e un XSS reutilizabil; cauți aceste apeluri la fiecare review.
• CSP: Angular are nevoie de un nonce pentru stilurile inline — ngCspNonce pe elementul rădăcină sau token-ul CSP_NONCE; security.autoCsp calculează hash-uri la build, dar acoperă doar scripturile și nu funcționează cu SSR.
• Introduci CSP-ul întâi cu Content-Security-Policy-Report-Only, altfel chunk-urile lazy sau stilurile inline se strică în producție.
• CSRF cu cookie de sesiune: HttpClient trimite cookie-ul XSRF-TOKEN ca X-XSRF-TOKEN pe cererile care modifică date, către aceeași origine — dar serverul trebuie să-l seteze și să-l verifice. Orice verificare din frontend se repetă pe server.

Apoi intră în detalii

• Varianta naivă „refresh la fiecare 401” face N refresh-uri; cu rotația refresh token-ului se invalidează reciproc, iar unele servere tratează refolosirea ca atac și închid sesiunea.
• Marchezi login/refresh cu un HttpContextToken (SKIP_AUTH) ca interceptorul să nu se intercepteze singur, atașezi token-ul doar la URL-urile API-ului tău, iar dacă token-ul s-a schimbat deja de când a plecat cererea, doar reîncerci.
• Doar 401 declanșează refresh — 403 înseamnă „nu ai voie”. Un refresh eșuat înseamnă logout, curățarea store-urilor și cache-urilor și propagarea logout-ului în celelalte tab-uri (BroadcastChannel).
• La pornire, un provideAppInitializer încearcă un refresh înainte de prima rută. Cu un provider OIDC extern, folosești o bibliotecă certificată în loc să scrii singur PKCE și rotația.

private refreshInFlight: Observable<string> | null = null;

refresh(): Observable<string> {
  this.refreshInFlight ??= this.http
    .post<{ accessToken: string }>('/auth/refresh', null, {
      withCredentials: true,                            // HttpOnly cookie
      context: new HttpContext().set(SKIP_AUTH, true),  // not intercepted again
    })
    .pipe(
      map((r) => r.accessToken),
      tap((t) => this.token.set(t)),                    // access token: memory only
      finalize(() => (this.refreshInFlight = null)),
      shareReplay(1),                                   // every 401 waits for the same one
    );
  return this.refreshInFlight;
}

Apoi intră în detalii

• provideBrowserGlobalErrorListeners() trimite window.onerror și promise-urile respinse netratate la ErrorHandler; ții handler-ul simplu și sigur — dacă aruncă, pierzi toate erorile.
• @boundary prinde doar erorile de randare, nu pe cele din event handlers sau cod asincron, iar o eroare prinsă tot ajunge raportată la ErrorHandler.
• Interceptorul aruncă din nou eroarea după tratare (throwError(() => err)), ca apelanții să poată reacționa; un catchError(() => of([])) fără logare face bug-urile invizibile.
• UX și operare: centralizezi și deduplici toast-urile (nu cinci mesaje pentru o problemă), traduci erorile tehnice în erori de domeniu în adaptor și atașezi context (rută, versiune, remote) fiecărei erori logate.

Apoi intră în detalii

• switchMap pentru scrieri e periculos: un save anulat poate să fi ajuns sau nu pe server. Scrierile folosesc concatMap sau exhaustMap.
• catchError merge în proiecția interioară; pus după switchMap, prima cerere eșuată închide tot stream-ul, iar căutarea moare în tăcere.
• Un simplu shareReplay(1) are refCount: false: pe o sursă infinită (websocket, interval) nu se dezabonează niciodată. Folosești { bufferSize: 1, refCount: true } — știind că cache-ul rămâne doar dacă sursa s-a terminat.
• RxJS e bazat pe push, fără backpressure încorporat, deci alegi o politică: renunți (switchMap, exhaustMap, throttleTime, auditTime, debounceTime), grupezi (bufferTime) sau limitezi concurența (mergeMap(fn, 3)). O coadă concatMap nelimitată pe o sursă rapidă umflă memoria.

readonly results$ = this.query$.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap((q) =>
    this.api.search(q).pipe(
      catchError((err) => {
        this.log.error(err);
        return of([]);        // inside: only this request fails, the stream lives on
      }),
    ),
  ),
  shareReplay({ bufferSize: 1, refCount: true }),
);

Apoi intră în detalii

• Din v21 runner-ul implicit e Vitest (@angular/build:unit-test); Karma e deprecat, iar suitele vechi pot fi mutate cu schematic-ul experimental refactor-jasmine-vitest.
• Teste zoneless: await fixture.whenStable() în loc de fakeAsync, fake timers din Vitest pentru debounce, TestBed.tick() ca să ruleze effect-urile; input-uri ca semnale prin inputBinding.
• Cu ports & adapters, rulezi o singură suită de teste de contract pe fiecare adaptor; harness-urile din CDK fac testele de componente independente de structura DOM-ului.
• În CI: nx affected plus cache pentru viteză, fără cache pentru e2e nedeterministe pe un backend real, iar coverage-ul ca indicator, nu ca țintă.

Apoi intră în detalii

• Schimbarea limbii cu i18n-ul încorporat înseamnă reload, chiar și cu loadTranslations() la runtime, pentru că textele din template sunt evaluate la crearea componentelor.
• Pluralele cer ICU, nu n === 1 ? … : …: româna are one, few și other („20 de fișiere”). Nu concatenezi niciodată propoziții — ordinea cuvintelor diferă între limbi.
• Id-uri custom (@@cart.title) ca traducerile să supraviețuiască modificărilor textului sursă; datele, numerele și moneda prin pipe-uri cu LOCALE_ID și registerLocaleData.
• Se potrivește cu SSR/prerender (o variantă pe limbă, aleasă după URL), iar cu hidratarea adaugi withI18nSupport(). Începi din prima zi: i18n adăugat mai târziu înseamnă să vânezi fiecare text scris direct în cod.

Apoi intră în detalii

• Alegerea stratului: Aria pentru un design system propriu, CDK pentru primitive low-level (overlay, drag & drop, utilitare a11y), Material când vrei rapid un UI gata făcut.
• Stilizezi după starea ARIA pe care o setează directivele ([aria-selected='true']), ca starea vizuală și cea accesibilă să nu se poată desincroniza.
• Compromisuri în alte locuri: virtual scroll scoate din DOM rândurile din afara ecranului (Ctrl+F și cititoarele de ecran nu le văd); preferi paginarea unde contează accesibilitatea completă.
• Proces: verificări din tastatură și cu cititor de ecran în definition of done, verificări automate în CI și review de a11y ca parte din contractul design system-ului.

Apoi intră în detalii

• HTTP: fetch e backend-ul implicit, iar withFetch() e deprecat; progresul la upload cere withXhr(), iar reportProgress devine reportUploadProgress / reportDownloadProgress.
• Router și template-uri: paramsInheritanceStrategy: 'always' (rutele copil moștenesc params și data de la toți părinții), ?. întoarce undefined ca în TypeScript, un compilator mai strict (input-uri legate de două ori, data-* nu mai leagă input-uri), CanMatchFn cere currentSnapshot.
• Platformă și eliminări: TypeScript 6 și fără Node 20; ComponentFactoryResolver, ComponentFactory și provideRoutes au dispărut; pentru SSR configurezi allowedHosts și scoți withIncrementalHydration().
• Implementare: un branch de upgrade ținut verde în CI, bibliotecile și Node/TS actualizate întâi, e2e pe fluxurile critice, apoi un plan ulterior de a scoate Eager feature cu feature, în loc să-l tratezi ca permanent.