RFC: `signalStoreFeature` and access to Store about platform

[rainerhahnekamp]

Thanks, I never used it honstly. Was just a quick prototype.

In our extensions we still depend on the non-public types. This feature would improve the situation, but only if it lands in the core (also depends on internal types).

[gabrielguerrero]

@rainerhahnekamp I had a need for this in an app, and I gave it a go at trying to implement it, I got it working, and then just noticed you had a version in stackblitz, my version has a few improvements like it keeps the wrapped feature input type in case you need it as well

import { SignalStoreFeature } from '@ngrx/signals';
import type {
  SignalStoreFeatureResult,
  SignalStoreSlices,
} from '@ngrx/signals/src/signal-store-models';
import type { StateSignal } from '@ngrx/signals/src/state-signal';
import { Prettify } from '@ngrx/signals/src/ts-helpers';

export function withFeatureFactory<
  Input extends SignalStoreFeatureResult,
  Feature extends SignalStoreFeature<any, any>,
>(
  featureFactory: (
    store: Prettify<
      SignalStoreSlices<Input['state']> &
        Input['signals'] &
        Input['methods'] &
        StateSignal<Prettify<Input['state']>>
    >,
  ) => Feature,
): SignalStoreFeature<
  Input & (Feature extends SignalStoreFeature<infer In, any> ? In : never),
  Feature extends SignalStoreFeature<any, infer Out> ? Out : never
> {
  return ((store: any) => {
    const { slices, methods, signals, hooks, ...rest } = store;
    return featureFactory({
      ...slices,
      ...signals,
      ...methods,
      ...rest,
    } as Prettify<
      SignalStoreSlices<Input['state']> &
        Input['signals'] &
        Input['methods'] &
        StateSignal<Prettify<Input['state']>>
    >)(store);
  }) as Feature;
}

[gabrielguerrero]

That's a good point. I also use non-public types in a few places, but this is mainly because I need to allow methods to use things from the store. If this were part of the core, it would reduce the need to expose those non-public types.

[gabrielguerrero]

Having thought on this more, maybe this could be an overload of the signalStoreFeature like

signalStore(
  withMethods(() => {
    const httpClient = inject(HttpClient);
    return {
      load() {
        return httpClient.get<Person[]>('someUrl');
      },
    };
  }),
  signalStoreFeature((store) => withEntityVersioner(() => store.load())),
);

[GuillaumeNury]

I would love to write:

signalStore(
  withMethods(() => {
    const httpClient = inject(HttpClient);
    return {
      load() {
        return httpClient.get<Person[]>('someUrl');
      },
    };
  }),
  withEntityVersioner((store) => store.load()),
);

But as I asked in #4272, it requires to expose more types to the public API.

[rainerhahnekamp]

@gabrielguerrero, I think - and please correct me if I'm wrong - we are talking here about two different features.

• You need more feature functions and want to fix that by using signalStoreFeature because that's the closest thing at hand. So your usage of signalStoreFeature is bound to a specific signalStore.

flowchart LR
  signalStoreFeature --> Service --> signalStore

• I was speaking of providing a genericsignalStoreFeature which needs to get features of an existing signalStore by not depending on it.

flowchart LR
  ServiceImplementation --> signalStore
  withFeatureFactory --> GenericService
  withFeatureFactory --> ServiceImplementation
  signalStoreFeature --> GenericService

I'd we need both but maybe not under the same name.