Managing granular per-entity loading states in SignalStore collections

[Tiime-LcsGa]

When working with entity stores, I frequently encounter a specific UI/UX challenge:

• I load a collection and manage global feedback using setLoading / setLoaded.
• The entities are displayed in a list or table (e.g., Angular Material).
• Each row features specific actions like Delete, Update, etc.

The Problem:

Currently, these actions share the same "request status" as the rest of the store. If I trigger a "Delete" action on one row, the entire store reflects a loading state. I cannot distinguish which specific entity is being processed, resulting in a UI where either every row shows a spinner or none do.

Considered Alternatives:

I’ve thought about providing a separate single-entity SignalStore for every row. However, it's not possible (or I missed something) to implement with components like MatTable, where row templates are managed internally and no custom injector can be provided.

My Current (Non-Ideal) Workaround:

Before switching to ngrx-toolkit, I implemented a custom withRequestStatus feature that accepts a payload. This requires calling a withPayload method directly in the template to filter the status, which feels clunky — even in a zoneless environment.

<td mat-cell *matCellDef="let row">
  <button mat-icon-button (click)="store.delete(row.id)">
    @let (store.deleteLoading() && store.withPayload('delete', row.id)) {    
      <mat-icon>pending</mat-icon>
    } @else {
      <mat-icon>delete</mat-icon>
    }
  </button>
</td>

Question:

How do you address granular, per-row feedback? Is there a pattern for tracking "active" entity IDs during side effects without bloating the global state?

[michael-small]

I don't work with entities myself, so perhaps my perspective here is missing some essentials.

To clarify, when you say "I load a collection and manage global feedback using setLoading / setLoaded.", are you talking about using that from withCallState()? Or is that from your withRequestStatus?

withCallState has named collections, and you can specify multiple collections in the same feature.

[Tiime-LcsGa]

You are right, I wasn't clear enough. Here are some clarifications regarding my use case:

• I am currently using a custom withRequestStatus and would like to switch to the official withCallState.
• When I mentioned "loading a collection," I was referring to a generic list of entities, not the specific collection parameter from withCallState.
• While withCallState supports named collections, it doesn't seem to support granular state per entity ID.

I need to track which specific entity in a list is being processed. For instance, if I trigger a delete for entity ID 325, I want to show a spinner only for that row. Currently, withCallState provides a global state for the deleteOne operation, which would trigger a loading state for all delete buttons simultaneously.

Here is an example:

const TodoStore = signalStore(
  withEntities<Todo>(),
  // 'deleteOne' is global to the store/collection, not keyed by entity ID
  withCallState({ collections: ['loadMany', 'deleteOne'] }), 
  withMethods((store) => ({
    loadMany: rxMethod<void>(/* get request + setLoading('loadMany') + setLoaded(...)  */),
    deleteOne: rxMethod<Todo>((todo) => {
      // ⚠️ Here I cannot specify which todo is currently being deleted.
    })
  }))
);

Calling setLoading('deleteOne') affects the entire store state and I couldn't find a proper way (yet?) to be more granular (appart from my custom solution where I added on option to provide a payload to the setLoading function).

In the store:

setLoading('deleteOne', todo.id);

In the view:

store.deleteOneLoading() && store.deleteOnePayload() === todo.id

[rainerhahnekamp]

Hey @Tiime-LcsGa, I don't think that withCallState works for those fine-granular updates. Have you ever though about extending the entity itself with such a callstate property?

So you would have something like this:

type TodoView = Todo & { status: 'deleting' | 'updating' | 'pristine'} // whatever status you find fit.

signalStore(
  withEntities<TodoView>(),
  // ...
)

[Tiime-LcsGa]

Hey @rainerhahnekamp

I hadn't thought of that, but it's a very clever and flexible way to handle this!
Thanks for the suggestion. I'll try out this pattern as soon as possible and let you know if I run into any issues 😄

In the meantime, I'll mark this as the answer!

[rainerhahnekamp]

Thanks @Tiime-LcsGa, let us know how it went. Would be curious to hear!

[Tiime-LcsGa]

Hi @rainerhahnekamp,

After a couple of weeks of use, I haven't faced any issues with the (very flexible) solution you gave me 😉

It was really clever, thanks!