Is SignalStore overkill for just surfacing loading and error state

I have application use cases that sit very comfortably in SignalStore e.g. Load and Display an Employee and then allow edits to that employeee. In this model my store exposes my employee and provides methods that allow various updates and actions to be performed agaisnt them - each one calling an API to make the change and then refreshing the state accordingly.

This makes for a nice clean architecture. My view has data, error and loading signals it can bind to. Concerns are separated and the code is predictable.

However I also have other use cases where state is not updated e.g. load a list of employees who left in the last 90 days. If I use a dedicated signalStore for these I can bind my template in the same way as the previous example, but it feels that my store is just there for my convenience. I'm kinda OK with using a store here but only just...

Then I have other actions that have no state e.g. a menu option that might cause an API to be called to generate and email a report without bring any data back to the UI. Again I would like the loading and error states available for my UI.

Maybe it is just an inevitable architecture tradeoff but I feel I have a few choices to cope with this last category of use cases:

1. Create a 'command' signalStore which just passes through the commands to the API and importantly exposes a common interface to communicate error and loading states
2. Create a lightweight command service that exposes its own error and loading signals, so providing the same interface to the UI but without the 'overhead' of a signalStore
3. Create a command service that does not expose error and loading signals but just passes the call through to the API. The UI then maintains its own loading and error state handling

I am leaning towards the command signalStore so that my component coding is predictable but I feel like I am abusing signalStore in doing so.

This must be a common dilemma developers face. Is there a 'right' way?

Continue reading...