Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Enhance withCallState to Support Multiple Collections #147

Open
abhijit-chikane opened this issue Feb 16, 2025 · 8 comments

Comments

@abhijit-chikane
Copy link

abhijit-chikane commented Feb 16, 2025

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

abhijit-chikane commented Feb 16, 2025

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
Copy link
Author

one question:

Image

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

@abhijit-chikane
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

abhijit-chikane commented Feb 26, 2025

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants