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"

[PhilippMDoerner]

I think I was mostly slicing my store too big or rather I think I should've aimed for a feature along the lines of withQueries (analogous to withMethods but adds fields and load-methods at the same time) rather than withQuery.

I was ending up with something like this .
Conceptually the problem there is just that I'm using a store that needs to abstract away a lot of endpoints and making one SignalStoreFeature-instance per endpoint.

export const CharacterPageStore = signalStore (
  { providedIn: 'root',
  withState(initialState),
  withComputed(... various computed things ...),
  withQuery('character', ... function making http request for single character ...),
  withQuery('nonPlayerCharacters' ... function making http request for non-player-characters ...),
  withQuery('locations', ... function making http request for all known locations of campaign ...),
  withQuery('sessions', ... function making http request for all sessions of campaign ...),
  withQuery('items', ... function making http request for all items of campaign ...),
)

The solution I think is to instead write something along the lines of withMethods, something that can register multiple queries in one go the same way withMethods adds multiple methods in one go.

export const CharacterPageStore = signalStore (
  { providedIn: 'root',
  withState(initialState),
  withComputed(... various computed things ...),
  withQueries(store => {
    return {
      character: ...function...,
      nonPlayerCharacters: ...function...,
      locations: .... function...,
      sessions: ... function ....,
      items: ... function....
    }
  }),
)

I'm still somewhat struggling here with the return type of such a feature though.

[rainerhahnekamp]

Have you ever thought of using a withQueries, where you provide a list of values and internally you are iterating over them and create methods (or whatever you have to do)?

[PhilippMDoerner]

I think that matches the approach I described at the end, essentially making sth. analogous to withMethods where the user makes a factory to create an object ala:

store => ({
  character: (params: Params1) => characterService.loadCharacter(params),
  nonPlayerCharacters: (params: Params2) => characterService.loadNonPlayerCharacters(params),
  ....
})

and from that the feature then creates the fields character, characterError, characterQueryState and the method loadCharacter etc.

I'm currently staring at the signature of withMethods to figure out how my own type-signature for such a feature would look like