标签：#ngrx

We are pleased to announce the latest major version of the NgRx framework, featuring exciting new features, bug fixes, and other updates. Resource Extensions 🧩 Angular's resource and httpResource APIs cover a large part of async state management, but two very common requirements are not configurable at the resource level: Value on loading: when a resource reloads, value() resets to undefined until the new data arrives. Value on error: when a resource enters the error state, reading value() throws. The new @ngrx/signals/resource entry point addresses both cases with resource extensions : a set of utilities for customizing the behavior of a Resource in a composable, reusable way. They wrap an existing resource and patch only the parts of its behavior that should change, while fully preserving the original resource type. The extendResource function accepts the resource as the first argument, followed by the extensions to apply: import { Component } from ' @angular/core ' ; import { httpResource } from ' @angular/common/http ' ; import { extendResource , withPreviousValueOnLoading , withValueOnError , } from ' @ngrx/signals/resource ' ; @ Component ({ /* ... */ }) export class TodoList { // type: HttpResourceRef<Todo[] | undefined> readonly todosResource = extendResource ( httpResource < Todo [] > (() => ' /api/todos ' ), withPreviousValueOnLoading (), withValueOnError ( undefined ) ); } The returned resource is still the exact resource that was passed in, so no access is lost to the APIs of more specific resource types, such as WritableResource . Only value() behaves differently: it keeps the previously loaded todos while a reload is in flight, and returns undefined instead of throwing when the request fails. Built-in Extensions There are four built-in extensions: withPreviousValueOnLoading keeps the last resolved value while the resource is reloading, which is exactly what paginated and filtered lists need to avoid flickering. withValueOnLoading returns a specific fal

In recent years, Angular has taken an important step toward a simpler and more declarative reactivity model with the introduction of Signals . NgRx, which has long been the de facto standard for state management in complex Angular applications, followed this evolution by introducing Signal Store . The goal is not to completely replace @ngrx/store , but to offer a lighter and more local alternative, designed for use cases where the classic Actions → Reducers → Selectors pattern feels excessive. In this article, we'll see how to use NgRx Signal Store to build a reactive, typed store that integrates seamlessly with Angular components, drastically reducing boilerplate and improving code readability. This tutorial is aimed at Angular developers who are already familiar with Signals and "classic" NgRx. What is NgRx Signal Store NgRx Signal Store introduces a different way of thinking about state compared to classic @ngrx/store . A Signal Store : is not based on Redux does not use actions or reducers does not require explicit selectors Instead, the model revolves around three main concepts: 🧩 State State is defined as a set of signals , typically using withState . Each state property is immediately reactive and can be read directly by components. 🧠 Derived state Derived state is defined using withComputed . It is the conceptual equivalent of selectors, but with a more direct syntax and better integration with Angular's Signals system. 🔧 Methods State changes and side effects (such as HTTP calls) are encapsulated in methods declared with withMethods . This keeps the store logic in a single place, without having to orchestrate multiple files as in the traditional NgRx pattern. In other words, a Signal Store resembles a strongly structured reactive service more than a pure Redux store. This approach makes Signal Stores particularly suitable for: local or feature state small to medium-sized applications reducing complexity in contexts where Redux would be overkill Creating the