withResources with fail resource is blocking the store.

[luandaja]

When a resource is in a failing state for any reason and you try to patchState, the console will display an error and the action will be skipped.

This behavior can be reproduced with this store and calling any increment method.

If I'm doing something wrong, please let me know.

import { withResource } from '@angular-architects/ngrx-toolkit';
import { resource } from '@angular/core';
import { patchState, signalStore, withMethods, withState } from '@ngrx/signals';

export const Store = signalStore(
  {
    providedIn: 'root',
  },
  withState({
    count: 0,
  }),

  withResource(() => ({
    test: resource({
      loader: () => {
        console.log('test');
        // throw new Error('test');
        return Promise.reject('test');
      },
    }),
    // test2: httpResource(() => 'https://www.not-exist'),
  })),
  withMethods((store) => ({
    increment() {
      patchState(store, { count: store.count() + 1 });
    },
    increment2() {
      patchState(store, (state) => ({ ...state, count: state.count + 1 }));
    },
  }))
);

Checking the ngrx/platform patchState code, the issue is because when we call patchState, this call internally calls getState that gets the value.

[luandaja]

In the withResources code, I moved the Value from state to props and now it is working, but I am not sure about that change (i'll research more).

However, that confirms the issue. When the resource is in a fail state, it cannot access the value, and if we keep the value as part of the state, we will call that signal as part of the ngrx/signals patchState.

[rainerhahnekamp]

@luandaja . That’s the behavior of angular resource. Accessing a value if it is in error state, it will always throw

[luandaja]

@luandaja . That’s the behavior of angular resource. Accessing a value if it is in error state, it will always throw

Sure, I got that. However, in the example, if the resource is in the fail state, I cannot update the store (even if this is unrelated to the resource part). Eg. executing the increment method. I think the failed resource should not block the whole store from being updated.

As a note: the code screenshots are form ngrx/platform and angular-architects/ngrx-toolkit source code.

[jdegand]

How about adding a try/catch inside loader to prevent entering into a failed state where you can't access the store?

A more complicated solution would be to separate into multiple stores (one for the count, etc).

[rainerhahnekamp]

I see two options:

1. Require users to explicitly check if error is undefined when a resource is part of the state, instead of directly calling getState.
2. Introduce an optional flag that preserves the resource’s value even when it is in an error state.

[luandaja]

The patchState is the one that calls the getState behind scenees.

It is not intuitive to think you cannot update the counter because the store has a resource in a failing state.

I am not sure about the flag for preserving the resource value due to that, as it modifies the original resource behavior, and this does not look like that kind of issue.

What about:

1. update ngrx/platform getState method to verify if is "safe" to call a value (if the store will use withResources this will be a common scenario)
2. or Is that crazy to move the generated {name}Value signal from state to props in the withResources code? at the end the stateSource [STATE_SOURCE]; only iterate over state keys. (like this screenshot withResources with fail resource is blocking the store. #242 (comment))

[rainerhahnekamp]

@luanda I guess we all don’t want to have a diverged behavior of resource. That’s why I brought in the flag option, which I see as the last resort.

I also agree that patchState should also work with an erroneous resource. Although it would be tempting to check what happens to the native resource if I change its value when it is in an error state.

Updating getState is out of scope, since we are here in the toolkit and not in the NgRx repo.
Moving the value to props would go against the core design of NgRx (it was like that in one first drafts actually and got reverted). It would mean that you cannot use patchState anymore to update state (which the resource is).

Maybe we find more ideas…

[nclskfm]

Hi @rainerhahnekamp, any updates on this? Could you please check, if my question on SO is related? I think this is a bug, but I'm not sure if it's the same one as in this issue. Otherwise, I would create a new issue.

[rainerhahnekamp]

At the moment, I only see a different approach in getState as an option. But that only means that the problems goes away for patchState. As soon as you call getState in your application code, the SignalStore would again throw. Would that be a viable option?

---

As for your SO question. Somebody posted already a stackblitz https://stackblitz.com/edit/stackblitz-starters-8pydvdea?file=package.json where withResource works without issues. Can you provide a modified version where I can see the error?

What's more important: You are saying

To simulate the production behaviour as closely as possible, we use the resource object instead of httpResource.

If you want to simulate the production behavior, you take the original SignalStore with httpService and use HttpTestingController to mock the HttpClient.