withSelectors - Migration of ngrx/store selectors logic to @ngrx/signals

[Svane20]

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

signals

Information

Currently, using ngrx/store and selectors, a function can be defined to get internal state slice within the store based on external parameters.

function getPreferencesById(userId, key, users) {
   const user = users[userId];
   if (user && user.preferences) {
      return user.preferences[key];
   }

   return undefined;
}

export function getUserPreferences(userId, key) {
    return createSelector(getAllUsers, users => getPreferencesById(userId, key, users))
}

With ngrx/signals, an official way is currently not defined.

My current workaround is to add a method in withMethods to get the desired behavior

export interface User {
  id: number;
  name: string;
  preferences?: Record<string, any>;
}

export interface State {
  users: Record<number, User>;
}

const initialState: State = {
  users: {},
};

export const myStore = signalStore(
  withState(initialState),
  // Selectors based on internal state which do not accept parameters
  withComputed({}),
  withMethods(store => ({
    // Selectors based on external parameters
    getUserPreferences: (userId: number, key: string) => {
      return computed(() => {
        const user = store.users()[userId];
        if (user && user.preferences) {
          return user.preferences[key];
        }

        return undefined;
      });
    },
  })),
);

In my opinion, this is bad practice. The withMethods sole purpose should be to update the stores internal slices.

To create a clear separation, like the selectors in ngrx/store, a new section should be added to the Signal Store called withSelectors (or a better name), that is only used to get internal state based on external parameters

export const myStore = signalStore(
  withState(initialState),
  withSelectors(store => ({
    getUserPreferences: (userId: number, key: string) => {
      const user = store.users()[userId];
      if (user && user.preferences) {
        return user.preferences[key];
      }

      return undefined;
    },
  })),
);

Describe any alternatives/workarounds you're currently using

No response

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

• Yes
• No

[Devin-Harris]

The "bad practice" feeling I get from your withMethods approach is not because it is not updating internal store slices (personally i think its ok to have methods that do this but thats beside the point). My main issue is because you are returning the computed value of a reactive signal not the computed signal itself.

For example, if you do const cookiePref = myStore.GetUserPreferences(1, "LikesCookies"), that will give you whether user 1 likes cookies at that particular point in time. If the users signal in the store is updated and user 1 changes his preference to cookies, cookiePref cannot "react" to that change anymore.

I would think you would instead want your method to use the internal state, to build a computed signal based on the users internal signal. Something like:

export const myStore = signalStore(
   withState(initialState),
   withMethods((store) => ({
      getUserPreferences: (userId: number, key: string) => {
         return computed(() => {
            const user = store.users()[userId];
            if (user && user.preferences) {
               return user.preferences[key];
            }
   
            return undefined;
         })
      },
   }))
);

Then when accessing the value of the computed state, you use the preferences signal like so:
const cookiePref$ = myStore.getUserPreferences(1, "LikesCookies"); // Signal<any>
const cookiePref = cookiePref$(); // any

To me that does not feel strange, but keeps reactivity. If this does not fit your philosophy, would with props be more appropriate?

export const myStore = signalStore(
   withState(initialState),
   withProps((store) => ({
      userPreferencesAccessor: (userId: number, key: string) => {
         return computed(() => {
            const user = store.users()[userId];
            if (user && user.preferences) {
               return user.preferences[key];
            }
   
            return undefined;
         })
      },
   }))
);

const cookiePref$ = myStore.userPreferencesAccessor(1, "LikesCookies"); // Signal<any>

But, i think i am in agreement that a wrapper function could reduce some boilerplate, not sure at what cost though (one that comes to mine is it clear that returns of selectors are wrapped inside computed signals or not). Rough idea could be something like:

type WithSelectorsFactoryResult<FactoryOutput> = Record<string, (...args) => FactoryOutput>;
type SelectorSignalsFunction<FactoryOutput> = {
   [x in keyof FactoryOutput]: FactoryOutput[x] extends (...args: any) => any
      ? (...args: Parameters<FactoryOutput[x]>) => Signal<ReturnType<FactoryOutput[x]>>
      : never;
};
type WithSelectorsOutputResult<O extends SignalStoreFeatureResult, FactoryOutput> = O & {
   methods: SelectorSignalsFunction<FactoryOutput>;
};

function withSelectors<
   I extends SignalStoreFeatureResult,
   O extends SignalStoreFeatureResult,
   FactoryOutput extends {},
>(
   factory: (store: StateSignals<I['state']> & I['props'] & I['methods']) => FactoryOutput
): SignalStoreFeature<I, WithSelectorsOutputResult<O, FactoryOutput>> {
   return (store: InnerSignalStore<I['state'], I['props'], I['methods']>) => {
      const selectors = factory({ ...store.stateSignals, ...store.computedSignals, ...store.methods });
      const selectorSignals = (Object.keys(selectors) as (keyof WithSelectorsFactoryResult<O>)[]).reduce((acc, k) => {
         acc[k] = (...args) => computed(() => selectors[k](...args));
         return acc;
      }, {} as SelectorSignalsFunction<FactoryOutput>);

      return withMethods(() => ({ ...selectorSignals }))(store) as any;
   };
}

export const myStore = signalStore(
   withState(initialState),
   withSelectors((store) => ({
      userPreferencesAccessor: (userId: number, key: string) => {
         const user = store.users()[userId];
         if (user && user.preferences) {
            return user.preferences[key];
         }

         return undefined;
      },
   }))
);

[Svane20]

The "bad practice" feeling I get from your withMethods approach is not because it is not updating internal store slices (personally i think its ok to have methods that do this but thats beside the point). My main issue is because you are returning the computed value of a reactive signal not the computed signal itself.

For example, if you do const cookiePref = myStore.GetUserPreferences(1, "LikesCookies"), that will give you whether user 1 likes cookies at that particular point in time. If the users signal in the store is updated and user 1 changes his preference to cookies, cookiePref cannot "react" to that change anymore.

I would think you would instead want your method to use the internal state, to build a computed signal based on the users internal signal. Something like:

export const myStore = signalStore(
   withState(initialState),
   withMethods((store) => ({
      getUserPreferences: (userId: number, key: string) => {
         return computed(() => {
            const user = store.users()[userId];
            if (user && user.preferences) {
               return user.preferences[key];
            }
   
            return undefined;
         })
      },
   }))
);

Then when accessing the value of the computed state, you use the preferences signal like so: const cookiePref$ = myStore.getUserPreferences(1, "LikesCookies"); // Signal<any> const cookiePref = cookiePref$(); // any

To me that does not feel strange, but keeps reactivity. If this does not fit your philosophy, would with props be more appropriate?

export const myStore = signalStore(
   withState(initialState),
   withProps((store) => ({
      userPreferencesAccessor: (userId: number, key: string) => {
         return computed(() => {
            const user = store.users()[userId];
            if (user && user.preferences) {
               return user.preferences[key];
            }
   
            return undefined;
         })
      },
   }))
);

const cookiePref$ = myStore.userPreferencesAccessor(1, "LikesCookies"); // Signal<any>

But, i think i am in agreement that a wrapper function could reduce some boilerplate, not sure at what cost though (one that comes to mine is it clear that returns of selectors are wrapped inside computed signals or not). Rough idea could be something like:

type WithSelectorsFactoryResult<FactoryOutput> = Record<string, (...args) => FactoryOutput>;
type SelectorSignalsFunction<FactoryOutput> = {
   [x in keyof FactoryOutput]: FactoryOutput[x] extends (...args: any) => any
      ? (...args: Parameters<FactoryOutput[x]>) => Signal<ReturnType<FactoryOutput[x]>>
      : never;
};
type WithSelectorsOutputResult<O extends SignalStoreFeatureResult, FactoryOutput> = O & {
   methods: SelectorSignalsFunction<FactoryOutput>;
};

function withSelectors<
   I extends SignalStoreFeatureResult,
   O extends SignalStoreFeatureResult,
   FactoryOutput extends {},
>(
   factory: (store: StateSignals<I['state']> & I['props'] & I['methods']) => FactoryOutput
): SignalStoreFeature<I, WithSelectorsOutputResult<O, FactoryOutput>> {
   return (store: InnerSignalStore<I['state'], I['props'], I['methods']>) => {
      const selectors = factory({ ...store.stateSignals, ...store.computedSignals, ...store.methods });
      const selectorSignals = (Object.keys(selectors) as (keyof WithSelectorsFactoryResult<O>)[]).reduce((acc, k) => {
         acc[k] = (...args) => computed(() => selectors[k](...args));
         return acc;
      }, {} as SelectorSignalsFunction<FactoryOutput>);

      return withMethods(() => ({ ...selectorSignals }))(store) as any;
   };
}

export const myStore = signalStore(
   withState(initialState),
   withSelectors((store) => ({
      userPreferencesAccessor: (userId: number, key: string) => {
         const user = store.users()[userId];
         if (user && user.preferences) {
            return user.preferences[key];
         }

         return undefined;
      },
   }))
);

I completely agree, @Devin-Harris. It was a mistake from my side that the withMethods did not return a computed value. I have updated my example.

My point is, as you suggest, that with a wrapper function, a clear section in the signal store that focuses on selectors based on external parameters (internal state changes are handled with withComputed).

I believe that it will allow for a smoother transition from the ngrx/store to ngrx/signals, since at least at my company, where selectors are heavily used.

Alternatively, as suggested, the documentation should be updated to reflect that withProps could be used here. Currently, the documentation showcases how to convert signals to observables and how to inject services when used across multiple sections in the signal store.