feat(signals): add SignalStoreFeatureType

[rainerhahnekamp]

This allows custom features to reuse another feature's inferred state, props, and methods as input without duplicating the feature result type manually.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngrx/platform/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Documentation has been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Closes #5185

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

[martin-the-geek]

We have something similar in our project except we have a second generic parameter where we can specify a subset of keys to depend on which helps limit the setup in our feature tests.

From memory it went something like this

type StoreFeatureResultKeys<T extends StoreFeatureResult> = keyof T['state'] | keyof T['props'] | keyof T['methods'];

type ExtractedStoreFeature<Feature extends (...params: never[]) => unknown> =
  ReturnType<Feature> extends SignalStoreFeature<infer Input, infer Output>
    ? Input & Output
    : never;

export type SignalStoreFeatureType<
  Feature extends (...params: never[]) => unknown,
  Keys extends StoreFeatureResultKeys<ExtractedStoreFeature<Feature>> = StoreFeatureResultKeys<ExtractedStoreFeature<Feature>>
> = {
  state: Pick<ExtractedStoreFeature<Feature>>['state'], Extract<Keys, keyof ExtractedStoreFeature<Feature>>['state']>>,
  props: Pick<ExtractedStoreFeature<Feature>>['props'], Extract<Keys, keyof ExtractedStoreFeature<Feature>>['props']>>,
  methods: Pick<ExtractedStoreFeature<Feature>>['methods'], Extract<Keys, keyof ExtractedStoreFeature<Feature>>['methods']>>,
};

// to depend on an entire feature
type<SignalStoreFeatureType<withSomeFeature>>()

// to depend on a subset of the feature
type<SignalStoreFeatureType<withSomeFeature, 'stateA' | 'methodB'>>()

[rainerhahnekamp]

@martin-the-geek, but why would you want that?

I see SignalStoreFeatureType is a type for a specific feature. If you want a more generic one that could be implemented by multiple signalStoreFeature types, then I understand the motivation behind your approach. But even then, I would write a generic type manually, meaning I would not like to depend on an existing one.

I just don't know if we are overcomplicating things here.

[martin-the-geek]

@rainerhahnekamp Our motivation for having a convenience type to identify a subset of a feature is to narrow the dependencies of another feature to limit the impacts to our feature tests.

If feature A depends on only a few signals from feature B but feature B has dozens, when testing feature A we only have to add the few bits to our test store that feature A depends on. Also, if in the future feature B adds some elements that are irrelevant to feature A, we don't have to update feature A's tests to include the new elements. Problem gets worse if feature B depends on feature C, etc.

Sure, I guess we just keep the key limiting type custom to our app, but it might be useful for others.

[rainerhahnekamp]

@markostanimirovic, could please re-check?

[markostanimirovic]

👏