NgRx 22 releases Resource Extensions to prevent state reset in Angular's resource API

NgRx, the reactive state management framework for Angular, released version 22 this week, bringing utilities to customize Angular's own resource and httpResource, dynamic signals for union types, a new typing helper for the SignalStore, and compatibility with ESLint v10. The main highlight is a set of experimental extensions that address a behavior that bothers anyone using resource in production: the value reset during reload.

The problem NgRx 22 solves

Angular's resource and httpResource APIs reset value() to undefined whenever the resource enters a reload state, and throw an exception if the code tries to read value() while the resource is in an error state. In practice, this means a screen that depends on value() to render a list flashes blank on every update, and any state read right after a network error breaks the flow.

In the feature's original RFC, maintainer Marko Stanimirović explained why this behavior also hindered deeper integration with the SignalStore:

once a resource enters the error state, any subsequent patchState call will throw because it reads value() internally

Marko Stanimirović, NgRx maintainer

Resource extensions: patching without losing the type

The solution comes through a new experimental entry point, @ngrx/signals/resource. The extensions wrap an existing resource and fix just these two behaviors (value reset and error exception), preserving the resource's original type, including httpResource's more specific typing. There are four native extensions, and a provideResourceExtensions function registers the default behavior at the application, route, or component level, giving granular control over where the patch applies.

The proposal was well received by the community. Manfred Steyer, a reference author on Angular, responded enthusiastically and suggested adding an activation signal to the mechanism; another commenter on the RFC asked for parity with SolidJS's createResource, such as access to the current value inside the loader itself. A summary published on DEV Community noted that part of this behavior could already be reproduced by combining Angular's snapshot() with extra state logic, but highlighted the advantage of the new approach:

with Resource Extensions, you stay on the resource itself

DEV Community, summary on the NgRx 22 release

This means keeping the value writable and preserving the resource's more specific type, instead of creating a parallel state layer on top of it.

Who was already solving this another way

This problem isn't exclusive to NgRx. TanStack Query for Angular already offers retention of the previous data when switching query keys through the placeholderData: keepPreviousData option. Within the NgRx ecosystem itself, the community project NgRx Toolkit was already solving part of this too: the withResource feature has supported a previous value without throwing an exception in the error state since version 20.6.0. The difference with Resource Extensions is bringing this behavior to Angular's native resource, without requiring an additional store layer.

Dynamic deep signals for union types

The second relevant change in version 22 affects how the SignalStore types states modeled as a union. Until now, a state slice typed as a union (the natural way to represent "not loaded yet") collapsed into a single flat Signal, losing the granularity of access to internal fields.

Starting with version 22, each member of an object literal within the union gets its own DeepSignal, accessible after narrowing with in. For anyone modeling loading states as a union of types (something like { status: 'loading' } | { status: 'loaded', data: T }), this eliminates the need for cast workarounds to access specific fields after checking the status.

Other changes in version 22

Besides the two main highlights, the release brings minor adjustments that affect the day-to-day work of those maintaining larger SignalStores:

• A new SignalStoreFeatureType utility extracts the state and members from a feature factory, allowing custom features to reuse these types instead of manually redeclaring them.
• @ngrx/store-devtools gained an actionCreators option to dispatch actions directly from the Redux DevTools.
• @ngrx/eslint-plugin now supports ESLint v10, dropping support for ESLint v8 and the legacy .eslintrc format.
• The documentation site got a light theme.

How to update without pain

To migrate, the project needs to be on Angular 22, TypeScript 6.0, and RxJS in the ^6.5 or ^7.5 range. The update runs with ng update @ngrx/store@22 for those using the classic store, or ng update @ngrx/signals@22 for projects using only the SignalStore. Most breaking changes have an automated migration, detailed in the migration guide and the project's official changelog.

One separate warning is worth noting: Angular 22 changed the timing of resource itself, and a developer reported test failures caused by this change, which ended up documented as a breaking change in Angular's release notes. Anyone updating to NgRx 22 while also upgrading Angular to version 22 should review test suites that depend on resource timing before assuming the migration went cleanly.

NgRx's moment within modern Angular

The discussion around Angular 22 on Hacker News gave hints about how part of the community sees NgRx's role today. One comment summarized the advantage of the SignalStore over the classic reducer-based store approach:

NGRX Signals is the new way and its lovely. Instead of having 5 files to get state hooked up, its usually 1 file and all/most functionality is co-located.

Hacker News user, discussion about Angular 22

Another comment put NgRx itself into a broader context of framework simplification:

Modern Angular is MUCH nicer to use than the v2 days (or even the v4 days when I first started working with it). A lot of the required boilerplate is unnecessary nowadays. And even RxJS and NgRX are becoming less and less necessary to use too, which is great.

Hacker News user, discussion about Angular 22

For those maintaining SignalStores in production, the practical takeaway from release 22 is twofold: on one hand, NgRx reduces friction when dealing with async data via resource, something that previously required parallel state and hand-written value-retention logic; on the other, the Angular ecosystem itself keeps shrinking the area where an external state library is indispensable, which is a relevant data point for anyone deciding the stack of a new project today.