Reacting to multiple service results from API calls within SignalStore

[slmcrs]

Say I have a view of items, where the list of items is a piece of state within a SignalStore. When the store loads, it will make a call to load data. The list component will reference computed values based on the request status, so if pending, show a spinner, if error show a message, and if fulfilled, show the data.

Now, on this same view that has a list of the items, we will also be able to open a dialog popup. This dialog popup will have its own loading state, and only close if we have a success on the api call. This is what is causing some confusion and I am not sure the best way to handle this scenario.

The problem becomes, since we are on the same page/view, we need to be able to track the state of each type of call separately, otherwise we risk trigger the wrong UI states by sharing a single request status field.

This is not a problem itself, but when I need to set up the methods for all different types, it becomes slightly cumbersome having to create the same logic with different prefix for all of the state values.

I am also not sure if this is a valid use case for watchState. I am thinking potentially withProps + an observable would be the answer once we are upgraded to 19 but currently we are locked into 18.

Maybe I am going about this the wrong way, so I wanted to know if there was an expected pattern in this scenario that I am maybe missing.

I also created a stackblitz showcasing my current setup:
https://stackblitz.com/edit/stackblitz-starters-yd9srwa1?file=src%2Fapp%2Fstate%2Frequest-status.feature.ts

[rainerhahnekamp]

The most pragmatic solution would be to add a callback in addComment.

export class CommentDialogComponent {
  readonly commentStore = inject(CommentStore);
  readonly dialogRef = inject(MatDialogRef<CommentDialogComponent>);
  readonly message = signal('');
  readonly throwFakeError = model(false);

  constructor() {
    this.commentStore.resetAdd();
  }

  onClose(): void {
    this.dialogRef.close();
  }

  onConfirm(): void {
    let comment: Comment = {
      content: this.message(),
      createdAt: new Date().toISOString(),
    };
    this.commentStore.addComment({ 
      comment, 
      triggerError: this.throwFakeError(), 
      cb: () => this.dialogRef.close() // <-- callback to be added
    });
  }

[slmcrs]

Thanks for taking the time to reply!

I had thought of potentially using a callback to trigger some outside update but I thought that might be considered a bad practice.
I guess my thought was that this would be adding some unpredictability to the store methods and what it does, but perhaps I am just thinking too much into it at that point and making it more complicated than it needs to be.

After making this post, I also have found out about the lovely package @ngrx-traits/signals and was experimenting with converting the status signals returned from the withCalls() to observables that the component can listen to. The downside here being, if there is ever more than one call happening at once, you can't really track it easily.

I think for the time being the callback is straightforward enough I will lean towards implementing that. I am interested to see if this scenario goes away as more services adopt signals and are designed with signals in mind.