RFC: withKeyed signal store feature

[Devin-Harris]

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

signals

Information

I have found I often have reusable signal store features that I want to use multiple times in the same signal store or in other features with property name constraints. Having the ability to pull in all the state, methods, properties, etc.. for a given feature under some unique key defined where you use the feature would be useful.

Something like the following is what I am thinking as far as api

const withCommonFeature = () =>
   signalStoreFeature(
      withState(() => ({ commonField: 'Hello world!' })),
      withMethods((store) => ({
         setField: (value: string) => {
            patchState(store, setField(value));
         },
      }))
   );

const Store = signalStore(
   withKeyed('A', withCommonFeature()),
   withKeyed('B', withCommonFeature()),
   withMethods((store) => ({
      log() {
         console.log(store['A'].commonField());
         console.log(store['B'].commonField());
      },
   }))
);

withKeyed would be the function defined in the standard library in this example.

I have a somewhat working fork, if this feature is considered.
Note it is still a little rough around utilising writable state so any ideas on that could be discussed here. The main con in my current pass is I have a watchState because I am not running the keyed feature on the root store , so two stateSources need to be kept in sync when patches happen inside the inner and outer stores.

Describe any alternatives/workarounds you're currently using

The project I am working in is still on v18, so my workaround is for that version of signal store (i can port this to v19 for those interested if need be). Its a rough version using native withComputed as shown here:

type ComputedSignalsKeyType<O extends SignalStoreFeatureResult> = keyof O['computed'];
type ComputedSignalsValueType<O extends SignalStoreFeatureResult> = {
   [x in ComputedSignalsKeyType<O>]: O['computed'][x] extends Signal<infer V> ? V : O['computed'][x];
};

type WithKeyedOutputComputedResult<O extends SignalStoreFeatureResult> = O['computed'] &
   Signal<O['state'] & ComputedSignalsValueType<O>> &
   O['methods'];
type WithKeyedOutputStateResult<O extends SignalStoreFeatureResult> = O['state'] & ComputedSignalsValueType<O>;
type WithKeyedOutputResult<T extends string | symbol, O extends SignalStoreFeatureResult> = EmptyFeatureResult & {
   state: { [x in T]: WithKeyedOutputStateResult<O> };
   computed: {
      [x in T]: WithKeyedOutputComputedResult<O>;
   };
   methods: {};
};

export function withKeyed<
   T extends string | symbol,
   I extends SignalStoreFeatureResult,
   O extends SignalStoreFeatureResult,
>(key: T, innerFeature: SignalStoreFeature<I, O>): SignalStoreFeature<I, WithKeyedOutputResult<T, O>> {
   return (store) => {
      const storeForFactory = inject(
         signalStore(
            { providedIn: 'root' },
            withState(() => ({}))
         )
      ) as Parameters<SignalStoreFeature<I, O>>[0];

      const storeForFactoryWithHooks = {
         ...storeForFactory,
         hooks: (store as any).hooks ?? {},
      };

      const _innerStore = innerFeature(storeForFactoryWithHooks);

      const computedValues = computed(() => {
         const computedSignals = _innerStore.computedSignals;
         const computedKeys: ComputedSignalsKeyType<O>[] = Object.keys(computedSignals);
         return computedKeys.reduce((acc, k) => {
            acc[k] = isSignal(computedSignals[k]) ? computedSignals[k]() : (computedSignals[k] as any);
            return acc;
         }, {} as ComputedSignalsValueType<O>);
      });
      const state = computed(() => {
         return { ...getState(_innerStore), ...computedValues() };
      });
      Object.assign(state, _innerStore.methods);
      Object.assign(state, _innerStore.computedSignals);
      Object.assign(state, _innerStore.stateSignals);

      const storeWithKey = withComputed(
         () =>
            ({
               [key]: state,
            }) as {
               [x in T]: WithKeyedOutputComputedResult<O>;
            }
      )(store);
      const storeWithHooks = withHooks(() => _innerStore.hooks)(storeWithKey) as any;

      return storeWithHooks;
   };
}

Without some of the internal symbols, types, and helper methods, its a little verbose and limited on how writes inside the keyed feature are handled. Especially when their are keyed features inside other keyed features, thus the feature request.

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

• Yes
• No

[TomaszStanik]

It's good proposition - it would be helpull in some cases in our projects. Currently our workaround is creating new signalStores...

I would like to add similar RFC for something like withObjects - it could be connected with withKeyed maybe?

export class MyClass {
     sayHello(): void {
        console.log('Hello');
   }
}

const Store = signalStore(
  withObjects(store => {
        return {
               foo: new MyClass();
         }
   }),
   withMethods((store) => ({
      log() { 
              store.foo.sayHello();
      },
   }))
);

[eliellis]

Awesome proposal. This would be great to have!

It's good proposition - it would be helpull in some cases in our projects. Currently our workaround is creating new signalStores...

I would like to add similar RFC for something like withObjects - it could be connected with withKeyed maybe?

export class MyClass {
sayHello(): void {
console.log('Hello');
}
}

const Store = signalStore(
withObjects(store => {
return {
foo: new MyClass();
}
}),
withMethods((store) => ({
log() {
store.foo.sayHello();
},
}))
);

In this case, wouldn't the (existing) withProps(...) capability achieve the desired results?

[rainerhahnekamp]

Guys, I’m not sure I fully understand what you’re trying to do here. The way I read it, you want to pack multiple SignalStores into a single class—is that correct?

Personally, I don’t think it’s good practice to create large services that bundle too much functionality. What we definitely want to avoid is having one SignalStore that manages the entire app state.

Wouldn’t a simple composition class be enough for your case? Something like this:

class ComposedSignalStore {
  user = inject(UserStore);
  products = inject(ProductsStore);
  books = inject(BookStore);
 
  // ...
}

But again, maybe I’m misunderstanding the actual use case. If so, could you please elaborate?

Thanks! 🙌

[eliellis]

My use-case for something like this is primarily about namespacing particular features and all of the associated additions from said feature beneath a particular key, including methods, computeds, props, etc. Currently, a store feature can tack on nested state in a fairly straighforward way. Where that state appears in the resulting compostion can be made configurable by taking an appropriate "key" value into the feature factory. However, as far is I am aware, it isn't nearly as straightforward for methods, computeds, etc. especially when the desired shape of the composed store is to have all of your feature additions grouped beneath a single key.

Take the following trivial "search" feature as an example:

function withSearch() {
  return signalStoreFeature(
    withState( { limit: 10, offset: 0, query: '' }),
    withComputed((store) => ({
      hasQuery: computed(() => store.query().length > 0)
    })),
    withMethods((store) => ({
      updateQuery: (query: string) => {
        patchState(store, { query });
      },
      resetQuery: () => {
        patchState(store, { query: '' });
      },
      updateLimit: (limit: number) => {
        patchState(store, { limit });
      },
      updateOffset: (offset: number) => {
        patchState(store, { offset });
      }
    }))
  );
}

const MyStoreWithSomeSearchState = signalStore(
  // ... other store defs
  withSearch()
)

Ideally, I'd like to be able to group all of these composed values beneath a particular key within the resulting store so anything "search" related will live at myStore.search.*.

However, taking the trivial path to achieve something like this immediately leads to type errors in withComputed and withMethods (which is to be expected):

In a perfect world, the withSearch() feature would register itself and all associated properties beneath some shared key, like search for example. With this proposal, the desired outcome can be easily achieved:

const MyStoreWithSomeSearchState = signalStore(
  // ... other store defs
  withKeyed('search', withSearch())
)

// ... somewhere else, within a component

const myStore = inject(MyStoreWithSomeSearchState);

onQueryChange(query: string) {
  myStore.search.updateQuery(query);
}

Hopefully the above illustrates my use-case well enough, even if it is trivial. I'd certainly like to believe that something like this isn't abusing the ideals behind how the signal store and signal store features are intended to work–on first blush, it seems quite complimentary to the compositional nature of things. However, I would definitely be open to suggestions on how achieve something like this more idiomatically if this type of approach is frowned upon.

[Devin-Harris]

My use-case for something like this is primarily about namespacing particular features and all of the associated additions from said feature beneath a particular key, including methods, computeds, props, etc. Currently, a store feature can tack on nested state in a fairly straighforward way. Where that state appears in the resulting compostion can be made configurable by taking an appropriate "key" value into the feature factory. However, as far is I am aware, it isn't nearly as straightforward for methods, computeds, etc. especially when the desired shape of the composed store is to have all of your feature additions grouped beneath a single key.

Take the following trivial "search" feature as an example:

function withSearch() {
  return signalStoreFeature(
    withState( { limit: 10, offset: 0, query: '' }),
    withComputed((store) => ({
      hasQuery: computed(() => store.query().length > 0)
    })),
    withMethods((store) => ({
      updateQuery: (query: string) => {
        patchState(store, { query });
      },
      resetQuery: () => {
        patchState(store, { query: '' });
      },
      updateLimit: (limit: number) => {
        patchState(store, { limit });
      },
      updateOffset: (offset: number) => {
        patchState(store, { offset });
      }
    }))
  );
}

const MyStoreWithSomeSearchState = signalStore(
  // ... other store defs
  withSearch()
)

Ideally, I'd like to be able to group all of these composed values beneath a particular key within the resulting store so anything "search" related will live at myStore.search.*.

However, taking the trivial path to achieve something like this immediately leads to type errors in withComputed and withMethods (which is to be expected):

In a perfect world, the withSearch() feature would register itself and all associated properties beneath some shared key, like search for example.

Hopefully the above illustrates my use-case well enough, even if it is trivial. I'd certainly like to believe that something like this isn't abusing the compositional ideals behind how the signal store and signal store features are intended to work, but would definitely be open to suggestions on how achieve something like this more idiomatically if this type of approach is frowned upon.

Couldn't have said this better myself. This, for me anyway, is less about using stores in stores and more about resolving name collisions when using multiple features in a single store

[eliellis]

Couldn't have said this better myself. This, for me anyway, is less about using stores in stores and more about resolving name collisions when using multiple features in a single store

Yes, definitely. This isn't about bloating a store beyond its breaking point, but rather, being able to organize feature additions and eliminate naming collisions for all additions, not just state, but also methods, computeds, and other props in a "clean" way.

[rainerhahnekamp]

I think I get what you’re going for, but I don’t have a great feeling about the proposed solution—let me explain why.

Let’s say I’m building a regular service (without SignalStore) that includes a search feature alongside others. If I were writing all the logic myself, I don’t think I’d naturally nest everything under a search property. That kind of structure wouldn’t feel intuitive.

Now back to SignalStore. When thinking about building a reusable feature—like a generic search extension—I see a potential issue with name collisions. The feature doesn’t know which SignalStore it will be used in, what other properties or methods already exist, or whether other features might introduce conflicting names.

In that case, as the extension author, I’d want to offer customization options so that consumers can choose their own member names. Is that closer to what you had in mind?

[Devin-Harris]

To your intuitive point, I agree. However, I think if you have the same feature used in multiple places with different internal member names could also not feel great too. For instance, say I have some reusable feature (maybe the withRequestStatus from the docs: https://ngrx.io/guide/signals/signal-store/custom-store-features). I have used it in a few stores in my app, but for one reason or another there is a name conflict in this new store I am working in (maybe I have multiple "error" members as an example). If the withRequestStatus feature had inputs to override the conflicting members, I could attempt to override just the part(s) with conflicts. But now accessing members provided by that feature is partially different in this store than all the others. Of course their is an "accessing" change with something like withKeyed too, but just noting since I dont think customization options fully solves the intuitiveness when your dealing with name conflicts.

I think offering customization options is a good practice for generic features in general. However, their are edge cases with this.

One being the consumer is not always in control of what customization options are provided. If the generic feature does not provide these customization options the consumer may have to wait on some external library to update, as one example. Something like withKeyed gives some more flexibility out at the consumer level.

Also a withKeyed approach is more resilient to change. If you have some generic feature that you are using in some store, and that generic feature is updated (maybe a member is renamed or added), how would the consumer know to go back and customize the new member to a different name if the rename/addition caused a conflict? The withKeyed would fully encapsulate that features members from the rest of the store so changes at either end would be less likely to allow conflicts than a partial config of key mappings for every member of generic features (at least in theory 😄).

[rainerhahnekamp]

@Devin-Harris, adding this feature could be a significant change to the SignalStore. What do you think about the approach used in withEntities, where entities are explicitly named? Could something like that help here?

We might also consider providing utility functions to make it easier for feature authors to define named features in a consistent way.

[Devin-Harris]

@rainerhahnekamp I do like the explicit naming in the withEntities approach as well. I could see a similar approach helping with the name conflict problem in the following ways:

1. feature accepts a string prefix input that you concatenate on ALL internal feature members
   OR
2. feature accepts a config object of many string inputs that you use in place of any/all internal feature members (potentially a partial object so the internal feature can fallback to its original member name if an override is not provided)

It seems withEntities is closer to the first point I have here, but both of them seem sound for the name conflict problem. Heres some high level pros and cons I find with it.

Cons:

1. how much boilerplate does the author and consumer of the feature have to write to allow name overriding

• In withEntities it seems like quite a lot of extra code the author of the feature has to write just for allowing users to resolve name conflicts. Things like extra helper types, functions, etc...
• This could be exasperated with a feature that has many internal members and requires lots of conditional key overriding.

2. In turn, how much flexibility does the consumer have to override names if the feature author does not "opt in" to name overriding

Pros:

1. State and other store members are all "inline" with each

• This approach would solve the problem I identified in my original attempt (https://github.com/Devin-Harris/platform/blob/codespace-special-space-carnival-q45769wggpvcx7q5/modules/signals/src/with-keyed.ts) where the state has too be synced with a watchstate since their is no internal store being created.

2. Consistency between other name conflict resolving features like withEntities

I would have to put some thought into how something like the withEntities approach could be done generically so that any feature could have any/all of its members overridden at the consumer level, while maintaining type safety and what not. (Probably what you were getting at with your "utility functions" suggestion)

The ideal goal in my head would be:

1. to allow the consumer to simply wrap a feature in some helper function/feature, and then to be able to override any/all members to their liking
   AND/OR
2. for a feature author to easily expose input(s) for overriding any/all members of the feature (including methods which is not done in something like the withEntities example).

Personally I feel like the rough withKeyed attempt is pretty close to the first part of that goal while being pretty straightforward for both the feature consumer and author to use/expose potentially name conflicted features.

I do see the drawbacks, especially in that first attempt, so I ultimately defer to you on how best to move forward. Like I said I'd have to put more thought into utility functions more in line with a withEntities style approach, but no matter what decision is made I think name conflicts are generally a pain point with the signal store features, at least for me, so any and all ideas are welcome.

P.S. Love your youtube videos 😁

[Devin-Harris]

Finally got some time to look into those utility functions and came up with something that also looks promising...

Basic idea is to add two new helper features: withExposeKeys and withSetKeys

• https://github.com/Devin-Harris/platform/blob/codespace-special-space-carnival-q45769wggpvcx7q5/modules/signals/src/with-expose-keys.ts
• https://github.com/Devin-Harris/platform/blob/codespace-special-space-carnival-q45769wggpvcx7q5/modules/signals/src/with-set-keys.ts

withExposeKeys expects a factory function that returns a feature where the parameters to said function are different keys that can be overriden by the consumer. The author then defines the defaults of those keys as additional parameters after the factory function.

Then the consumer can either choose to use the exposed feature without the second withSetKeys if they choose. If so it will use those defaults the author set, but if not they can override each exposed key individually.

Heres how the api is looking

const withCommonFeature = withExposeKeys(
   (commonFieldKey, setFieldKey) =>
      signalStoreFeature(
         withState(() => ({ [commonFieldKey]: 1000 })),
         withComputed((store) => ({
            commonFieldComp: computed(() => `${store[commonFieldKey]()}: comp`),
         })),
         withMethods((store) => {
            const setFieldMethod = (value: number) => {
               patchState(store, { [commonFieldKey]: value });
            };

            return {
               [setFieldKey]: setFieldMethod,
            };
         })
      ),
   'commonField',
   'setField'
);

export const Store = signalStore(
   { providedIn: 'root' },
   withState(() => ({
      rootState: 'Hello',
   })),
   withCommonFeature(),
   withSetKeys(withCommonFeature, '1', 'set1'),
   withSetKeys(withCommonFeature, '2', 'set2'),
   withHooks((store) => {
      return {
         onInit() {
            store.set1(123);
            store.set2(456);
            store.setField(8910);

            //Below logs: {
            //   "1": 123,
            //   "2": 456,
            //   "rootState": "Hello",
            //   "commonField": 8910
            // }
            console.log(getState(store));
         },
      };
   })
);

Still limitations on how the author must "opt in" to expose keys with this for the consumer to be able to override. Also if you need to override say just the 5th key exposed, you need to override all first 4 as well to some value (at least with the typescript magic i was trying for this particular pass). Still not sure if this is the ultimate approach to name conflicts but it does have a lot of benefits.

[rainerhahnekamp]

@Devin-Harris, I can see you’re putting a lot of effort into this. Just to set expectations right:

We can definitely work on it together, but there’s no guarantee it will land in @ngrx/signals anytime soon. As an alternative, we could add it to ngrx-toolkit (community library) as an incubation feature, or you could publish it as a standalone library for now.

[Devin-Harris]

No worries!

I completely understand if theirs a long turn around time on getting something like this released. I figured I would share my ideas in case that helped speed up the process but had no expectations on what I've done here even being the absolute best way to approach this problem anyway.

I looked into ngrx-toolkit before I realized I would need the STATE_SOURCE / getInitialInnerStore piece for the original attempt but I can go back there and make an issue with some points from the conversation here. Then I can leave a more standardized member conflict solution up to some of the more main contributors in this project for now.

Thankyou everyone for all the input and suggestions!

[rainerhahnekamp]

I can go back there and make an issue with some points from the conversation here

Sure, as I said, it has a better chance of landing sooner there. And if it is stable and proves itself, we can think of moving it back "home".