(feat): Extend SignalsDictionary and MethodsDictionary

[tmasnyk]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

I've created my own SignalStoreFeature called withEntitiesManagement, which adds an entities collection, CRUD operations, and other functionality to manage it. I want to use several such features in my store:

export const ApplicationsModuleStore = signalStore(
...
 withEntitiesManagement('applications', ApplicationsService),
 withEntitiesManagement('applicationsGroups', ApplicationsGroupsService),
 withEntitiesManagement('applicationsLinks', ApplicationsLinksService),
...
)

However, this produces a large and flat list of named methods and 'selectors', which causes noticeable freezing during IDE type fetches as well. So, I decided to slice the store to be used like this:

    store = inject(ApplicationsModuleStore );

    const applicationEntities = this.store.applications.selectedItems();
    const applicationGroupsEntities = this.store.applicationsGroups.selectedItems();
    const applicationsLinksEntities = this.store.applicationsLinks.entities()
    ...
    this.store.applications.pager();
    this.store.applications.updateFilter(filter);
    this.store.applications.delete(applicationEntities[0]);
    this.store.applications.findAll();

    this.store.applicationsGroups.entities();
    this.store.applicationsGroups.updateFilter(filter);
    this.store.applicationsGroups.delete(applicationGroupsEntities[0]);
    this.store.applicationsGroups.findAll();
    ...

But there is a problem with the type limitations in the signal store:

export type SignalsDictionary = Record<string, Signal<unknown>>;
export type MethodsDictionary = Record<string, Function>;

These types don't work when I try to use them with slices, as they don't satisfy SignalStoreFeatureResult and InnerSignalStore:

export type EntitiesManagementComputed<E extends Entity, Collection extends string> = {
  [K in Collection]: {
    selectedItems: Signal<E[]>;
    pager: Signal<Pager>;
    entities: Signal<E[]>;
  }
};

export type EntitiesManagementMethods<E extends Entity, F extends Filter, Collection extends string> = {
  [K in Collection]: {
    updateFilter: (filter: F) => void;
    updateSelectedItems: (id: EntityId, selected: boolean) => void;
    findAll: (parentResourceId?: null | number) => Promise<void>;
    setCurrentItem: (entity: E | null) => void;
    findOneById: (id: EntityId) => Promise<void>;
    save: (entity: E) => Promise<void>;
    create: (data: Partial<E>, translatableProps: TranslatablePropertiesType<E>[]) => void;
    delete: (entity: E, parentResourceId?: number) => Promise<void>;
  };
};

export type EntitiesManagementFeatureResult<E extends Entity, F extends Filter, Collection extends string> = {
  state: {};
  computed: EntitiesManagementComputed<E, Collection>;
  methods: EntitiesManagementMethods<E, F, Collection>;
};

To use the store with slices, the types need to be something like this:

export type SignalsDictionary = Record<string,  Signal<unknown> | Record<string,  Signal<unknown>>>;
export type MethodsDictionary = Record<string, Function |  Record<string, Function>>;

Could the NgRx team extend these types?

Describe any alternatives/workarounds you're currently using

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[rainerhahnekamp]

Can I suggest an alternative?

Why don't you create multiple Stores, each responsible for one particular entity? This is also recommended for withEntities().

If you have the need to provide a single service for all three entities, you could have your three SignalStore and wrap a Service around them, which exposes each signalStore as property.

class ApplicationStore {
  readonly applications = inject(ApplicationStore);
  readonly links = inject(ApplicationLinksStore);
  readonly groups = inject(ApplicationGroupsStore);
}

I'm going to convert this issue to a discussion.

[tmasnyk]

First of all, thank you, @rainerhahnekamp, for the reply and the work you do! Your videos and sources have been very helpful to me.

Yes, it's a solution, but I really like the way Signal Store is chosen. The way the store object combines features is appealing. In my opinion, Signal Store is already a facade, and creating facades over facades isn’t something I like, at least in this case.

In my case, I've started to use Signal Store as a "module store," aiming for each module to have no external dependencies on other modules, thereby ensuring low coupling. For example, if I need 'Users' and 'Products' data in my module, the final store would be:

export const ApplicationsModuleStore = signalStore(
 withState({}),
 withEntitiesManagement('applications', ApplicationsService),
 withEntitiesManagement('applicationsGroups', ApplicationsGroupsService),
 withEntitiesManagement('applicationsLinks', ApplicationsLinksService),
 withEntitiesManagement('user', UsersService), 
 withEntitiesManagement('products', ProductsService), 
)

Or use less expensive features, such as withCollectionLoad, which loads only collections without CRUD operations and will be used by the module. The "ModuleStore" will have all the needed data and be closed off from the outside. The store structure is well-organized. One disadvantage is that some modules might duplicate some data, but in my case, this isn’t a problem.

So, to organize access to a larger 'module store' in a more manageable way, I started thinking about using slices.

In your example, there might be a temptation to move every small store to its own feature module (e.g., /users, /products/, /applications) and reintroduce dependencies between modules, which I am trying to avoid. Maybe it's unusual to use a store without decomposing it into its own modules—I’m not sure yet. What do you think? Can this approach work?

[rainerhahnekamp]

Your videos and sources have been very helpful to me.

Thanks a lot! 👍

a temptation to move every small store to its own feature module (e.g., /users, /products/, /applications) and reintroduce dependencies between modules

Yes, this is exactly what I am aiming for. I want to avoid having a huge store which all my modules have access. I'd like to restrict access and only provide it for certain modules. I accept that this comes with more boilerplate but I also gain more isolation/modularity.

So from my perspective, I would highly recommend to go with many, smaller stores. We will see what the others have to say on that topic.

[tmasnyk]

Here is my existing project architecture example:
app
└─ modules
├─ applications
├─ users
└─ products

It uses NGXS global states, and all modules have cross-links to use feature stores between them, resulting in high coupling. What I aim to achieve is full module isolation, breaking cross-links, and my project's purpose allows for this.

I want to have one module store (and some component stores if needed). All my module components will inject only one store; they won’t need to know about other stores (Users, Products) in other modules.

export const ApplicationsModuleStore = signalStore(
  withEnvDevtools('APPLICATIONS_MODULE_STORE'),
  withEntitiesManagement('applications', ApplicationsService),
  withEntitiesManagement('applicationsGroups', ApplicationsGroupsService),
  withUsersLoad(),
  withProductsLoad(),
  withQueryParamsBind([
    { collection: 'applications', route: '/applications' },
    { collection: 'applicationsGroups', route: '/applications/groups' }
  ]),
);

This store will have all the necessary data to serve the module, as well as a clear and attractive presentation thanks to the customFeature.I don't see the point, at least for my particular project, in creating separate small stores for each collection, especially if they should belong to other feature modules. Creating separate stores loses the power and beauty of "combinatorics". I understand that the authors didn't intend for this use, but I like using it this way, and it suits my project.

So, I would like to have the ability to create nested computed properties and methods to structure the store more manageably. But since there haven't been any such requests from the community yet, perhaps you could suggest whether it's possible to patch the necessary types without needing to fork the project. So far, I haven't been able to find a suitable solution

[markostanimirovic]

This feature may be something you're looking for: #4504

[tmasnyk]

Great, looks like what I need, thank you.