RFC(@ngrx/signals): Resource Integration Alternative

[kobi2294]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

Introduction

This RFC proposes a different integration model between Angular Resource and SignalStore.

Today, Resource combines two responsibilities in one object:

1. async orchestration (loading lifecycle, race handling, reload semantics, errors)
2. state ownership (value and related status state)

That coupling is convenient, but it limits flexibility in real store-driven apps.

Teams often need explicit domain policies:

• what value should be visible during reload
• what value should be visible on source changes
• how error states recover
• whether local overrides should win over remote updates

It also makes composition harder when remote data must stay in sync with local state,
such as selected items, optimistic edits, or UI-specific flags.

SignalStore already provides a predictable model for state transitions:
methods represent events, patchState and updaters define transitions,
and computed signals derive read models.

The core idea is to keep that boundary:
Resource should handle transport and asynchrony,
while SignalStore remains the single owner of application state.

This keeps Resource strengths, reduces RxJS-heavy boilerplate,
and preserves explicit, testable, domain-specific state transitions.

Syntax

The API can be offered in three variants, ordered from minimal code and minimal flexibility to more verbose code with maximum control.

Basic Usage

In the simplest form, the consumer defines the resource and the feature takes care of wiring it into the store.

withResources((store) => ({
	user: httpResource(() => `https://myhost/api/user/${store.userId()}`),
}))

This variant would:

1. add core state fields such as userValue, userStatus, and userError
2. add computed signals such as userHasValue and userIsLoading
3. add a private method such as _userReload
4. update the state through patchState, using the resource values as-is

Custom Updaters

The second variant gives the consumer control over how resource snapshots are translated into state changes, while the feature still performs the actual patchState call.

withResources({
	user: withUpdaters(
		httpResource(() => `https://myhost/api/user/${store.userId()}`),
		(snapshot, state) => newPartialState
	),
})

This is flexible, but a single updater can easily turn into a long chain of status checks. To keep that logic structured, a helper such as resourceUpdaters(...) can provide defaults and let the consumer override only the cases they care about.

withResources({
	user: withUpdaters(
		httpResource(() => `https://myhost/api/user/${store.userId()}`),
		resourceUpdaters(
			resolved((value, state) => ({ userValue: value })),
			error((error, state) => ({ userValue: DEFAULT_USER, userError: error })),
			loading((state) => ({ userValue: state.userValue })),
			reloading((state) => ({ userValue: undefined })),
			local((value, state) => ({ userValue: value }))
		)
	),
})

Each function (such as resolved, error, loading) is a pre-built function that checks for a specific condition and returns either a pratial state, or undefined. The resourceUpdaters function composes them together. This syntax minimizes boilerplate but is also highly extendable.

Consumers should not be required to provide every handler. Any missing case can fall back to the default behavior. It is also possible to provide helpers that cover multiple states, such as busy(...) for both loading and reloading, or newValue(...) for both local and resolved values.

Custom Update Callback

The final variant gives the consumer full control over how state is updated. Instead of the feature calling patchState internally, it invokes user-provided callbacks.

withResources({
	user: withHandlers(
		httpResource(() => `https://myhost/api/user/${store.userId()}`),
		resourceHandlers({
			onResolved: (value, state, store) => updateState(store, 'userLoaded', { userValue: value }),
			onError: (error, state, store) => updateState(store, 'userError', { userError: error }),
		})
	),
})

This should be treated as a last resort. It enables advanced integrations, such as devtools-aware updates, but it also opens the door to anti-patterns. It's important to minimize the logic in the callbacks only to the intended use - update store state in response to resource lifecycle changes.

Describe any alternatives/workarounds you're currently using

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[rainerhahnekamp]

Hey @kobi2294,

It seems to me that this is an opinionated way, which would use snapshots under the hood. As you know, we need to find the right balance between opinionated and being generic.

For example, we could have an additional "long-notation" version:

withResources(({ userId }) => ({
  user: {
    resource: () => httpResource(() => `https://myhost/api/user/${userId()}`),
    snapshots: [handleError(err) => ({ status: 'loaded',  value: undefied })],
    extensions: [...]
  }
)})


function handleError<T>(
  errorHandler: (error: Error) => T
) {
  return (resource: Resource<T>) => {
    const res = computed(() => {
      const snap = resource.snapshot();
      if (snap.status === 'error') {
        try {
          return { status: 'resolved' as const, value: errorHandler(snap.error) };
        } catch (error) {
          if (error instanceof Error) {
            return { status: 'error' as const, error };
          }
        }
      }
      return snap;
  });

  return resourceFromSnapshots(res);
}}

In this case, handleError would be a factory function that returns a ResourceSnapshot. To construct the final resource for the SignalStore, we would apply all the snapshots and extensions to the original one.

In that case, your version should work, and if somebody else requires a different variation, they can do that as well.

I think if we allow users to integrate their snapshots into withResource in a very simple way, that this is the sweet spot.

[kobi2294]

Hey @kobi2294,

It seems to me that this is an opinionated way, which would use snapshots under the hood. As you know, we need to find the right balance between opinionated and being generic.

For example, we could have an additional "long-notation" version:

withResources(({ userId }) => ({
user: {
resource: () => httpResource(() => https://myhost/api/user/${userId()}),
snapshots: [handleError(err) => ({ status: 'loaded', value: undefied })],
extensions: [...]
}
)})

function handleError(
errorHandler: (error: Error) => T
) {
return (resource: Resource) => {
const res = computed(() => {
const snap = resource.snapshot();
if (snap.status === 'error') {
try {
return { status: 'resolved' as const, value: errorHandler(snap.error) };
} catch (error) {
if (error instanceof Error) {
return { status: 'error' as const, error };
}
}
}
return snap;
});

return resourceFromSnapshots(res);
}}
In this case, handleError would be a factory function that returns a ResourceSnapshot. To construct the final resource for the SignalStore, we would apply all the snapshots and extensions to the original one.

In that case, your version should work, and if somebody else requires a different variation, they can do that as well.

I think if we allow users to integrate their snapshots into withResource in a very simple way, that this is the sweet spot.

Hi @rainerhahnekamp :-)

The only thing that is missing for me here is the ability to include the previous state when calculating the new value. Remember that the focus of this approach is on modifying the state in a way that will allow the consumer to define various logics on how the state changes when the resource changes.

The proposed approach emphasizes 3 principles

1. The signal store holds the state - not the resource. We only use the resource for transport and synchronization
2. The resource status and value changes are applied on the store's core state using updater - "reducer-like" logic - that calculates the new state by combining the old state + the values coming from the resource.. That means that you can both read, and write, not just the resource value but also other properties from the core state.
3. The most flexible varient also let's you choose the update mechanism - This way, if you use a feature like withDevtools you can perform the changes using updateState instead of patchState and also supply an action name.

Here are some use cases that this approach enables

A. I want to support Undo. To do that, I keep the current value of the resource and also the previous one. When it changes I modify 2 properties - not just one.
B. I use withEntities and want to modify the entites with data coming from the resource using the built in updaters
C. I am maintaining an index of data coming from the resource. The resource returns a list of T and I keep it but also modify a Record<string, T> indexing by one of the properties - for performance.
D. As mentioned - I want all state changes to go through updateState so I can see them in the devtools, and also provide action name.
E. I have a flag "isDirty" that tells me if the entity was edited by the user. If so - I want to discard changes from the server.

It also supports all the useCases mentioned in #5126 although in a different way.

These are just some examples from real projects I encounter in the last 2 months :-)

[rainerhahnekamp]

1. The signal store holds the state - not the resource. We only use the resource for transport and synchronization

So at least in withResources the resource is not separated from the SignalStore. It is merged into it. The value is a subset of the SignalStore's state, and the same is true for the methods and the properties.

If you are using the resource to fetch data but need to update the "real state" afterwards, I actually think that resource is the wrong tool here. I don't think that each data fetch scenario can be done with the resource. On the contrary.

I think it is much easier and you have much more control if you use the patchState/rxState combination.

---

In the case you want that the SIgnalStore implements the Resource's API, then I think you are much better off just implementing it on your own:

singalStore(
  withState({ value: T }),
  withMethods(store => ({
    _reload() {
     // ...
   }
  })),
  // ...
)

---

Why do you want to use the resource here? Is there a specific reason?

[kobi2294]

I assume people will use resources on their transport services becuase this is a very straight forward tool that will become standard.

They will use it to:

1. Describe the trigger that decides when to load the data
2. Describe the logic that fetches the data and in some cases they will do it with very little syntax (httpResource - in most cases)
3. Enjoy the synchronization features, the automatic cancellation, and many more features

I don't see any reason to reinvent the same API so that the consumer can describe the transport. The resource APIs are perfect for that, and I think they will become the standard way to transport data from server, and from other asynchronous sources, to the client.

So I think "withResources" should allow them to reuse their resources with the store. As a best practice I think the resource will be defined regardless of the store, and in withResources the consumer will provide reference to existing resources.

And I dont think it is accurate to say that in the first variant the resource is merged into the store. In this specific variant it is copied to the store, but the store remains the single point of truth - not the resource.

Idealy I want to be able to modify things like status and value through patchState without informing the resource. For example -
In one of my applications we use local storage for caching, so that we can restore the last state of the application. If we use resource internally in the state - how would we reconstruct the last error returned from the server? (real life scenario that I had to tackle last week :-) )