Feature Request: Enhance withCallState to Support Multiple Collections

[abhijit-chikane]

Feature Request: Enhance withCallState from @angular-architects/ngrx-toolkit to Support Multiple Collections and make a part of core @ngrx/signals package

Issue
Currently, withCallState only accepts a collection with a single string value. However, in large projects, we often need to track the loading state of multiple collections simultaneously.

While it's possible to use multiple withCallState functions, this approach has a significant drawback: the Store currently accepts only 15 inputs. Using withCallState multiple times can quickly reach this limit, making state management inefficient.

Proposed Solution
Extend withCallState to accept an array of strings, allowing developers to manage the state of multiple collections more effectively.

I've already implemented a similar feature in a custom store and shared my approach in this Medium article.

I believe integrating this functionality into the core @ngrx/signals package (instead of relying on @angular-architects/ngrx-toolkit) would be highly beneficial for developers working with complex state management scenarios.

Appreciation
Thanks for all the great work you do @ngrx-toolkit! Looking forward to your thoughts on this.

Related issue already posted on @ngrx/platform

[rainerhahnekamp]

we often need to track the loading state of multiple collections simultaneously

The upcoming resource will define the standard for a status field in Angular. I think we should focus on integrating the resource into the SignalStore. Then these issues you've mentioned would be gone.

Would do you say?

[abhijit-chikane]

we often need to track the loading state of multiple collections simultaneously

The upcoming resource will define the standard for a status field in Angular. I think we should focus on integrating the resource into the SignalStore. Then these issues you've mentioned would be gone.

Would do you say?

I agree that the Resource API will address some of these issues. However, I’m unsure about its adoption in existing projects.

For new development, it makes sense to use the Resource API, but migrating large-scale projects to these new APIs will take time. In the meantime, since this feature is already available in the @angular-architects/ngrx-toolkit, I’m happy to enhance it further to improve its usability.

[rainerhahnekamp]

OK, but then please do the following before making a PR:

• Let's discuss the design here
• It should be backwards-compatible (no breaking changes)
• It needs to be supported by unit tests
• Documentation also has to be added.

[abhijit-chikane]

Sure. I think the medium post I shared already has pretty much everything explain.
It should be backwards-compatible (no breaking changes) => I think this is possible but needs some extra efforts.
I can help with the documentation.
@rainerhahnekamp
Thanks for quick replies!😀

[abhijit-chikane]

one question:

Do we really need the config -> collection hierarchy in the arguments? Wouldn't it be simpler to just allow string | string[] instead?

[abhijit-chikane]

OK, but then please do the following before making a PR:

• Let's discuss the design here
• It should be backwards-compatible (no breaking changes)
• It needs to be supported by unit tests
• Documentation also has to be added.

Here's a working example link to the idx-project:
https://idx.google.com/signal-store-demo-5061337

Let me know your Gmail address, and I’ll add you as a collaborator.

[rainerhahnekamp]

We should discuss the design here. you can provide code examples where you show how the changes to the API should look like from the user's perspective.

[abhijit-chikane]

@rainerhahnekamp I have updated the PR
#148
could you please take a look?
then we can update the documentation

I have tested this
everything seems to be working fine and it's backward compatible except that we have to now pass 'collections' as arg instead of 'collection'

edited
I just noticed that we can make it 100% backword compatilbe. Will make the required changes shortly but could you please review the changes?

Thanks

[abhijit-chikane]

@rainerhahnekamp I have made changes in this pr and fully backward compatible
Let me know if any change is required
Thanks!

[rainerhahnekamp]

@abhijit-chikane, great. Can you also add a test so that I can see what changes your feature brought, i.e. what can I now do, what I couldn't do before.

[abhijit-chikane]

@rainerhahnekamp I have added a test in same PR

[abhijit-chikane]

#148

[barchewbacca]

Hey folks @rainerhahnekamp @abhijit-chikane, I wanted to use it because saw it in the docs but it doesn't seem to be in the latest release yet or am I missing something?