Before/After: Rescuing a Chaotic Angular Codebase into a Maintainable, Fast Angular 20 System (Signals + Nx, Real Numbers)

What I walked into

The first demo I saw looked like a pinball machine—charts repainted on every websocket tick, tables re-sorted on every keystroke, and a memory footprint that climbed until Chrome begged for mercy. Leadership asked if we could stabilize in weeks, not months. That’s the job.

• Angular 14 app, partial NgRx, lots of ad-hoc BehaviorSubjects

• Jittery PrimeNG tables and charts, renders spiking 30–60/sec

• Circular deps across features, flaky CI, failing unit tests

• No TypeScript strictness, inconsistent null handling, zone.js everywhere

Immediate baselines

I never refactor blind. We captured render counts with Angular DevTools, profiled flame charts, and turned on Firebase Performance and GA4 for p95 TTI and route transitions. These became our scoreboard.

• p95 TTI 5.2s (core route)

• Avg. renders per detail view: 180 during a 30s session

• Bundle 2.4MB (gz), vendor bloated

• Error rate 3.1% (unhandled promise rejections, null derefs)

Cost of chaos

In aviation, media, and telecom, real-time is table stakes. I’ve seen this at a major airline (kiosk reliability), Charter (ads telemetry), and a broadcast media network (scheduling). If your dashboard jitters, your business decisions jitter.

• Engineers spend cycles firefighting instead of shipping features

• Jitter and lag destroy trust and NPS

• Hiring suffers when candidates see a tangled repo

The modernization lever

For stakeholders evaluating an Angular consultant, the question is ROI and time-to-stability. The lever is disciplined modernization with guardrails and measurable outcomes.

• Signals + SignalStore cut accidental renders

• Nx boundaries prevent code rot

• Telemetry turns subjective UX into objective KPIs

Week 0–1: Stabilize the foundation

We didn’t forklift to a new app. We created safety rails first. Nx split the repo into domain libs (analytics, users, shared-ui) with tag-based rules so the anti-patterns couldn’t creep back in.

• Enable TypeScript strict, ESLint, and strictTemplates

• Introduce feature flags (Firebase Remote Config)

• Add Angular DevTools + Firebase Performance baselines

• Break circular deps; add Nx with enforceable boundaries

Week 1–2: Replace vibe-coded state with SignalStore

The state layer is where jitter is born. We moved the hot paths to SignalStore slices so updates are atomic and render-scoped.

• Typed event schemas for websocket payloads

• Selectors derive minimal recompute graphs

• Effects handle retry/backoff and error toasts

• PrimeNG tables/charts fed by derived, memoized signals

Week 2–3: Render discipline + data virtualization

Once state was quiet, rendering followed. Virtualization and debounced updates cut CPU spikes without harming perceived freshness.

• ChangeDetectionStrategy.OnPush everywhere it matters

• cdk-virtual-scroll and windowed queries

• Debounced inputs and coalesced UI updates

• Highcharts updated via computed signals, not imperative churn

Week 3–4: CI guardrails and zero-downtime release

Releases were done behind flags, with telemetry proving no regression before full rollout.

• Cypress component tests for critical widgets

• Lighthouse budgets in CI; Sentry + OpenTelemetry

• Blue/green via Firebase Hosting channel or feature flags

• Canary metrics compared before/after cutover

Code

import { signalStore, withState, withComputed, withMethods, patchState } from '@ngrx/signals';
import { inject } from '@angular/core';
import { WebSocketService } from '../data/ws.service';
import { retryBackoff } from './util-retry';

// Typed event schema
interface TelemetryPoint { ts: number; cpu: number; mem: number; region: 'us'|'eu'|'apac'; }
interface TelemetryState {
  points: TelemetryPoint[];
  region: 'us'|'eu'|'apac';
  status: 'idle'|'live'|'error';
}

const initial: TelemetryState = { points: [], region: 'us', status: 'idle' };

export const TelemetryStore = signalStore(
  { providedIn: 'root' },
  withState(initial),
  withComputed(({ points, region }) => ({
    // only recompute when inputs change
    latest: () => points().at(-1),
    avgCpu: () => {
      const filtered = points().filter(p => p.region === region());
      return filtered.length ? Math.round(filtered.reduce((a,b)=>a+b.cpu,0)/filtered.length) : 0;
    }
  })),
  withMethods((store, ws = inject(WebSocketService)) => ({
    setRegion(region: TelemetryState['region']) { patchState(store, { region }); },
    connect() {
      patchState(store, { status: 'live' });
      ws.stream<TelemetryPoint>('telemetry')
        .pipe(retryBackoff({ initialInterval: 500, maxInterval: 8000, jitter: true }))
        .subscribe({
          next: (p) => patchState(store, s => ({ points: [...s.points, p] }))),
          error: () => patchState(store, { status: 'error' })
        });
    }
  }))
);

Template usage

<p-panel header="Region: {{ store.region() | uppercase }}">
  <p-dropdown [options]="regions" [(ngModel)]="region" (onChange)="store.setRegion($event.value)"></p-dropdown>
  <app-cpu-gauge [value]="store.avgCpu()"></app-cpu-gauge>
  <small *ngIf="store.status()==='error'" class="p-error">Connection lost. Retrying…</small>
</p-panel>

Why this works

Signals keep render graphs tight, and the store owns retries and edge cases. We used similar patterns at a leading telecom provider for ads telemetry and at a broadcast media network for schedule updates.

• Atomic updates + derived selectors reduce repaint scope

• Typed events prevent undefined/null churn

• Backoff protects UX during outages (field-proven at a major airline kiosks)

Nx boundaries and cached builds

// nx.json (excerpt)
{
  "affected": { "defaultBase": "main" },
  "namedInputs": {
    "sharedGlobals": ["{workspaceRoot}/.eslintrc.json"],
    "default": ["{projectRoot}/**/*", "!{projectRoot}/**/*.spec.ts"],
    "production": ["default", "!{projectRoot}/**/*.spec.ts"]
  },
  "targetDefaults": {
    "build": { "cache": true, "inputs": ["production", "^production"] },
    "test": { "cache": true }
  }
}

GitHub Actions with budgets

name: ci
on: [push, pull_request]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with: { version: 9 }
      - run: pnpm install --frozen-lockfile
      - run: pnpm nx affected -t lint test build --parallel
      - run: pnpm cypress:component
      - run: pnpm lighthouse -- --ci --assertions.performance>=0.85

What this buys us

On a recent Charter-style analytics dashboard, this CI kept p95 TTI trending downward while the team shipped features at pace.

• Fast PR feedback + guardrails against regressions

• Objective UX gates via Lighthouse budgets

• Cache keeps velocity high even with strict checks

Snapshot

These outcomes mirror what I’ve delivered at a global entertainment company (employee/payments dashboards) and an enterprise IoT hardware company (device management UIs) where we also added telemetry and gating CI. For execs, the headline is clear: fewer fires, faster delivery, happier users.

• p95 TTI: 5.2s → 2.1s (-59%)

• Route render counts (detail view): 180 → 48 (-73%)

• Bundle: 2.4MB → 1.65MB gz (-31%)

• Error rate: 3.1% → 0.9% (-71%)

• Velocity: +55% story throughput after guardrails

Keep what works, scope what changes

I don’t force a wholesale NgRx rewrite. We keep stable pieces and move the noisy ones to Signals so we can show immediate render wins without a full reset.

• Wrap RxJS streams with typed adapters; migrate hot paths first

• Use SignalStore for slices with clear owners (auth, telemetry, layout)

• Feature-flag rollouts and compare metrics pre/post

Deterministic tests and SSR readiness

Even if SSR isn’t day-one, we prepare the code so SSR is an option—no work gets thrown away.

• Stable initial values via TransferState when SSR is present

• Component tests assert render counts and timing

• Selectors kept pure to protect future SSR moves

Common signals it’s time

If this describes your roadmap, bring in an Angular expert who can stabilize fast without halting feature delivery. I typically deliver the assessment within a week and a hardening plan in week two.

• You see jitter or CPU spikes during live demos

• CI is flaky or nonexistent; hotfixes ship untested

• Your team avoids touching certain modules for fear of breakage

• Version upgrades keep stalling on unknown risks

Engagement model

You want predictable outcomes and real metrics. That’s the bar.

• 2–4 weeks for rescues, 4–8 for full upgrades

• Remote-first with daily touchpoints and weekly executive readouts

• Proven playbooks from a global entertainment company, United, Charter, a broadcast media network, an insurance technology company, an enterprise IoT hardware company

PrimeNG + data virtualization

Imperative chart updates per tick cause redraw storms. Computed signals cut invalidation to only when data slices truly change.

• Use p-table with lazy load + cdk-virtual-scroll

• Only update chart series when computed signals change

Retry and device-state patterns (from kiosk work)

at a major airline, we built Docker-based hardware simulation to validate retry behavior with card readers and printers. The same patterns help any real-time dashboard survive the field.

• Exponential backoff with jitter; user-visible status

• Offline-first toasts and queued mutations

Design tokens and accessibility

Performance isn’t just speed; it’s usable speed. Tokens help ship polish without regressions.

• Density and typography tokens; AA contrast checks

• Focus management for live regions

What to do this week

Prove the win in a slice, then scale it. Your team will feel the difference immediately.

• Measure renders and p95 TTI; pick one noisy route

• Turn on strict mode; add ESLint, basic budgets, and Sentry

• Wrap one hot path in a SignalStore slice and ship behind a flag