Fixing an AI‑Generated Angular 20+ Mess: Anti‑Pattern Triage, Real Tests, and a Stable Signals/SignalStore Core

The scene

The app looked good in screenshots, but real users saw double-fetches, ghost spinners, and ‘Change after checked’ flickers. Templates called functions with side‑effects; nested subscribes chained network calls with no cancellation; everything was typed as any. PrimeNG components were configured in templates via function calls, so change detection thrashed. There were no tests and no telemetry.

• Jittery UI and duplicate network calls

• Console flooded with errors that weren’t caught

• Zero tests on state logic

Constraints

We couldn’t pause delivery. Marketing had a launch window, and leadership needed a stability story this quarter. The ask: stabilize the core flows, keep SSR hydration healthy, and maintain role‑based behavior for multiple tenants.

• No delivery freeze

• Keep SSR fast

• Multitenant roles must remain intact

Top offenders I found (and you probably have)

Nested subscribes block cancellation and are easy to leak. Template functions and pipes with side‑effects force Angular to recompute constantly, spiking CPU. any types made SSR hydration non‑deterministic. A global singleton masqueraded as a store, so tests couldn’t isolate state. Errors were thrown inside subscribe callbacks—crashing change detection without user‑friendly recovery.

• Nested subscribes; ignored teardown

• Template functions causing side‑effects

• any typed state leaking everywhere

• Global singletons as mutable stores

• Ad‑hoc Observables mixing promises and streams

• Throwing inside subscriptions; no error boundaries

Why Signals/SignalStore matters here

Signals give you deterministic computed values and reduce the surface of accidental side‑effects. SignalStore offers a minimal backbone for state transitions, with explicit effects and retry/backoff. That’s the foundation for predictable tests and UX.

• Deterministic computed values

• Centralized mutation

• Testable read models

1) Instrument everything on day one

I installed Sentry with OpenTelemetry spans to see slow selectors vs network issues. GA4/Firebase caught drop‑offs in critical funnels. I wrapped risky refactors behind Remote Config flags so we could deploy continuously and release gradually.

• Sentry + OpenTelemetry

• GA4/Firebase Analytics

• Feature flags via Firebase Remote Config

2) Turn chaos into typed state

I introduced a DashboardStore slice that owns loading/error and a computed total. Effects use typed event payloads and exponential backoff for flaky endpoints. Now we could write deterministic tests and stop the spinner flicker.

• SignalStore for typed slices

• Computed read models

• Exponential retry with typed events

3) Kill nested subscribes and template functions

Anywhere I saw subscribe inside subscribe, I flattened with switchMap and moved into a store rxMethod. Templates now bind to signals or readonly inputs—no functions executed per change detection.

• Replace subscribes with rxMethod

• Use computed() in components

• Pure HTML bindings only

4) Add tests with the highest ROI

We started with store unit tests and a few component tests for error and loading states. Then we added thin E2E smoke tests for sign‑in, list->detail, and export—just enough to guard deployments without slowing the pipeline.

• Store logic and computed selectors

• Critical components via harness-like DOM tests

• E2E smoke on top three user journeys

Before: nested subscribes, side‑effects in getters

This is nearly verbatim from the code I inherited (names changed):

Bad component

@Component({
  selector: 'app-dashboard',
  templateUrl: './dashboard.component.html'
})
export class DashboardComponent implements OnInit, OnDestroy {
  data: any; // any everywhere
  sub?: Subscription;
  constructor(private svc: ApiService, private router: Router) {}

  ngOnInit() {
    this.sub = this.svc.getData().subscribe(res => {
      this.data = res;
      this.svc.getMore(res.id).subscribe(more => {
        this.data.more = more;
        if (this.data.more.error) {
          throw new Error('oops'); // crashes CD
        }
      });
    });
  }

  get total() { // side-effect in getter
    this.logPerf();
    return (this.data?.items || []).map(x => x.price).reduce((a,b)=>a+b, 0);
  }

  ngOnDestroy() { this.sub?.unsubscribe(); }
}

After: SignalStore + computed VM

import { Injectable, computed, inject, signal } from '@angular/core';
import { SignalStore, patchState, rxMethod } from '@ngrx/signals';
import { catchError, EMPTY, finalize, map, switchMap, tap } from 'rxjs';

interface Item { id: string; name: string; price: number; }
interface More { lastUpdated: string; error?: string }
interface DashboardState { items: Item[]; more?: More; loading: boolean; error?: string }

@Injectable({ providedIn: 'root' })
export class DashboardStore extends SignalStore<{ state: DashboardState }> {
  private api = inject(ApiService);

  constructor() {
    super({ state: { items: [], loading: false } });
  }

  readonly total = computed(() =>
    this.state().items.reduce((s, x) => s + x.price, 0)
  );

  readonly load = rxMethod<void>(trigger$ => trigger$.pipe(
    tap(() => patchState(this, { state: { ...this.state(), loading: true, error: undefined } })),
    switchMap(() => this.api.getData().pipe(
      switchMap(res => this.api.getMore(res.id).pipe(map(more => ({ res, more })))) ,
      tap(({ res, more }) => patchState(this, { state: { items: res.items, more, loading: false } })),
      catchError(err => {
        patchState(this, { state: { ...this.state(), loading: false, error: 'Load failed' } });
        return EMPTY;
      }),
      finalize(() => patchState(this, { state: { ...this.state(), loading: false } }))
    ))
  ));
}

@Component({
  selector: 'app-dashboard',
  standalone: true,
  template: `
    <section *ngIf="store.state().loading; else ready">
      <p-progressSpinner></p-progressSpinner>
    </section>
    <ng-template #ready>
      <div *ngFor="let item of store.state().items">
        {{ item.name }} – {{ item.price | currency }}
      </div>
      <footer>Total: {{ store.total() | currency }}</footer>
      <p *ngIf="store.state().error" class="error">{{ store.state().error }}</p>
    </ng-template>
  `
})
export class DashboardComponent {
  constructor(public store: DashboardStore) {
    this.store.load();
  }
}

Targeted tests that stick

import { TestBed, fakeAsync, tick } from '@angular/core/testing';
import { DashboardStore } from './dashboard.store';

it('computes total and clears loading deterministically', fakeAsync(() => {
  TestBed.configureTestingModule({
    providers: [
      DashboardStore,
      { provide: ApiService, useValue: createApiMock({
          getData: { items: [{ id: '1', name: 'X', price: 100 }] },
          getMore:  { lastUpdated: 'now' }
      })}
    ]
  });
  const store = TestBed.inject(DashboardStore);
  store.load();
  tick(); // resolves mocked observables
  expect(store.total()).toBe(100);
  expect(store.state().loading).toBe(false);
  expect(store.state().error).toBeUndefined();
}));

Affected-only CI that respects delivery speed

We enabled Nx affected to keep CI fast while still enforcing quality gates. Every PR spun up a Firebase preview channel for PM/QA to verify behind flags.

• Nx affected targets for lint/test/build

• Parallelism tuned to cache hits

GitHub Actions excerpt

name: ci
on: [pull_request]
jobs:
  affected:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
        with: { version: 9 }
      - run: pnpm install --frozen-lockfile
      - run: pnpm nx affected -t lint,test,build --base=origin/main --head=HEAD --parallel=3
      - run: pnpm nx run web:deploy:preview -- --message="${{ github.sha }}"

Stop regressions with ESLint rules

{
  "overrides": [
    {
      "files": ["*.ts"],
      "rules": {
        "rxjs/no-nested-subscribe": "error",
        "@typescript-eslint/no-explicit-any": "warn"
      }
    },
    {
      "files": ["*.html"],
      "rules": {
        "@angular-eslint/template/no-call-expression": "error"
      }
    }
  ]
}

• rxjs/no-nested-subscribe

• no-template-call-expression

What changed—numbers, not vibes

With a SignalStore backbone, pure templates, and basic tests, the app stopped jittering. PMs could ship safely through flags, and engineering got their evenings back. The telemetry proved it.

• Crash‑free sessions: 91% ➜ 99.6%

• P95 interaction latency: −38%

• Duplicates network calls: −72%

• Support tickets per 1k users: −45%

• Unit coverage in core modules: 12% ➜ 68%

• Bundle size: −18% via dead‑code elimination

Triggers that justify bringing in help now

If two or more of these are true, you’ll save weeks by bringing in a senior Angular consultant to set the backbone, guardrails, and tests. The trick is stabilizing without freezing delivery—that’s the playbook I’ve run at a global entertainment company, United, Charter, a broadcast media network, an insurance technology company, and an enterprise IoT hardware company.

• AI‑generated code that ‘works on my machine’ but not under load

• Frequent ‘Change after checked’ and hydration warnings

• No tests + weekly hotfixes

• Nested subscribes and any types throughout

• SSR renders fine but client hydration diverges

• Multi‑tenant data leakage risks

Engagement outline (time‑boxed, outcomes‑oriented)

We start with telemetry and diagnostics, stand up SignalStore slices for critical domains, replace jittery templates with pure bindings, and add tests that pay rent. CI gets Nx affected, preview deploys, and flag‑controlled rollouts. We finish with docs and a measured path forward.

• Days 1–2: Instrumentation + anti‑pattern inventory

• Days 3–5: Store backbone + refactor critical flows

• Days 6–10: Tests + CI guardrails + canary rollout

• Days 11–14: Backfill coverage, docs, handoff

What to instrument next

With stability in place, I usually add virtualization for large data sets, fill the AA gaps, and extend traces into Node.js or .NET services so the whole pipeline is observable. That’s how we kept United kiosks and Charter dashboards stable at scale.

• Extend OpenTelemetry spans across backend APIs

• Data virtualization for large tables (PrimeNG/virtualScroller)

• Budget for accessibility audits (AA) and keyboard traps