标签：#Rx

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

Rx.NET 7.0 has been released with a narrowly focused change aimed at reducing deployment size for Windows applications. The new version separates WPF, Windows Forms, UWP, and Windows Runtime integration from the main System.Reactive package, avoiding cases where self-contained applications could acquire tens of megabytes of unused framework dependencies. By Edin Kapić

There's a pattern I see a lot in Angular codebases that adopted Signals early: a developer discovers rxResource , loves that it handles loading and error state automatically, and then immediately reaches for tap() to write a signal inside the stream. private readonly resource = rxResource ({ params : () => this . paramsSignal (), stream : ({ params }) => this . api . fetch ( params ). pipe ( tap ( data => this . sideSignal . set ( data . meta )) // 💥 ) }); This looks harmless. It runs in development without complaint in zone-based Angular. Then you enable zoneless — or Angular tightens its reactive graph enforcement — and you get NG0600: Writing to signals is not allowed in a reactive context . The rxResource stream runs inside Angular's reactive scheduler. Signal writes there aren't just discouraged — they're illegal by design. The scheduler assumes computed signals and reactive contexts are read-only during evaluation. A write mid-computation breaks the glitch-free guarantee Angular's signal graph is built on. The fix I landed on: make the stream return everything it needs to return, as a single typed value. interface ResourceValue { readonly sections : Section []; readonly meta : Meta ; } private readonly resource = rxResource < ResourceValue , Params > ({ stream : ({ params }) => this . api . fetch ( params ). pipe ( map ( data => ({ sections : transform ( data ), meta : data . meta })) ) }); No tap . No side signal. Everything the rest of the store needs lives in resource.value() and can be read via computed . The lesson isn't "don't use tap". The lesson is that rxResource has a contract: it is a read primitive . Its stream is for fetching and transforming. If you're writing signals inside it, you're treating it as a command bus — and that's a different tool. Originally published on ysndmr.com .

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