DEV Community: The Modern Web

Skip the App Stores: Build an Installable, Native-Like Mobile App with Angular, Ionic & PWA

mehdi — Mon, 10 Aug 2026 21:52:18 +0000

[!NOTE]

Summary: Progressive Web Apps (PWAs) combine the reach of the web with the native experience and speed of mobile apps. In this guide, we walk step-by-step through building an installable, native-like mobile app with Angular, Ionic, and PWA capabilities—covering service workers, web manifests, iOS Safari requirements, and instant free deployment.

Why Ionic Delivers That Authentic Native-Like Feel

Building a web app for mobile is easy, but making it feel native is where most web applications fail. This is where Ionic shines:

Native Touch Gestures: Ionic brings built-in mobile gestures—such as swipe-to-go-back, pull-to-refresh (ion-refresher), swipeable modals, and instant touch feedback—directly into the browser.
Hardware-Accelerated Animations: Transitions between pages (iOS slide-in, Android material push) run on the Web Animations API at 60fps/120fps with zero jank.
Adaptive Platform Styling: Ionic automatically adapts its UI controls—rendering iOS Human Interface Guidelines styling on Apple devices and Material Design on Android devices automatically from a single codebase.

Combining Ionic's native UI controls with Angular's PWA capabilities gives your users a mobile app that looks, feels, and responds exactly like an app downloaded from the App Store.

1. Setting Up Angular PWA Support

Angular CLI provides an official automated schematic to convert your project into a PWA:

npx ng add @angular/pwa

What this schematic generates:

public/manifest.webmanifest: Configures app name, theme color, display mode (standalone), and app icons.
ngsw-config.json: Defines caching strategies for static assets (index, JS, CSS) and dynamic lazy-loaded chunk bundles.
src/main.ts: Registers provideServiceWorker().
public/icons/: Generates a standard set of PWA icon assets (72x72 up to 512x512).

2. The `manifest.webmanifest` Asset Configuration

When serving your application with ionic serve or building for production, ensure angular.json maps your static public/ directory so the browser serves manifest.webmanifest cleanly at the root URL.

Update `angular.json`:

Add the public/ directory mapping to the "assets" array in angular.json:

"options": {
  "outputPath": {
    "base": "www",
    "browser": ""
  },
  "index": "src/index.html",
  "polyfills": ["src/polyfills.ts"],
  "tsConfig": "tsconfig.app.json",
  "inlineStyleLanguage": "scss",
  "assets": [
    {
      "glob": "**/*",
      "input": "public",
      "output": "."
    },
    {
      "glob": "**/*",
      "input": "src/assets",
      "output": "assets"
    }
  ]
}

By mapping "input": "public" to "output": ".", public/manifest.webmanifest is output cleanly at /manifest.webmanifest with HTTP 200 OK.

3. Understanding Mobile & iOS Safari PWA Requirements

To test real PWA capabilities on an iPhone:

HTTPS Requirement:

Desktop Chrome treats http://localhost as a secure origin. However, mobile devices (especially iOS Safari) require a valid HTTPS connection to register Service Workers and enable installable features.
Standalone Installation:

On iOS, standalone PWA capabilities activate after the user opens Safari, taps Share $\rightarrow$ Add to Home Screen, and launches the app from the standalone home screen icon.

4. Instant Production Deployment with Surge

To test real PWA capabilities on any mobile device without complex SSL certificate setup, deploy your production build folder (www/) using Surge.sh:

Step 1: Build the production bundle

ionic build --prod

Step 2: Deploy to Surge

npx surge www

Surge will immediately output a live, trusted HTTPS URL (e.g. https://my-ionic-pwa.surge.sh).

5. Testing Mobile Capabilities on iPhone

Open Safari on your iPhone and navigate to your Surge HTTPS URL (https://my-ionic-pwa.surge.sh).
Tap the Share button in Safari $\rightarrow$ Select Add to Home Screen.
Launch the app from the new icon on your home screen.
Experience your native-like mobile app running directly from the home screen!

6. Pro Tip: Future-Proof Code with Capacitor Plugins

Instead of calling browser Web APIs directly (like navigator.clipboard or custom camera file inputs), access device capabilities through official Capacitor Plugins (such as @capacitor/camera, @capacitor/clipboard, @capacitor/share, @capacitor/geolocation, and @capacitor/preferences).

[!TIP]
Why This Matters: Official Capacitor plugins feature first-class web implementations.
When your app runs in the browser or PWA, Capacitor automatically uses standard web APIs and UI fallbacks (via @ionic/pwa-elements). If you ever decide to publish your app to the Apple App Store or Google Play Store down the road, you won't need to change a single line of code—Capacitor seamlessly switches to native iOS and Android SDKs!

Conclusion

Building an installable, native-like mobile PWA with Angular & Ionic gives your users instant loading times, smooth gestures, and a native mobile feel right from the browser—bypassing app store review delays completely while leaving the door open for native app store deployment anytime.

Happy coding! 🚀

Does Capacitor Run a Local HTTP Server? How Hybrid Apps Actually Load Assets Under the Hood

mehdi — Mon, 10 Aug 2026 20:49:33 +0000

If you've ever inspected an Ionic or Capacitor app running on an iOS device using Safari Developer Tools or an Android device using Chrome Inspect, you've probably noticed something intriguing in the address bar:

iOS (Safari Inspector): capacitor://localhost/index.html
Android (Chrome Inspect): https://localhost/index.html

Seeing localhost naturally leads to a very logical question:

"Is Capacitor running a background HTTP server (like Node or Python) on my phone to serve web assets?"

The short answer is No, Capacitor does NOT run an HTTP server on your mobile device.

So why does DevTools display localhost, and how are your HTML, CSS, and JavaScript files loaded without a server? Let's take a deep dive under the hood.

1. Why `file://` Was Abandoned

In the early days of hybrid app development (like Cordova and PhoneGap), web assets were loaded directly off local storage using the file:// protocol:

file:///android_asset/www/index.html

While simple, using file:// created major headaches for modern web development:

CORS Violations: Browsers restrict cross-origin requests made from file:// to external API endpoints.
Disabled Web APIs: Modern browser features like window.fetch, Web Crypto, Service Workers, and localStorage often require a "Secure Context" (https:// or localhost) and fail or behave unpredictably on file://.
Broken Absolute Paths: Links like <img src="/assets/logo.png" /> break when resolved relative to file paths.

To give web apps a modern, standards-compliant environment, Capacitor had to make the browser engine think it was loading a website from localhost, without the performance and security overhead of running an actual HTTP server process.

2. The Illusion: Synthetic Scheme Handlers

Instead of opening a background network port, Capacitor uses native OS-level WebView hooks to intercept network requests inside the app's private memory space.

+-----------------------------------------------------------------------+
|                         Capacitor Mobile App                          |
|                                                                       |
|  +---------------------+                 +-------------------------+  |
|  |   WebView Engine    |                 |   Native Native Layer   |  |
|  | (WebKit / Chromium) |                 |     (Swift / Java)      |  |
|  +----------+----------+                 +------------+------------+  |
|             |                                         |               |
|             | 1. Request https://localhost/main.js    |               |
|             +---------------------------------------->|               |
|                                                       | 2. Intercepts |
|                                                       |    in memory  |
|                                                       |               |
|             3. Returns Byte Stream                    | 4. Reads file |
|             <-----------------------------------------+    from Disk  |
|                                                       |               |
+-------------------------------------------------------+---------------+
                                                        |
                                          +-------------v-------------+
                                          |   App Bundle (Flash/ROM)  |
                                          | index.html | main.js      |
                                          +---------------------------+

On iOS (Safari Engine)

Capacitor registers a native WKURLSchemeHandler for the custom scheme capacitor:// with the host localhost.

When the iOS WKWebView attempts to load capacitor://localhost/main.js, WebKit calls Capacitor’s Swift handler in memory. Capacitor reads main.js directly from the local disk using FileManager and streams the bytes back to the WebView.

On Android (Chromium Engine)

Capacitor uses WebViewAssetLoader mapped to https://localhost.

When Android's WebView requests https://localhost/main.js, Android overrides shouldInterceptRequest(). Capacitor opens a Java InputStream directly from the app’s .apk asset folder and hands it to Chromium.

The request never reaches network sockets or an external interface. It is handled 100% in-memory via native file streams.

3. Three Technical Proofs That No Server Exists

If you want to prove to yourself that there is no background HTTP server running on the device, try these tests:

Proof 1: Connection Refused in App Console

Inspect your live running app in Chrome/Safari DevTools and attempt to fetch localhost on any TCP port:

fetch('http://127.0.0.1:8080')
  .catch(err => console.error(err));
// Output: TypeError: Failed to fetch (ERR_CONNECTION_REFUSED)

If a server was listening, it would bind a socket on 127.0.0.1. Because no port is bound, the OS immediately rejects TCP connections.

Proof 2: Zero Open TCP Sockets (`netstat`)

Connect your mobile device to your machine and inspect active network sockets for your app process (e.g., using adb shell netstat -tuln on Android). You will find zero active listening TCP sockets associated with the Capacitor app process.

Proof 3: Open-Source Native Implementation

You can view the exact interceptor implementation in Capacitor's open-source repositories:

iOS: CAPBridgeViewController.swift handles WKURLSchemeTask.
Android: WebViewLocalServer.java handles WebResourceResponse.

4. The Memory Lifecycle: Flash (ROM) vs. RAM

Where do your assets actually live while the app is installed and running?

+---------------------------------------------------------------+
|                      FLASH STORAGE (ROM)                      |
|  Permanent package store (.apk / .ipa)                        |
|  Contains: index.html, bundle.js, styles.css, images          |
+-------------------------------+-------------------------------+
                                |
                                | App Launch / Native Intercept
                                v
+---------------------------------------------------------------+
|                           DEVICE RAM                          |
|  Active runtime execution memory                              |
|  Contains: V8/JavaScriptCore Heap, Parsed DOM Tree,           |
|            Rendered Bitmaps, In-Memory RAM Cache              |
+---------------------------------------------------------------+

At Rest (Flash Storage / ROM): Your bundled assets (.html, .js, .css, media) live inside the compiled .apk or .ipa binary stored on non-volatile Flash Memory.
At Launch (Streamed to RAM): When the app starts, Capacitor's native bridge opens a file stream to read bytes off Flash Storage into memory.
At Runtime (RAM): The browser engine (WebKit or Chromium) parses the JavaScript into V8/JavaScriptCore bytecode, creates the DOM tree, and holds uncompressed image bitmaps and in-memory cache directly in RAM.

Summary Cheat Sheet

Question	Answer
Does Capacitor run an HTTP server on mobile?	No. It uses native scheme handlers (`WKURLSchemeHandler` & `WebViewAssetLoader`).
Why does DevTools show `localhost`?	To trick the browser engine into enabling CORS & Secure Context Web APIs without `file://` restrictions.
Are files loaded over a network port?	No. Files are intercepted in-memory and read directly from local app storage.
Where are assets stored when the app is running?	Stored permanently on Flash Storage (ROM) and compiled/cached in RAM during execution.

What about Local Development Live Reload?

The only scenario where a real HTTP server is used is during local development. When you set server.url in capacitor.config.json (e.g. http://192.168.1.50:5173), your development computer runs a dev server (like Vite or Webpack), and the phone connects to your computer over Wi-Fi. In production builds, server.url is removed, and native scheme interception takes over!

Found this helpful? Share it with other hybrid mobile developers building with Ionic, Capacitor, React Native, or WebViews!

Give Your Data Superpowers: Perfect Autocomplete with NgRx SignalStore

mehdi — Sun, 09 Aug 2026 17:07:27 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

However, as applications grow, treating state as passive data containers causes business logic to bleed across components, pipes, and utility files. In this article, we’ll explore how to transform raw data into Smart Objects inside an NgRx SignalStore using Object Enrichment—and how to overcome Angular's Dependency Injection constraints cleanly using runInInjectionContext.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

Because these objects are strictly data containers with zero behavior, domain logic—like formatting full names or validating roles—gets scattered across component helper methods, utility functions, or template pipes.

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

Enriching the payload at write time (right after the API response and immediately before calling patchState) guarantees that every signal, selector, or component consuming the store automatically receives a smart object.

2. Performance Reality

Angular's computed() signal is memoized. It re-evaluates .map() only when rawUsers() updates. Because both write-time mapping and computed() execute exactly once per API payload update, performance is equivalent. Write-time enrichment is purely an architectural choice to enforce data safety.

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

Real-world domain logic often requires external state. For instance, determining if a user canEdit() might require checking if the user has an 'ADMIN' role and whether the active session has an 'EDIT_USER' permission in a global PermissionsStore:

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

As your domain model grows, threading multiple dependencies (AuthService, FeatureFlagStore, Router) through mapping calls creates brittle function signatures. Adding or removing a dependency breaks every mapping call across your codebase.

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

When execution yields at await firstValueFrom(...), Angular’s synchronous injection stack is cleared. When the API response resolves in a later microtask, calling enrichUser(dto) -> inject(PermissionsStore) finds zero active injection context.

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

This workaround relies on an implicit timing rule. If another developer refactors the method months later and inlines const enrich = createEnricher() after the await boundary, the code still compiles cleanly but crashes in production with NG0200.

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

If a domain method on a root entity needs to evaluate rules against component-scoped state (e.g., local form state or route parameters), pass Angular's Injector as an optional parameter to the domain method:

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

If logic relies heavily on local component state, keep that logic inside a component-scoped store or view model. Because component-level stores sit lower in Angular's DI hierarchy, they can freely inject root stores, access smart objects, and combine them with local UI state cleanly—without polluting the core object with component-level dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

End the Utility File Nightmare: Co-locating Logic in NgRx SignalStore

mehdi — Sun, 09 Aug 2026 17:06:55 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

Type Less, Discover More: Building Self-Contained Objects in Angular

mehdi — Sun, 09 Aug 2026 17:06:09 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

Supercharge Your NgRx SignalStore with Smart Objects

mehdi — Sun, 09 Aug 2026 17:05:24 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

Your Angular State is Too Passive (And How to Fix It)

mehdi — Sun, 09 Aug 2026 17:04:55 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

Stop Scattering Your Angular Logic: The "Smart Object" Pattern in NgRx SignalStore

mehdi — Sun, 09 Aug 2026 17:04:02 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

The Secret to Insanely Clean Business Logic in NgRx SignalStore

mehdi — Sun, 09 Aug 2026 17:02:35 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

The Cleanest Angular Architecture You Aren't Using Yet

mehdi — Sun, 09 Aug 2026 16:59:32 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

From Raw Data to Smart Objects: A Cleaner Way to Use NgRx SignalStore

mehdi — Sun, 09 Aug 2026 00:24:26 +0000

Building enterprise Angular applications often starts with the same pattern: fetching raw data objects from a REST API and storing them directly in application state.

🛠️ Interactive Playground & Code

Want to skip straight to the code? You can explore the full, working implementation in the GitHub Repository or test the live reactivity directly below:

⚡ StackBlitz Workspace: Open Live Playground
GitHub Repository: mehdi985/stackblitz-starters-cat5gpwk

1. The Passive Data Problem

When backend APIs return raw JSON payloads, we typically model them using TypeScript interfaces:

// 📁 user.model.ts
export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

This causes two major issues:

Poor Discoverability: Developers cannot rely on IDE autocomplete (user.) to discover available domain rules. They must hunt down utility functions or grep the codebase for pipes.
Logic Duplication: Basic domain rules get rewritten across multiple components, increasing the risk of bugs when business rules change.

2. Step 1: Smart Domain Objects (Without Dependency Injection)

To solve this, we can adopt a Smart Object approach via Object Enrichment (a Factory Mixin pattern).

Instead of treating User as passive data, we define an enriched interface containing methods, and a factory function that decorates incoming data with self-contained domain behavior.

// 📁 user.model.ts

// 1. Enriched Interface
export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
}

// 2. Factory Function (Object Enrichment)
export function enrichUser(dto: UserDto): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
  };
}

The Developer Experience (DX) Win

Now, typing user. in TypeScript or an Angular HTML template immediately surfaces fullName() and hasRole() via IDE autocomplete:

<!-- Instant discoverability in templates -->
<h3>{{ user.fullName() }}</h3>

@if (user.hasRole('ADMIN')) {
  <span class="badge">Admin User</span>
}

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

When integrating smart objects into an NgRx SignalStore, an obvious question arises:

"Why not keep raw data in store state and enrich it on read using a computed() signal?"

// ❌ THE "READ-TIME" ENRICHMENT APPROACH
export const UserStore = signalStore(
  withState({ rawUsers: [] as UserDto[] }),
  withComputed(({ rawUsers }) => ({
    users: computed(() => rawUsers().map(enrichUser)),
  }))
);

While this looks clean, transforming objects inside computed() introduces an architectural leak:

❌ Read-Time (computed): Store holds raw data -> Component A reads users (Smart Object ✅) -> Component B reads store.rawUsers() directly (Passive Data! ❌)
✅ Write-Time (at Source): API Response -> enrichUser() -> Store holds Smart Objects -> Any read path automatically gets Smart Objects ✅

1. Architectural Safety: Enriched by Default

If state holds raw data, nothing stops a developer from accessing store.rawUsers() directly or deriving a new computed signal straight from base state—completely bypassing the enriched methods.

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

// 📁 permissions.store.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class PermissionsStore {
  private readonly permissions = signal<string[]>(['EDIT_USER', 'DELETE_USER']);

  hasPermission(permission: string): boolean {
    return this.permissions().includes(permission);
  }

  togglePermission(permission: string): void {
    const current = this.permissions();
    if (current.includes(permission)) {
      this.permissions.set(current.filter((p) => p !== permission));
    } else {
      this.permissions.set([...current, permission]);
    }
  }
}

Passing Dependencies as Parameters

The simplest way to give our enrichment function access to PermissionsStore is to pass it explicitly:

// 📁 user.model.ts
export function enrichUser(dto: UserDto, permissionsStore: PermissionsStore): User {
  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Inside our SignalStore, we inject PermissionsStore and thread it into .map():

// 📁 user.store.ts
export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    permissionsStore = inject(PermissionsStore)
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      const rawUsers = await firstValueFrom(userService.fetchUsers());
      const enrichedUsers = rawUsers.map((dto) => enrichUser(dto, permissionsStore));

      patchState(store, { users: enrichedUsers, isLoading: false });
    },
  }))
);

The Drawback: Parameter Drilling

4. Step 3: Direct `inject()` & The `NG0200` Trap

To eliminate parameter drilling, we can call inject() directly inside the enrichment function:

// 📁 user.model.ts
import { inject } from '@angular/core';
import { PermissionsStore } from './permissions.store';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(): boolean;
}

export function enrichUser(dto: UserDto): User {
  // Resolved via Angular Injection Context at execution time
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Now, the signature is pristine: enrichUser(dto). However, updating your store method to use .map(enrichUser) triggers a runtime crash:

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  patchState(store, { isLoading: true });

  const rawUsers = await firstValueFrom(userService.fetchUsers());

  // 💥 RUNTIME CRASH: NG0200
  const enrichedUsers = rawUsers.map(enrichUser);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

NG0200: inject() must be called from an injection context such as a constructor, a factory function, a field initializer, or a function passed to runInInjectionContext.

Why Does This Crash? (The Microtask Boundary)

Angular’s inject() function relies on an active Injection Context tied strictly to synchronous execution stack frames.

[ Synchronous Store Setup ] ──► Injection Context ACTIVE ✅
            │
            ▼
   await firstValueFrom(...) ──► Microtask Boundary / Async Gap ⏸️
            │
            ▼
[ Async Resume Phase ]      ──► Injection Context LOST ❌ ──► NG0200 Error!

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

Developers often attempt to bypass this by creating a factory that captures dependencies synchronously before the await boundary:

// 📁 user.model.ts
export function createEnricher() {
  const permissionsStore = inject(PermissionsStore);

  return (dto: UserDto): User => ({
    ...dto,
    fullName() { return `${this.firstName}${this.lastName}`; },
    canEdit() {
      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  });
}

// 📁 user.store.ts
async loadUsers(): Promise<void> {
  // Captured synchronously before await ✅
  const enrich = createEnricher();

  const rawUsers = await firstValueFrom(userService.fetchUsers());
  const enrichedUsers = rawUsers.map(enrich);

  patchState(store, { users: enrichedUsers, isLoading: false });
}

The Refactoring Trap

6. Step 4: The Final Solution — `runInInjectionContext`

To make context restoration explicit and 100% refactor-proof, we inject Angular's EnvironmentInjector once during store setup and wrap the write-time transformation inside runInInjectionContext:

// 📁 user.store.ts
import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

interface UserState {
  users: User[];
  isLoading: boolean;
}

const initialState: UserState = {
  users: [],
  isLoading: false,
};

export const UserStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector) // 👈 1. Grab EnvironmentInjector
  ) => ({
    async loadUsers(): Promise<void> {
      patchState(store, { isLoading: true });

      try {
        // 2. Async API Call (Injection context drops after await)
        const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

        // 3. Explicitly restore Injection Context so enrichUser can call inject() without params
        const enrichedUsers = runInInjectionContext(injector, () =>
          rawUsers.map(enrichUser)
        );

        patchState(store, { users: enrichedUsers, isLoading: false });
      } catch (error) {
        patchState(store, { isLoading: false });
        console.error('Failed to load users:', error);
      }
    },
  }))
);

Integration with `@ngrx/signals/entities` (`withEntities`)

If your SignalStore uses entity management, this pattern plugs directly into setAllEntities:

import { EnvironmentInjector, inject, runInInjectionContext } from '@angular/core';
import { patchState, signalStore, withMethods } from '@ngrx/signals';
import { setAllEntities, withEntities } from '@ngrx/signals/entities';
import { firstValueFrom } from 'rxjs';
import { User, UserDto, enrichUser } from './user.model';
import { UserService } from './user.service';

export const UserEntityStore = signalStore(
  { providedIn: 'root' },
  withEntities<User>(),
  withMethods((
    store,
    userService = inject(UserService),
    injector = inject(EnvironmentInjector)
  ) => ({
    async loadUsers(): Promise<void> {
      const rawUsers: UserDto[] = await firstValueFrom(userService.fetchUsers());

      const enrichedUsers = runInInjectionContext(injector, () =>
        rawUsers.map(enrichUser)
      );

      patchState(store, setAllEntities(enrichedUsers));
    },
  }))
);

7. Section 5: DI Scope Rules & The Template Escape Hatch

Understanding how Angular’s Dependency Injection Hierarchy works is vital when using inject() inside smart objects:

An injection context can only resolve dependencies from its current level or higher up the DI tree toward the Root Injector.

[ Root / Environment Injector ] ──► Root Singletons (AuthService, Global Stores)
           │
           ▼
[ Component / Element Injector ] ─► Local Component State & Scoped Services

Root Stores (providedIn: 'root'): enrichUser() can only call inject() on services provided in root. Attempting to inject a service scoped to a local component provider will throw a NullInjectorError.
Component Stores (providers: [UserStore]): Passing a component's ElementInjector into runInInjectionContext allows enrichUser() to resolve both root singletons and local component-scoped services.

What If a Method Needs Component Context?

// 📁 user.model.ts
import { Injector, inject, runInInjectionContext } from '@angular/core';
import { PermissionsStore } from './permissions.store';
import { LocalComponentService } from './local-component.service';

export interface UserDto {
  id: string;
  firstName: string;
  lastName: string;
  roles: string[];
}

export interface User extends UserDto {
  fullName(): string;
  hasRole(role: string): boolean;
  canEdit(injector?: Injector): boolean;
}

export function enrichUser(dto: UserDto): User {
  const permissionsStore = inject(PermissionsStore);

  return {
    ...dto,
    fullName() {
      return `${this.firstName}${this.lastName}`;
    },
    hasRole(role: string) {
      return this.roles.includes(role);
    },
    canEdit(injector?: Injector) {
      if (injector) {
        return runInInjectionContext(injector, () => {
          const localContext = inject(LocalComponentService, { optional: true });
          if (localContext && !localContext.isEditingAllowed()) {
            return false;
          }
          return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
        });
      }

      return permissionsStore.hasPermission('EDIT_USER') && this.hasRole('ADMIN');
    },
  };
}

Expose the Injector in your component and pass it directly from the template binding:

// 📁 app.component.ts
import { Component, OnInit, Injector, inject } from '@angular/core';
import { UserStore } from './user.store';
import { PermissionsStore } from './permissions.store';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <div style="font-family: system-ui, -apple-system, sans-serif; padding: 24px; max-width: 700px; margin: 0 auto;">
      <h2>🚀 Step 4: Direct inject() with runInInjectionContext</h2>

      <div style="margin-bottom: 20px; padding: 12px; background: #f0f4f8; border-radius: 8px;">
        <button (click)="permissionsStore.togglePermission('EDIT_USER')">
          Toggle 'EDIT_USER' Permission
        </button>
        <span>
          Status: <strong>{{ permissionsStore.hasPermission('EDIT_USER') ? 'ALLOWED ✅' : 'REVOKED ❌' }}</strong>
        </span>
      </div>

      @if (userStore.isLoading()) {
        <p>Loading users...</p>
      } @else {
        <div>
          @for (user of userStore.users(); track user.id) {
            <div>
              <h3>{{ user.fullName() }}</h3>
              <p>Roles: {{ user.roles.join(', ') }}</p>

              <!-- Pass component injector directly from template binding -->
              @if (user.canEdit(injector)) {
                <button>✏️ Edit User</button>
              } @else {
                <span>No edit permission</span>
              }
            </div>
          }
        </div>
      }
    </div>
  `,
})
export class App implements OnInit {
  readonly userStore = inject(UserStore);
  readonly permissionsStore = inject(PermissionsStore);

  // Expose local ElementInjector to template
  protected readonly injector = inject(Injector);

  ngOnInit(): void {
    this.userStore.loadUsers();
  }
}

8. Architectural Guidance: Keep Domain Models Generic

While passing a local Injector into templates serves as a useful escape hatch, treat it as an exception rather than a primary pattern.

Keep smart objects focused strictly on core domain business rules and providedIn: 'root' dependencies.

Conclusion

Combining Write-Time Object Enrichment with Angular's runInInjectionContext provides a robust architecture for enterprise Angular applications:

Passive Data becomes Smart Objects, co-locating business logic with data.
SignalStore state is Enriched by Default, ensuring downstream selectors and components receive safe, typed domain models.
Parameter Drilling is Eliminated, keeping mapper signatures clean with direct inject() calls.
DI Boundaries are Safe, avoiding NG0200 async drops across HTTP boundaries.

Why Angular, Vue, and ESLint Can't Upgrade to TypeScript 7.0 (Yet) — And Why TS 7.1 Changes Everything

mehdi — Wed, 05 Aug 2026 15:04:43 +0000

[!NOTE]

Summary: TypeScript 7.0 shipped with a brand-new native compiler core (tsgo). However, if you try upgrading your Angular 22, Vue, Svelte, or ESLint project to TypeScript 7.0 today, your build will fail with ERESOLVE peer dependency locks. In this article, we explore the deep technical reasons why frontend frameworks can't use TS 7.0 yet, what an AST (Abstract Syntax Tree) compiler plugin is, and why TypeScript 7.1 is the release everyone is waiting for.

The Hype Around TypeScript 7.0

When Microsoft released TypeScript 7.0, the web development community was buzzing. Featuring a brand-new native compiler engine (often called tsgo), TS 7.0 promises 8x–12x faster compilation speeds.

Naturally, developers running npm install typescript@latest in their Angular 22, Vue, or React projects expect an instant speed boost.

Instead, running npm install typescript@^7.0.0 in an Angular 22 project throws a hard error:

npm error code ERESOLVE unable to resolve dependency tree
npm error Could not resolve dependency:
npm error peer typescript@">=6.0 <6.1" from @angular/compiler-cli@22.1.0
npm error peer typescript@">=6.0 <6.1" from @angular/build@22.1.3
npm error peer typescript@">=4.8.4 <6.1.0" from @typescript-eslint/parser@8.66.0

Why are Angular, Vue, Svelte, and typescript-eslint explicitly locking out TypeScript 7.0?

Plain `tsc` vs. Framework Compilers: The AST Connection

To understand why standard projects can upgrade TypeScript easily while frameworks cannot, we need to look at how compilers parse code.

1. Plain TypeScript Projects (React, Node.js, Express)

For a standard Node.js or React app, TypeScript (tsc) acts as a plain transpiler. It reads your code, strips type annotations (: string, : number), and emits .js files.

For these projects, upgrading TypeScript major versions is transparent.

2. Framework Compilers (Angular `ngc`, Vue SFC, Svelte, ESLint)

Frameworks do not use TypeScript as a plain transpiler. They hook directly into TypeScript's internal Programmatic Compiler API.

Source File: tab1.page.ts
 └── AST Parser (ts.createSourceFile)
      ├── ClassDeclaration: Tab1Page
      │    └── Decorator: @Component({ templateUrl: 'tab1.page.html' })
      │         └── Inline HTML Template Validator & Code Rewriter

What is an AST (Abstract Syntax Tree)?

An AST is a tree-like object structure representing your code.

Angular's compiler (@angular/compiler-cli / ngc) parses your HTML templates and correlates every element binding, event listener, and pipe directly against TypeScript AST nodes. Before TypeScript emits JavaScript, Angular's compiler rewrites AST nodes to transform @Component() decorators into Angular instructions (ɵɵdefineComponent()).

The Missing Piece in TypeScript 7.0

When Microsoft built TypeScript 7.0's native engine (tsgo), they focused on CLI compilation speed (tsc). However, TypeScript 7.0 omitted the public Programmatic Compiler API (ts.createProgram, ts.transform, ts.factory).

Because tools like @angular/compiler-cli, @vue/compiler-sfc, svelte-preprocess, and typescript-eslint rely on this Compiler API to parse and rewrite AST nodes, none of these tools can run on TypeScript 7.0 without breaking.

As a result, framework maintainers deliberately set strict peer dependency locks:

"peerDependencies": {
  "typescript": ">=6.0 <6.1"
}

Enter TypeScript 7.1: The Bridge for Toolmakers

The TypeScript team at Microsoft recognized this ecosystem blocker immediately. Work is already underway on TypeScript 7.1 (tracked on GitHub under issue #63703 - TypeScript 7.1 Iteration Plan).

What TS 7.1 Delivers:

Stable Programmatic Compiler API: Exposing the AST parser and transformer factory functions to external tools.
Framework Alignment: Enabling Angular, Vue, Svelte, and ESLint to leverage native tsgo speed without breaking custom AST transformations.

TypeScript 7.1 is targeted for release in Autumn 2026.

Will Upgrading to TS 7.1 Require Massive Framework Rewrites?

No. Because Microsoft and core framework maintainers (including the Angular team via GitHub issue #69719) are collaborating on the TS 7.1 Compiler API spec, framework adoption will be fast and smooth.

When TypeScript 7.1 lands, Angular will backport support into a minor release (e.g., Angular 22.2 or 22.3), allowing you to upgrade cleanly with:

npx ng update @angular/cli @angular/core

Key Takeaways for Developers

Stay on TypeScript ~6.0.3: If you are building on Angular 22, keep your package.json pinned to the officially supported range (~6.0.3).
Do NOT force --legacy-peer-deps: Forcing TS 7.0 into an Angular 22 build will cause compiler transformer crashes.
Look Ahead to TS 7.1: The entire frontend ecosystem is preparing for TypeScript 7.1 in Autumn 2026.

DEV Community: The Modern Web

Skip the App Stores: Build an Installable, Native-Like Mobile App with Angular, Ionic & PWA

Why Ionic Delivers That Authentic Native-Like Feel

1. Setting Up Angular PWA Support

What this schematic generates:

2. The manifest.webmanifest Asset Configuration

Update angular.json:

3. Understanding Mobile & iOS Safari PWA Requirements

4. Instant Production Deployment with Surge

Step 1: Build the production bundle

Step 2: Deploy to Surge

5. Testing Mobile Capabilities on iPhone

6. Pro Tip: Future-Proof Code with Capacitor Plugins

Conclusion

Does Capacitor Run a Local HTTP Server? How Hybrid Apps Actually Load Assets Under the Hood

1. Why file:// Was Abandoned

2. The Illusion: Synthetic Scheme Handlers

On iOS (Safari Engine)

On Android (Chromium Engine)

3. Three Technical Proofs That No Server Exists

Proof 1: Connection Refused in App Console

Proof 2: Zero Open TCP Sockets (netstat)

Proof 3: Open-Source Native Implementation

4. The Memory Lifecycle: Flash (ROM) vs. RAM

Summary Cheat Sheet

What about Local Development Live Reload?

Give Your Data Superpowers: Perfect Autocomplete with NgRx SignalStore

🛠️ Interactive Playground & Code

1. The Passive Data Problem

2. Step 1: Smart Domain Objects (Without Dependency Injection)

The Developer Experience (DX) Win

Architectural Deep-Dive: Write-Time vs. Read-Time computed()

1. Architectural Safety: Enriched by Default

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

Passing Dependencies as Parameters

The Drawback: Parameter Drilling

4. Step 3: Direct inject() & The NG0200 Trap

Why Does This Crash? (The Microtask Boundary)

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

The Refactoring Trap

6. Step 4: The Final Solution — runInInjectionContext

Integration with @ngrx/signals/entities (withEntities)

7. Section 5: DI Scope Rules & The Template Escape Hatch

What If a Method Needs Component Context?

8. Architectural Guidance: Keep Domain Models Generic

Conclusion

End the Utility File Nightmare: Co-locating Logic in NgRx SignalStore

🛠️ Interactive Playground & Code

1. The Passive Data Problem

2. Step 1: Smart Domain Objects (Without Dependency Injection)

The Developer Experience (DX) Win

Architectural Deep-Dive: Write-Time vs. Read-Time computed()

1. Architectural Safety: Enriched by Default

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

Passing Dependencies as Parameters

The Drawback: Parameter Drilling

4. Step 3: Direct inject() & The NG0200 Trap

Why Does This Crash? (The Microtask Boundary)

5. Step 3.5: The "Closure Factory" Workaround & Its Vulnerability

The Refactoring Trap

6. Step 4: The Final Solution — runInInjectionContext

Integration with @ngrx/signals/entities (withEntities)

7. Section 5: DI Scope Rules & The Template Escape Hatch

What If a Method Needs Component Context?

8. Architectural Guidance: Keep Domain Models Generic

Conclusion

Type Less, Discover More: Building Self-Contained Objects in Angular

🛠️ Interactive Playground & Code

1. The Passive Data Problem

2. Step 1: Smart Domain Objects (Without Dependency Injection)

The Developer Experience (DX) Win

Architectural Deep-Dive: Write-Time vs. Read-Time computed()

1. Architectural Safety: Enriched by Default

2. Performance Reality

3. Step 2: Tapping into Singleton Dependencies (Parameter Passing)

Passing Dependencies as Parameters

The Drawback: Parameter Drilling

4. Step 3: Direct inject() & The NG0200 Trap

2. The `manifest.webmanifest` Asset Configuration

Update `angular.json`:

1. Why `file://` Was Abandoned

Proof 2: Zero Open TCP Sockets (`netstat`)

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

4. Step 3: Direct `inject()` & The `NG0200` Trap

6. Step 4: The Final Solution — `runInInjectionContext`

Integration with `@ngrx/signals/entities` (`withEntities`)

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

4. Step 3: Direct `inject()` & The `NG0200` Trap

6. Step 4: The Final Solution — `runInInjectionContext`

Integration with `@ngrx/signals/entities` (`withEntities`)

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

4. Step 3: Direct `inject()` & The `NG0200` Trap

6. Step 4: The Final Solution — `runInInjectionContext`

Integration with `@ngrx/signals/entities` (`withEntities`)

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

4. Step 3: Direct `inject()` & The `NG0200` Trap

6. Step 4: The Final Solution — `runInInjectionContext`

Integration with `@ngrx/signals/entities` (`withEntities`)

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

4. Step 3: Direct `inject()` & The `NG0200` Trap

6. Step 4: The Final Solution — `runInInjectionContext`

Integration with `@ngrx/signals/entities` (`withEntities`)

Architectural Deep-Dive: Write-Time vs. Read-Time `computed()`

4. Step 3: Direct `inject()` & The `NG0200` Trap

6. Step 4: The Final Solution — `runInInjectionContext`

Integration with `@ngrx/signals/entities` (`withEntities`)