RFC: `signalStoreFeature` and access to Store about platform

[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]

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).

[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.

[rainerhahnekamp]

@Donnerstagnacht

you find a working and typed solution at https://stackblitz.com/edit/ngrx-signal-store-starter-z3q5i5?file=src%2Fmain.ts

Your withIncrement will not get the store but an wrapper function which patches the state. By doing that we can decouple withIncrement from the specific store and make it therefore reusable.

[GuillaumeNury]

@rainerhahnekamp I tried to implement again the withTabVisibility feature, using withFeatureFactory and I do not need internal types anymore 😍

https://stackblitz.com/edit/ngrx-signal-store-starter-dmybgr?file=src%2Fmain.ts

The only change is going from:

signalStore(
  withTabVisibility({
    onVisible: (store) => store.loadOpportunity(store.opportunityId()),
  }))

to:

signalStore(
  withFeatureFactory((store) =>
    withTabVisibility({
      onVisible: () => store.loadOpportunity(store.opportunityId()),
    }),
  )
)

[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())),
);

[gabrielguerrero]

Hey @rainerhahnekamp, I was indeed referring to having the withFeatureFactory be just an overloaded in signalStoreFeature, my reasoning was that the names are similar and I was not sure about the name withFeatureFactory when its main goal is just to give access to the store to another store feature, I don't want people to think they can be use to create store features, that's signalStoreFeature job, which is where I got the idea of maybe making it part signalStoreFeature, an overloaded version that receives factory function with the store as param. I'm just brainstorming, really; I'm not really sure it is a good idea; maybe we just need a different name for withFeatureFactory.

[Donnerstagnacht]

Is this proposal also intended to enable other signalStoreFeatures to manipulate the state of a store?

Something like:

const counterStore = signalStore(
  { providedIn: 'root' },
  withState(intitialState),
  witSharedState((store) => withIncrement<counter>('items', store))
);

function withIncrement<Entity extends object>(
  key: keyof Entity,
  sharedStoreIn: StateSignal<Entity>
) {
  return signalStoreFeature(
    withMethods(() => {
      const sharedStore = sharedStoreIn as any; //How to type the store?
      return {
        withIncrement() {
          patchState(sharedStore, { [key]: sharedStore[key]() + 1 });
        },
      };
    })
  );
}

Even if it is not intended, could someone help me to type out that use case?
https://stackblitz.com/edit/ngrx-signal-store-starter-23tsna?file=src%2Fmain.ts

Probably, it could also be an idea to let developers choose if they want to share store elements and offering a system like "shareState()", "shareMethods(), "shareStore()".

[GuillaumeNury]

@Donnerstagnacht you can also do it with already available feature store Input condition (as documented here)

https://stackblitz.com/edit/ngrx-signal-store-starter-rlktqe?file=src%2Fmain.ts

[GuillaumeNury]

@rainerhahnekamp in your last example, it seems weird to move the updaterFn out of the custom feature. I like the withFeatureFactory, but I'd rather use it like this:

https://stackblitz.com/edit/ngrx-signal-store-starter-qedtku?file=src%2Fmain.ts

But a type SignalStoreFeatureStore would be needed (I am not sure about the naming of this type 😅)

[rainerhahnekamp]

Hi @GuillaumeNury, yeah that's much better.

In the end, it is the old story about getting access to the internal types, right?

[rainerhahnekamp]

@GuillaumeNury, @Donnerstagnacht: I've updated my version. Turned out that the only type we really need is SignalState and that one is public.

So we can use the version of @GuillaumeNury and not violate the encapsulation.

[GuillaumeNury]

@rainerhahnekamp kind of. But with SignalState + 'withFeatureFactory' we can keep internals hidden 🎉

I changed the generic of withIncrement to allow the state to have non-numeric properties : https://stackblitz.com/edit/ngrx-signal-store-starter-pozgde?file=src%2Fmain.ts

The result looks wonderful! I hope to see this in v18.X 😁