Forem: Jordan Davis

Live Examples - Modern Angular Patterns (2025): Signals, NgRx, RxJS, Web Components, A11y & Performance Testing

Jordan Davis — Tue, 19 Aug 2025 04:46:52 +0000

Live demo: StackBlitz · Source: GitHub

I pulled together a hands-on Angular modern patterns showcase that demonstrates how to combine Signals, NgRx, RxJS, Web Components, and a pragmatic performance + a11y playbook. It targets the latest Angular (standalone components & new control flow) and is meant to be read in the code—then run, tweak, and profile.

Repo: https://github.com/jdavis-software/angular-modern-patterns-showcase
Instant demo: https://stackblitz.com/edit/angular-modern-patterns-showcase

Why this exists

Signals unlocked fine‑grained reactivity, standalone components simplified architecture, and NgRx matured into an ergonomic state stack. You’ll find a lot of articles about each thing in isolation; this repo focuses on how they fit together in real UI flows.

Quick start

Run it locally

git clone https://github.com/jdavis-software/angular-modern-patterns-showcase
cd angular-modern-patterns-showcase
npm i
npm start
# Visit http://localhost:4200

Or open in your browser (no setup):

👉 StackBlitz live demo

Contents at a glance

Signals vs NgRx — clear division of responsibility
When RxJS still shines — external streams, back-pressure, and composition
Web Components in Angular — native + Angular Elements, Shadow DOM styling
Performance playbook — render less, compute once, stream smart
Accessibility (WCAG 2.2) — keyboard-first and screen reader friendly
Performance testing — devtools, lab checks, and CI ideas

Tip: Scan the component folders and open the matching route in the running app to see each pattern live.

1) Signals: feature‑local state & derived data

Use Signals for UI-centric or feature-local state. Compute derivations and memoize expensive work with computed. Keep it close to the component.

import { signal, computed, effect } from '@angular/core';

type CartItem = { name: string; price: number; qty: number };

export class SignalsCartComponent {
  readonly items = signal<CartItem[]>([]);

  readonly count = computed(() => this.items().reduce((n, i) => n + i.qty, 0));
  readonly total = computed(() => this.items().reduce((s, i) => s + i.price * i.qty, 0));

  constructor() {
    effect(() => console.log('cart changed', this.items()));
  }

  add(item: CartItem) { this.items.update(xs => [...xs, item]); }
  clear() { this.items.set([]); }
}

Heuristics

If state is owned by a single feature/view and derived mostly for rendering, keep it in Signals.
Prefer computed over ad‑hoc transforms in templates to remove work from change detection.
Use small, testable derivations instead of big monolithic selectors where only one view cares.

2) NgRx: app‑wide state, effects, and time‑travel

Use NgRx when multiple features need the same source of truth, you need effects orchestration (server calls, caching, retries), or time‑travel/debuggability matters.

Bridge NgRx selectors to Signals with toSignal for ergonomic templates:

import { Store } from '@ngrx/store';
import { toSignal } from '@angular/core/rxjs-interop';
import { selectVisibleTodos } from './store/selectors';
import { todoToggled } from './store/actions';

export class TodosComponent {
  readonly todosSig = toSignal(this.store.select(selectVisibleTodos), { initialValue: [] });

  constructor(private store: Store) {}

  toggle(id: string) {
    this.store.dispatch(todoToggled({ id }));
  }
}

Rule of thumb

Signals: local view state + derived render data
NgRx: cross‑feature domain state + effects + devtools

3) Where RxJS still shines

Even with Signals, RxJS is unrivaled for external/continuous streams (websockets, DOM events, SSE), back‑pressure, multicasting, and complex async composition. Expose the result to the view as a Signal.

import { interval, Subject } from 'rxjs';
import { bufferTime, map, shareReplay } from 'rxjs/operators';

const source$ = interval(100); // noisy stream
export const batches$ = source$.pipe(
  bufferTime(2000),
  map(batch => ({ count: batch.length, last: batch.at(-1) })),
  shareReplay({ bufferSize: 1, refCount: true }),
);

import { toSignal } from '@angular/core/rxjs-interop';
export class DashboardComponent {
  readonly batchSig = toSignal(batches$, { initialValue: { count: 0, last: null } });
}

Guideline

Keep RxJS at the boundaries and for non-trivial async flows; bridge to Signals for consumption in templates.

4) Web Components in Angular

The repo shows two interop paths:

A) Consume native custom elements

Bind attributes/props like normal.
Listen to well-typed CustomEvent contracts—treat events as part of your API.
Theme via CSS custom properties that pierce Shadow DOM.

<progress-ring value="{{percent()}}" aria-label="Upload progress"></progress-ring>

B) Export Angular as a custom element (Angular Elements)

import { Injector } from '@angular/core';
import { createCustomElement } from '@angular/elements';
import { ProgressRingComponent } from './progress-ring.component';

export class AppModule {
  constructor(injector: Injector) {
    const ProgressEl = createCustomElement(ProgressRingComponent, { injector });
    customElements.define('progress-ring', ProgressEl);
  }
}

Styling across Shadow DOM

Prefer design tokens via CSS variables (e.g., --ring-color).
Avoid deep selectors; keep styling opt‑in and documented in the component README.

5) Performance playbook (practical)

Render less: use trackBy on every *ngFor; avoid recomputing arrays/objects in templates.
Compute once: push expensive work into computed signals or memoized selectors.
New control flow & @defer: lazy‑render non‑critical UI.
Change detection: drive updates via signals to minimize checks.
Virtualization: use CDK virtual scroll for large lists.
Network: preconnect critical origins; cache smartly at the HTTP layer.

@defer (on viewport) {
  <heavy-widget></heavy-widget>
}

<li *ngFor="let user of users(); trackBy: userId">{{ user.name }}</li>

userId = (_: number, u: { id: string }) => u.id;

6) Accessibility (WCAG 2.2 minded)

Semantic HTML first; ARIA only to fill gaps.
Keyboard-first: visible focus, logical tab order, and roving tabindex for composite widgets.
Focus trapping for dialogs; Escape closes; return focus to the invoker.
Live regions for async updates (e.g., background save).

// Roving tabindex (essentials)
current = signal(0);
onKey(e: KeyboardEvent) {
  if (e.key === 'ArrowRight') this.current.update(i => (i + 1) % this.items.length);
  if (e.key === 'ArrowLeft')  this.current.update(i => (i - 1 + this.items.length) % this.items.length);
}

7) Performance testing: how to measure this repo

You don’t improve what you don’t measure. Here are low‑friction ways to profile the examples locally or on StackBlitz.

A) Angular DevTools Profiler (Chrome)

Open the app, install Angular DevTools.
Navigate to a demo (e.g., list rendering).
Start profiling, interact (scroll/filter), stop and inspect change detection cycles and component hotspots.

B) Chrome Performance panel

npm start, open http://localhost:4200.
DevTools → Performance → Record.
Interact with the demo; Stop.
Inspect Main thread (scripting/layout/paint), long tasks, and FPS.

C) Lighthouse (lab checks)

With the app running locally:

npx lighthouse http://localhost:4200 --only-categories=performance --view

Compare before/after toggling patterns (e.g., adding trackBy, enabling @defer).

D) Web Vitals in code (field-ish signals)

Add a basic Web Vitals logger (optional) to see CLS/LCP/INP in DevTools console in dev builds.

// vitals.ts (add where convenient in dev)
import { onCLS, onLCP, onINP } from 'web-vitals';
onCLS(console.log);
onLCP(console.log);
onINP(console.log);

For CI: consider scripting a headless Lighthouse run against a static build and diffing scores to prevent performance regressions.

How to use these patterns at work

Start with Signals for local, view-level state. Promote to NgRx only when multiple features require the same data, or effects orchestration/debuggability are needed.
Keep RxJS at the edges and for non-trivial async flows, then bridge to Signals with toSignal().
Prefer Web Components when collaborating across frameworks or publishing design tokens.
Treat performance and a11y as acceptance criteria, not afterthoughts—measure early.

What’s next

Planned additions:

Signals + forms patterns (typed models & derived validity)
Router data with signals and granular prefetching
Hydration pitfalls checklist (SSR)
A dedicated “perf lab” comparing render strategies

If you want a pattern added, open an issue or PR. And if this helps, a ⭐ on the repo makes it easier for others to find.

Building Enterprise-Grade Angular Apps: Performance Techniques and Patterns Shaping the Future

Jordan Davis — Tue, 12 Aug 2025 22:03:21 +0000

Angular has matured into a highly capable framework for building large-scale, enterprise-grade applications. But as your application grows, so does the complexity of maintaining fast load times, smooth interactions, and scalable architectures.

In this post, we’ll explore current best practices and emerging patterns for building high-performance Angular applications that will stand the test of time — along with real-world examples and relevant sources.

1. Optimize Change Detection

Use `ChangeDetectionStrategy.OnPush`

Angular’s default change detection checks every component in the tree on each change detection cycle. For large apps, this can become costly.

@Component({
  selector: 'app-customer-list',
  templateUrl: './customer-list.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class CustomerListComponent {
  @Input() customers!: Customer[];
}

Why it matters:

OnPush tells Angular to only re-check a component when:

An input reference changes
An event inside the component triggers it
You manually mark it for check (ChangeDetectorRef.markForCheck())

Source: Angular Docs — Change Detection

2. Embrace Standalone Components and Signals (Angular v16+)

Standalone components and Angular Signals reduce module overhead and make reactivity more explicit, resulting in faster renders and better state tracking.

import { signal } from '@angular/core';

export class DashboardComponent {
  totalSales = signal<number>(0);

  updateSales(value: number) {
    this.totalSales.set(value);
  }
}

Why it matters:

Signals offer fine-grained reactivity similar to frameworks like Solid.js, and standalone components reduce NgModule bloat.

Source: Angular Blog — Signals

3. Lazy Loading & Route-Level Code Splitting

Break your app into smaller chunks to reduce initial load time.

const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () =>
      import('./admin/admin.routes').then(m => m.ADMIN_ROUTES)
  }
];

Best practice:

Use feature-based lazy loading for large areas of the app.
Apply preloading strategies (QuicklinkStrategy or custom) for frequently accessed routes.

Source: Angular Docs — Lazy Loading

4. Optimize Template Rendering

Avoid heavy computations in templates — use pipes or precomputed values.
Use trackBy in *ngFor to reduce DOM churn.

<li *ngFor="let customer of customers; trackBy: trackById">
  {{ customer.name }}
</li>

trackById(index: number, item: Customer): number {
  return item.id;
}

Source: Angular Docs — NgFor Performance

5. Efficient State Management

Choose the right state management tool for the scale of your app:

Signals + RxJS for smaller to medium stateful needs
NgRx or Akita for large, complex applications with shared state

Example: Combining Signals with RxJS for fine-grained reactivity.

import { signal, computed } from '@angular/core';
import { from } from 'rxjs';

export class CartService {
  private items = signal<Item[]>([]);
  total = computed(() => this.items().length);

  addItem(item: Item) {
    this.items.mutate(arr => arr.push(item));
  }
}

6. Optimize API Calls

Debounce user input before making HTTP calls
Use caching and memoization for repeated requests

this.searchTerms.pipe(
  debounceTime(300),
  distinctUntilChanged(),
  switchMap(term => this.apiService.search(term))
).subscribe();

Source: RxJS Operators

7. Ahead-of-Time (AOT) Compilation and Build Optimization

Enable AOT by default:

"configurations": {
  "production": {
    "aot": true,
    "buildOptimizer": true
  }
}

AOT reduces runtime errors and speeds up the app by compiling templates at build time.

Source: Angular Build Optimizer

8. Future Patterns to Watch

Signals-First State Management — Moving away from heavy global state towards localized, reactive state using Angular Signals.
Hydration for Angular Universal — Seamless server-to-client handoff for faster Time-To-Interactive.
ESM-Only Builds — Smaller, faster, tree-shakeable builds.
Micro-frontend Architectures with Module Federation — Scaling teams and apps without monolithic deployments.

Source:

Key Takeaways

Use OnPush change detection wherever possible.
Adopt Signals and Standalone Components to simplify and speed up rendering.
Apply lazy loading and code splitting to reduce initial load time.
Keep templates clean and use trackBy for performance.
Pick the right state management approach for your app's scale.
Optimize API calls with RxJS operators.
Stay ahead with future-ready patterns like hydration and module federation.

Implementing Passkeys in Large‑Scale Web Applications

Jordan Davis — Tue, 12 Aug 2025 15:40:50 +0000

Passwords are still the single biggest source of account takeovers, help‑desk tickets, and UX friction. In 2025, passkeys—built on FIDO2/WebAuthn—aren’t a shiny demo anymore; they’re the default for serious apps. If you’re running an enterprise product with millions of users, moving to passkeys pays off on three fronts: massively reduced credential‑stuffing and phishing risk, fewer support costs, and faster sign‑ins that users actually finish.

This guide is the straight talk version of passkey adoption at scale: what they are, where teams get burned, and the patterns that actually survive production traffic.

Background: What Passkeys Change (and Why It Matters)

FIDO2 marries WebAuthn (browser API) with CTAP (client‑to‑authenticator protocol). Instead of passwords, users authenticate with public‑key cryptography:

During registration, the client creates a per‑site key pair. The private key never leaves the device; the public key is sent to your server.
During authentication, the browser signs a server‑provided challenge with the private key. Your backend verifies the signature with the stored public key—no shared secrets to steal, no password to phish.

Key shifts versus traditional auth:

No reusable secret on the wire or in your DB. Password dumps become useless.
Phishing resistance via domain binding (the challenge is scoped to your RP ID).
Fewer “forgot password” flows, lower support volume, faster conversion.

Implementation Challenges You Need to Plan For

You can ship a proof of concept in a week. You can’t ship a reliable global rollout without tackling these four realities.

1) Scale & Performance

Attestation/Assertion payload sizes are bigger than a password post. Your edge and API gateways must handle spiky payloads (hundreds of KB in worst cases).
Cold starts in serverless lambdas during high‑traffic auth spikes will hurt. Keep auth paths as warm as you can; pin memory for crypto libs.
DB design: Store credential records (userId, credentialId, publicKey, transports, aaguid, signCount/backup‑eligible flags, createdAt, lastUsedAt). Index by userId and credentialId.
Rate limiting: Separate unauthenticated (registration/auth challenge) from authenticated routes. Put strict limits around challenge issuance.

2) Browser & Device Compatibility

Passkeys work on all modern browsers, but UX parity is not equal:

Platform authenticators (Touch ID, Windows Hello, Android biometrics) behave differently than cross‑platform keys (YubiKey). Your UI must clearly explain options and fallbacks.
Synced passkeys (iCloud Keychain, Google Password Manager) improve recovery but introduce multi‑device edge cases (e.g., new device, same account, different transport).
Some enterprise environments block BLE/NFC—make sure USB works and expose a “use a different device” path with QR codes (caBLE/Hybrid transport).

3) Integration with Existing Auth Systems

You probably have SSO, MFA, password resets, and device trust. Don’t big‑bang replace it all.

Hybrid rollout: Support password + TOTP and passkey side‑by‑side. Encourage passkey creation after successful password login (“Upgrade your sign‑in”).
Account linking: Multiple credentials per user. Treat credentials as first‑class resources: create, list, rename, set default, delete.
Risk & recovery: Keep break‑glass paths (backup OOB email/SMS or support‑verified reset). Document who can bypass and when.

4) User Onboarding & Support

Users don’t care about FIDO. They care about “does this sign me in faster?”

Copy matters: “Use Face ID or a security key” beats “Register a WebAuthn credential.”
Progressive disclosure: Start with the simplest recommended path; offer “use a hardware key” as an alternative.
Self‑service recovery: Clear UI to add another passkey while the user is signed in. Prompt users to add a second device on day one.

Architecture You Can Actually Run

High‑level flow (registration):

Client requests registration options from your backend.
Backend generates a challenge, chooses RP ID, and returns options.
Client calls navigator.credentials.create(...).
Client POSTs the credential to your backend.
Backend verifies attestation and persists credential metadata.

High‑level flow (authentication):

Client requests assertion options (challenge + allowCredentials).
Client calls navigator.credentials.get(...).
Backend verifies assertion (challenge, origin/RP ID, signature, signCount).
Backend issues a session (cookie) or token (JWT/opaque).

Code Examples (TypeScript/JS)

Below are deliberately low‑level examples to show what’s happening. In production you’ll likely use a vetted library for verification (e.g., @simplewebauthn/server on Node).

Registration (Client)

// registration.ts
type RegistrationOptions = PublicKeyCredentialCreationOptionsJSON;

export async function startRegistration() {
  const res = await fetch("/webauthn/registration/options", {
    method: "POST",
    credentials: "include",
  });
  const options: RegistrationOptions = await res.json();

  // Convert to proper types if your server returns JSON-friendly shapes
  const credential = (await navigator.credentials.create({
    publicKey: {
      challenge: base64urlToBuffer(options.challenge),
      rp: options.rp,
      user: {
        id: base64urlToBuffer(options.user.id),
        name: options.user.name,
        displayName: options.user.displayName,
      },
      pubKeyCredParams: options.pubKeyCredParams,
      authenticatorSelection: options.authenticatorSelection,
      timeout: options.timeout,
      attestation: options.attestation,
    },
  })) as PublicKeyCredential;

  const attestationResponse = credential.response as AuthenticatorAttestationResponse;

  await fetch("/webauthn/registration/verify", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    credentials: "include",
    body: JSON.stringify({
      id: credential.id,
      rawId: bufferToBase64url(credential.rawId),
      type: credential.type,
      response: {
        clientDataJSON: bufferToBase64url(attestationResponse.clientDataJSON),
        attestationObject: bufferToBase64url(attestationResponse.attestationObject),
      },
    }),
  });
}

// helpers
function base64urlToBuffer(value: string) {
  const pad = "=".repeat((4 - (value.length % 4)) % 4);
  const base64 = (value + pad).replace(/-/g, "+").replace(/_/g, "/");
  const raw = atob(base64);
  const buffer = new ArrayBuffer(raw.length);
  const bytes = new Uint8Array(buffer);
  for (let i = 0; i < raw.length; i++) bytes[i] = raw.charCodeAt(i);
  return buffer;
}
function bufferToBase64url(buffer: ArrayBuffer) {
  const bytes = new Uint8Array(buffer);
  let binary = "";
  for (let i = 0; i < bytes.byteLength; i++) binary += String.fromCharCode(bytes[i]);
  const base64 = btoa(binary).replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
  return base64;
}

Authentication (Client)

// authentication.ts
type AuthenticationOptions = PublicKeyCredentialRequestOptions;

export async function startAuthentication() {
  const res = await fetch("/webauthn/authentication/options", {
    method: "POST",
    credentials: "include",
  });
  const options: AuthenticationOptions = await res.json();

  const assertion = (await navigator.credentials.get({
    publicKey: {
      challenge: base64urlToBuffer(options.challenge as unknown as string),
      allowCredentials: options.allowCredentials?.map((c: any) => ({
        id: base64urlToBuffer(c.id),
        type: c.type,
        transports: c.transports,
      })),
      timeout: options.timeout,
      userVerification: options.userVerification,
      rpId: options.rpId,
    },
  })) as PublicKeyCredential;

  const response = assertion.response as AuthenticatorAssertionResponse;

  await fetch("/webauthn/authentication/verify", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    credentials: "include",
    body: JSON.stringify({
      id: assertion.id,
      rawId: bufferToBase64url(assertion.rawId),
      type: assertion.type,
      response: {
        clientDataJSON: bufferToBase64url(response.clientDataJSON),
        authenticatorData: bufferToBase64url(response.authenticatorData),
        signature: bufferToBase64url(response.signature),
        userHandle: response.userHandle ? bufferToBase64url(response.userHandle) : null,
      },
    }),
  });
}

Verification (Server‑Side Sketch, Node/Express)

// server/webauthn.ts (sketch)
import type { Request, Response } from "express";
import { generateChallenge, verifyAttestation, verifyAssertion } from "./webauthn-lib";
import { upsertCredential, getUserById, getCredentialById, updateSignCount } from "./db";

export async function registrationOptions(req: Request, res: Response) {
  const user = await getUserById(req.session.userId);
  const challenge = generateChallenge();
  req.session.challenge = challenge;
  res.json({
    rp: { id: "app.example.com", name: "Example App" },
    user: { id: user.idB64Url, name: user.email, displayName: user.displayName },
    challenge,
    pubKeyCredParams: [{ type: "public-key", alg: -7 }, { type: "public-key", alg: -257 }],
    authenticatorSelection: { residentKey: "preferred", userVerification: "preferred" },
    attestation: "none",
    timeout: 60000,
  });
}

export async function registrationVerify(req: Request, res: Response) {
  const { ok, credential } = await verifyAttestation(req.body, req.session.challenge, "app.example.com");
  if (!ok) return res.status(400).json({ error: "Invalid attestation" });
  await upsertCredential({
    userId: req.session.userId,
    credentialId: credential.id,
    publicKey: credential.publicKey,
    aaguid: credential.aaguid,
    transports: credential.transports,
    signCount: credential.signCount ?? 0,
  });
  res.sendStatus(200);
}

export async function authenticationOptions(req: Request, res: Response) {
  const user = await getUserById(req.body.userId);
  const creds = user.credentials.map((c: any) => ({ id: c.credentialId, type: "public-key", transports: c.transports }));
  const challenge = generateChallenge();
  req.session.challenge = challenge;
  res.json({ challenge, allowCredentials: creds, timeout: 60000, userVerification: "preferred", rpId: "app.example.com" });
}

export async function authenticationVerify(req: Request, res: Response) {
  const stored = await getCredentialById(req.body.id);
  const { ok, newSignCount } = await verifyAssertion(req.body, req.session.challenge, stored.publicKey, "app.example.com");
  if (!ok) return res.status(400).json({ error: "Invalid assertion" });
  await updateSignCount(stored.credentialId, newSignCount);
  // issue session/JWT here
  res.sendStatus(200);
}

Note: In production, use a robust library for verification logic and origin/RP ID enforcement. Keep your RP ID stable (usually your apex domain).

Best Practices from Enterprise Rollouts

Keep RP ID stable. Changing domains later is a migration headache.
Make “Add another passkey” a first‑session task. Push users to register a second device to reduce support tickets.
Instrument everything. Log registration starts/completions, failure reasons, and authenticator types. Treat passkey conversion like a funnel.
Prefer attestation: "none" unless you have a strict hardware security requirement—attestation adds complexity and PII considerations.
Offer clear fallback paths. Passkeys should be primary, not only. Keep a secure, rate‑limited recovery channel.
Guard challenges. One‑time use, short TTL, tie to IP/user agent as appropriate, and invalidate on success or timeout.
Session security still matters. Passkeys kill passwords, not session hijacking. Use HttpOnly, Secure, SameSite cookies, rotating tokens, CSRF protection where needed.

Rollout Strategy That Works

Phase 0 – Internal: Ship to employees on a staging domain; gather device matrix issues.
Phase 1 – Opt‑in: Show “Try passkeys” CTA after successful password login. Track adoption.
Phase 2 – Nudge: Present passkeys as recommended for high‑risk cohorts (admins, power users).
Phase 3 – Default: New accounts register a passkey during onboarding; passwords remain as backup.
Phase 4 – Password‑optional: Offer passkey‑only for orgs that opt in and have backup policies in place.

Key Takeaways

Passkeys slash phishing risk and support burden while speeding up sign‑ins.
Plan for scale: payload sizes, DB shape, warm paths, and strict rate limits.
Ship hybrid first: coexist with current auth; let users upgrade in‑flow.
Design the UX: clear copy, progressive options, and self‑service recovery.
Instrument the funnel and iterate—treat auth like a product.

Enterprise React Performance Techniques in 2025 — And the Patterns That Will Shape the Future

Jordan Davis — Tue, 12 Aug 2025 15:40:39 +0000

In enterprise-scale React applications, performance is more than a nice-to-have — it's a competitive advantage. Low-latency interactions improve retention, drive conversions, and make complex workflows feel effortless. In 2025, the React ecosystem is evolving rapidly, introducing features and patterns that demand a rethink of how we build performant apps at scale.

This article covers the latest production-proven performance techniques, plus a look ahead at the patterns set to transform enterprise React in the coming years.

Why Performance is the Enterprise Battleground

In high-stakes B2B and consumer apps, milliseconds can mean millions:

Internal tools: Productivity gains from faster UIs save labor costs.
SaaS platforms: Faster onboarding flows mean better trial-to-paid conversion.
E-commerce: Improved interaction speed boosts revenue and reduces bounce rates.

At enterprise scale, we’re dealing with massive bundles, complex data flows, and heterogeneous client devices. Performance optimization becomes a discipline, not an afterthought.

Related: Why Performance Matters for Business Success

The Current State of the Art (2025)

1. React 18+ Concurrent Rendering in Production

Concurrent features are no longer experimental. Large enterprises now leverage:

useTransition for non-blocking state updates (e.g., search filters, background refreshes).
startTransition to keep urgent interactions smooth during heavy updates.
Suspense for Data Fetching with frameworks like Next.js App Router.

Tip: Measure the impact with the React Profiler — concurrent rendering shines when paired with granular memoization.

const [isPending, startTransition] = useTransition();

function handleFilterChange(value: string) {
  startTransition(() => {
    setFilter(value);
  });
}

2. Selective Hydration with Streaming SSR

Modern SSR frameworks (Next.js, Remix, Hydrogen) now stream HTML to the client in chunks. Components hydrate selectively as needed, speeding up time-to-interactive.

Benefit: Reduces blocking hydration work on the client.
Pattern: Combine server components for static/slow-changing parts with client components for interactive areas.

// Example in Next.js App Router
export default async function Page() {
  const data = await getData();
  return (
    <>
      <Header /> {/* Server Component */}
      <InteractiveChart client:data={data} /> {/* Client Component */}
    </>
  );
}

Related: Streaming SSR in React 18

3. Fine-Grained Memoization & Reselect Patterns

Large apps still suffer from over-rendering. Modern enterprise teams are:

Using React.memo with precise props equality checks.
Memoizing derived state with useMemo and useCallback.
Centralizing derived data with Reselect in Redux to prevent wasted renders.

import { createSelector } from 'reselect';

const selectFilteredItems = createSelector(
  (state) => state.items,
  (state) => state.filter,
  (items, filter) => items.filter(item => item.type === filter)
);

4. React Server Components (RSC) in Enterprise Monoliths

RSC adoption is growing in enterprises using Next.js.

Advantages: Smaller JS bundles, no hydration cost for purely server-rendered components.
Challenges: Requires backend/frontend code colocation and CI/CD alignment.

Pattern: Isolate RSC boundaries clearly to avoid unexpected client bundling.

Related: React Server Components — Official RFC

5. Edge Rendering + Caching Strategies

With platforms like Vercel Edge, Cloudflare Workers, and Netlify Edge, enterprise teams now push rendering closer to the user:

Static data: Cache aggressively at the edge.
Dynamic data: Use stale-while-revalidate patterns to serve instantly while refreshing in the background.

export const revalidate = 60; // ISR in Next.js

Related: ISR in Next.js

Patterns That Will Change the Game in the Next 2–3 Years

1. Compiler-Driven React (React Forget)

React’s team is working on React Forget, an auto-memoizing compiler that removes the need for manual useMemo/useCallback in most cases.

Impact: Less boilerplate, fewer missed memoization opportunities.
Timeline: Experimental in 2025, expected to stabilize in 2026.

2. State Management Shift to Signals

Libraries like Preact Signals and React Canary Signals are introducing fine-grained reactivity — updating only what’s used, not the whole component.

Impact: Reduces rendering work dramatically in complex UIs.
Prediction: Framework integration will make signals mainstream.

3. Full-Stack React with Native Data Layer

Future React frameworks may ship with built-in, server-synced state, eliminating manual client data fetching and normalization.

Impact: Less glue code, fewer cache invalidation bugs.
Prediction: Inspired by Relay + RSC fusion.

4. Intelligent Prefetching at Scale

Next-gen router APIs will integrate AI-driven heuristics to predict navigation patterns and prefetch assets/data before the user clicks.

Impact: Perceived speedups of 200–400ms without manual tuning.

Related: Next.js Prefetching

Best Practices for Today (and Tomorrow-Proofing)

Measure before optimizing — use React Profiler, Lighthouse, and Web Vitals.
Chunk your bundles — leverage dynamic imports and route-level code splitting.
Adopt concurrent rendering early — train your team now.
Introduce Server Components gradually — start with low-risk UI areas.
Invest in edge caching — it’s the cheapest latency reduction.
Stay close to React RFCs — future patterns like signals and compiler optimizations will require mindset shifts.

Key Takeaways

Enterprise React performance is now a mix of runtime features and build-time optimizations — concurrent rendering, RSC, selective hydration.
Future patterns will reduce developer burden (React Forget) and improve reactivity (Signals).
Edge-first delivery + AI-powered prefetching will redefine what “instant” means in enterprise apps.
Start adopting gradual migration strategies today to avoid costly rewrites.

Mastering React Query in 2025: A Deep Dive into Data Fetching for Modern Apps

Jordan Davis — Tue, 12 Aug 2025 15:39:57 +0000

When building modern React applications, data fetching is no longer just about hitting an API — it’s about caching, synchronization, background updates, offline support, and delivering a seamless UX even under poor network conditions.

In 2025, React Query (now part of TanStack Query) remains the go-to library for managing server state, with a mature API, strong community, and deep integration with modern React features like Suspense, concurrent rendering, and server components.

This guide takes you beyond the basics into enterprise-grade patterns, real-world optimizations, and future-facing features.

Why React Query?

React Query eliminates much of the boilerplate traditionally associated with data fetching by providing:

Smart Caching — Cache results and re-use them without redundant network calls.
Automatic Background Updates — Keep data fresh without manual refetch logic.
Out-of-the-Box Pagination & Infinite Loading — Easily implement common UI patterns.
Offline & Network Recovery — Queue mutations and retry on reconnect.
Devtools Integration — Inspect queries, cache, and performance in real-time.

Related: Official React Query Documentation

Core Concepts

Queries

A query is any async function whose result you want to cache and manage.

import { useQuery } from '@tanstack/react-query';

function Todos() {
  const { data, isLoading, error } = useQuery({
    queryKey: ['todos'],
    queryFn: () => fetch('/api/todos').then(res => res.json()),
  });

  if (isLoading) return <span>Loading...</span>;
  if (error) return <span>Error: {error.message}</span>;

  return <ul>{data.map(todo => <li key={todo.id}>{todo.title}</li>)}</ul>;
}

Related: Queries in React Query

Mutations

Mutations handle creating, updating, or deleting data on the server.

import { useMutation, useQueryClient } from '@tanstack/react-query';

function AddTodo() {
  const queryClient = useQueryClient();
  const mutation = useMutation({
    mutationFn: (newTodo) => fetch('/api/todos', {
      method: 'POST',
      body: JSON.stringify(newTodo),
    }),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: ['todos'] });
    },
  });

  return (
    <button onClick={() => mutation.mutate({ title: 'New Task' })}>
      Add Todo
    </button>
  );
}

Related: Mutations in React Query

Advanced Patterns

1. Prefetching & Initial Data

Prefetch queries before a user navigates to a page for instant load.

await queryClient.prefetchQuery({
  queryKey: ['projects'],
  queryFn: fetchProjects,
});

Related: Prefetching

2. Infinite Queries for Endless Scrolling

React Query’s useInfiniteQuery simplifies infinite loading patterns.

const {
  data,
  fetchNextPage,
  hasNextPage,
  isFetchingNextPage,
} = useInfiniteQuery({
  queryKey: ['projects'],
  queryFn: fetchProjectsPaginated,
  getNextPageParam: (lastPage) => lastPage.nextCursor,
});

Related: Infinite Queries

3. Optimistic Updates

Give users instant feedback by updating the UI before the server confirms.

const mutation = useMutation({
  mutationFn: updateTodo,
  onMutate: async (updatedTodo) => {
    await queryClient.cancelQueries({ queryKey: ['todos'] });
    const previousTodos = queryClient.getQueryData(['todos']);
    queryClient.setQueryData(['todos'], old =>
      old.map(todo => todo.id === updatedTodo.id ? updatedTodo : todo)
    );
    return { previousTodos };
  },
  onError: (err, updatedTodo, context) => {
    queryClient.setQueryData(['todos'], context.previousTodos);
  },
  onSettled: () => {
    queryClient.invalidateQueries({ queryKey: ['todos'] });
  },
});

Related: Optimistic Updates

4. Offline Support

With React Query’s integration with localforage, you can persist cache and enable offline-ready experiences.

import { persistQueryClient } from '@tanstack/react-query-persist-client';
import { createSyncStoragePersister } from '@tanstack/query-sync-storage-persister';

const localStoragePersister = createSyncStoragePersister({ storage: window.localStorage });

persistQueryClient({
  queryClient,
  persister: localStoragePersister,
});

Related: Persisting Queries

Performance Considerations

Cache Time vs Stale Time — Tune to balance freshness and performance.
Batching & Window Focus — Disable refetch on window focus if unnecessary.
Server-Side Rendering (SSR) — Prefetch data server-side and hydrate on the client.
Devtools in Production? — Only enable in staging/dev environments.

Related: Performance Optimizations

React Query in the Context of RSC and Concurrent Features

With React 18 and beyond:

Suspense for Data Fetching pairs perfectly with React Query for declarative loading states.
Concurrent Rendering benefits from React Query’s ability to pause and resume work seamlessly.
React Server Components (RSC) can integrate with React Query for hybrid data-fetching strategies.

Related: Using React Query with Suspense

Key Takeaways

React Query abstracts server-state management, enabling fast, reliable, and maintainable data flows.
Prefetching, infinite queries, optimistic updates, and offline support are production-grade must-haves.
Tuning cache/stale times and integrating with Suspense/RSC ensures your app is ready for the future of React.

Forem: Jordan Davis

Live Examples - Modern Angular Patterns (2025): Signals, NgRx, RxJS, Web Components, A11y & Performance Testing

Why this exists

Quick start

Contents at a glance

1) Signals: feature‑local state & derived data

2) NgRx: app‑wide state, effects, and time‑travel

3) Where RxJS still shines

4) Web Components in Angular

A) Consume native custom elements

B) Export Angular as a custom element (Angular Elements)

5) Performance playbook (practical)

6) Accessibility (WCAG 2.2 minded)

7) Performance testing: how to measure this repo

A) Angular DevTools Profiler (Chrome)

B) Chrome Performance panel

C) Lighthouse (lab checks)

D) Web Vitals in code (field-ish signals)

How to use these patterns at work

What’s next

Links

Building Enterprise-Grade Angular Apps: Performance Techniques and Patterns Shaping the Future

1. Optimize Change Detection

Use ChangeDetectionStrategy.OnPush

2. Embrace Standalone Components and Signals (Angular v16+)

3. Lazy Loading & Route-Level Code Splitting

4. Optimize Template Rendering

5. Efficient State Management

6. Optimize API Calls

7. Ahead-of-Time (AOT) Compilation and Build Optimization

8. Future Patterns to Watch

Key Takeaways

Implementing Passkeys in Large‑Scale Web Applications

Background: What Passkeys Change (and Why It Matters)

Implementation Challenges You Need to Plan For

1) Scale & Performance

2) Browser & Device Compatibility

3) Integration with Existing Auth Systems

4) User Onboarding & Support

Architecture You Can Actually Run

Code Examples (TypeScript/JS)

Registration (Client)

Authentication (Client)

Verification (Server‑Side Sketch, Node/Express)

Best Practices from Enterprise Rollouts

Rollout Strategy That Works

Key Takeaways

Enterprise React Performance Techniques in 2025 — And the Patterns That Will Shape the Future

Why Performance is the Enterprise Battleground

The Current State of the Art (2025)

1. React 18+ Concurrent Rendering in Production

2. Selective Hydration with Streaming SSR

3. Fine-Grained Memoization & Reselect Patterns

4. React Server Components (RSC) in Enterprise Monoliths

5. Edge Rendering + Caching Strategies

Patterns That Will Change the Game in the Next 2–3 Years

1. Compiler-Driven React (React Forget)

2. State Management Shift to Signals

3. Full-Stack React with Native Data Layer

4. Intelligent Prefetching at Scale

Best Practices for Today (and Tomorrow-Proofing)

Key Takeaways

Mastering React Query in 2025: A Deep Dive into Data Fetching for Modern Apps

Why React Query?

Core Concepts

Queries

Mutations

Advanced Patterns

1. Prefetching & Initial Data

2. Infinite Queries for Endless Scrolling

3. Optimistic Updates

4. Offline Support

Performance Considerations

React Query in the Context of RSC and Concurrent Features

Key Takeaways

Use `ChangeDetectionStrategy.OnPush`