Conceptual Question NGRX Signal store - Many small features vs. few big features?

[PhilippMDoerner]

Heyho, I've been experimenting with the ngrx signal store on a private project of mine.
For the most part I've been writing myself features somewhat reminiscent of redux/ngrx toolkit, basically abstracting away interactions with services and automatically tracking request state + storing request-data in the store.

The approach I went with originally was making many tiny features (withQuery for GET-request, withCreatefor POST requests, withDelete for DELETE requests etc.) that you can then use together in signalStores as desired.
However, I found that given enough features that you want in a single store you're very quickly running into the limit of features a single store can hold (based on the type of the signalStore function that limit appears to be 16, after that you get type errors).

So I'm wondering if maybe my approach was wrong and instead it makes more sense to have a larger withBackend feature that you pass all a config with all the various HTTP requests you might want to do and stores them in the store in one go.

Does this maybe go beyond just this usecase and was a general design-intention behind the signal-store?
Fewer, but larger features to avoid the signal-store becoming overly complex with too many features at once?

[rainerhahnekamp]

I can only give you my opinion but exceeding 16 indicates that your store is too large. If the same store is required in any component/service which is sending a request, that's the wrong approach.

Split your store into multiple pieces. You will have some state which applies to only a component/component tree. That would be a component provided state, which you can also provide in root, if you want your state stays alive.

For state which is used application-wide, go with root provided state.

If your application heavily depends on eventing, you might also consider to use Redux, which means the extension of the toolkit or the global store.

[PhilippMDoerner]

I might want to rethink my structuring approach that I applied so far when using ngrx more generally then. I currently tend to split my code along problem-domains I can identify.
Like a chat-domain, my-profile-domain, tracking-domain etc., and then I create (potentially lazy-loaded) 1 module per domain.
Each module has its own store-slice (with signal-stores I guess it would be with their own signal-store-instance) that only this module may access.
It's essentially what I've grown most familiar with while using the "normal" ngrx-store in larger applications.

In such a scenario e.g. Chat is prone to have a fair amount of HTTP requests (one for writing a message, one for sending typing indicators, another to update read-status, one for fetching a list of conversations, one for fetching a list of messages for one conversation etc. ). Thus if you add 1 signal-store feature instance to your store per HTTP request, then it's not that unlikely you're hitting the 16 feature limit.

I guess that means I'd want to either:

• A) Ditch the "1 module = 1 store", keep "1 HTTP request = 1 custom feature instance" rule.
  Any module may now use any (or simply multiple) signal-store, think of criteria on how to slice your stores and keep them small
• B) Keep the "1 module = 1 store" rule, keep "1 HTTP request = 1 custom feature instance" rule.
  Make sure you slice your modules small enough to not need more than 5-6 different HTTP requests within a module
• C) Keep the "1 module = store" rule, ditch "1 HTTP request = 1 custom feature instance" rule.
  Write yourself features that handle multiple instances of a thing, in this case go along the lines of a feature that can add the necessary fields, signals and methods for multiple HTTP requests at once.

[rainerhahnekamp]

Do you have an example for that? That sounds a little bit "special"