RFC: withFeatureFactory

[RomainDood]

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

signals

Information

Hi,

I believe I've found a better approach than the existing withFeature function to implement custom SignalStore features that depend on an input value from the store.

Currently, to add a custom feature that requires an input from the store, developers must manually use the withFeature utility.
While this works, it introduces boilerplate and breaks the composability of features, since the custom feature cannot be passed directly into the signalStore factory.

The goal is to make it possible to use custom signalStoreFeatures in the same way as built-in functions like withState, withMethods, etc.
This improves readability and results in cleaner, more consistent code.

Here's a comparison between using withFeature and the proposed withFeatureFactory:

const filteredBooksFeature = (books: Signal<Book[]>) =>
  signalStoreFeature(
    withState({ query: '' }),
    withComputed((store) => ({
      filteredBooks: computed(() =>
        books().filter((b) => b.name.includes(store.query()))
      ),
    })),
    withMethods((store) => ({
      setQuery(query: string): void {
        patchState(store, { query });
      },
    }))
  );

const withBooksFilter = withFeatureFactory(filteredBooksFeature);

const BooksStore = signalStore(
  withEntities<Book>(),
  // ⚠️ withfeature 
  withFeature(({ entities }) => filteredBooksFeature(entities)), // 👈 NgRx example
  // ✅ withFeatureFactory👇 full access to the store with type-safety
  withBooksFilter(({ entities }) => entities)
);

The returned type of the inner function must match the type of the first parameter of the feature (in this case, filteredBooksFeature).
This is fully type-safe and enforced by TypeScript.

However, there is one limitation: the custom feature (like filteredBooksFeature) must accept exactly one parameter.
Otherwise, the inner function (withBooksFilter(({ entities }) => entities)) would have to return an array, which would be semantically strange and less intuitive.

To avoid this, I chose to enforce that the feature factory only accepts a single parameter.
If multiple values need to be passed, they can be wrapped in a single object with multiple properties.

// ❌ Not allowed:
withFeatureFactory((signalA: A, signalB: B) => ...)

// ✅ Good:
withFeatureFactory(({ signalA, signalB }: {signalA: A, signalB: B}) => ...)

Here's a reproduction where I explored different approaches to find the most ergonomic and type-safe solution:
https://stackblitz.com/edit/stackblitz-starters-31qrd2nq?file=withFeature%2F1-simple-only-one-helper-to-use.spec.ts

And I made an article about that (https://dev.to/romain_geffrault_10d88369/ngrx-signalstore-hacks-beautiful-dx-with-custom-features-1n4k)

Describe any alternatives/workarounds you're currently using

No response

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

• Yes
• No

[rainerhahnekamp]

Hey, I think that's withFeature v2 and that we should have it.

---

If the team as a whole agrees to move forward with this, here are a few thoughts from my side.

Name

I'd like to challenge the name. At the moment, everything starting with with-* returns a feature. withFeatureFactory does not. So here are some alternatives:

• featureFactory
• featureWithStore
• bindFeature

One-Parameter Limitation

The one-parameter limitation is not a problem at all. We have the same for signalMethod and rxMethod.

Testing

For the tests, make sure to verify it works with the input constraints. If something can go wrong in terms of typings, it usually happens there first.

Future of withFeature?

If everything goes well, with withFeatureFactory, I see withFeature as a candidate for deprecation. There is nothing that withFeatureFactory can't do what withFeature can.

Initially, my case would have been for decoupling. You don't have to have access to the source code of the feature, but still integrate it better into an existing store.
const withBooksFilter = withFeatureFactory(filteredBooksFeature); does the same.

Accompanying ESLint rule

I would also opt for an ESLint rule for any function returning signalStoreFeature and having parameters. They could be easily be replaced with withFeatureFactory and bring better DX with no additional costs.

[RomainDood]

Thank you for this first feedback.

Name

Here are some other propositions :

• buildFeature
• toFeature
• toInnerSignalStorefeature

Testing

Yes, it is so easy to lose the incoming input types.
I saw there is some type testing using expecter (from ts-snippet).
I think, I understand how It is working. I can create the typing test 👍

[ronnain]

Another question, should the inner store exposeSTATE_SOURCE and return it too (or the returned type should filter the STATE_SOURCE ?

I do not know why it is expose in withFeature ?

[markostanimirovic]

@RomainDood Is it possible create features with generic types using your solution?

For example, how would you implement the following feature:

export function withSelectedEntity<Entity>(entityMap: EntityMap<Entity>) {
  return signalStoreFeature(
    withState<SelectedEntityState>({ selectedEntityId: null }),
    withComputed(({ selectedEntityId }) => ({
      selectedEntity: computed(() => {
        const selectedId = selectedEntityId();
        return selectedId ? entityMap()[selectedId] : null;
      }),
    }))
  );
}

// store
export const UsersStore = signalStore(
  withEntities<User>(),
  withFeature(({ entityMap }) => withSelectedEntity(entityMap)),
);

[RomainDood]

@markostanimirovic , very interesting case 😉 !
I make some test, and I think it not possible to use generic types like that.
Because, TS does not handle passing a callback type to a mapper.

But I will make some more try to find a proper solution for this case.

[RomainDood]

Feature with generic type

To handle features with generic type, I propose something like that:

const { selector: selectedEntitySelector, withFeature: withSelectedEntity } =
  createGenericFeature(<Entity>(entityMap: Signal<EntityMap<Entity>>) =>
    toSignalStoreFeatureResult(
      signalStoreFeature(
        withState<{ selectedEntityId: string | null }>({
          selectedEntityId: null,
        }),
        withComputed(({ selectedEntityId }) => ({
          selectedEntity: computed(() => {
            const selectedId = selectedEntityId();
            return selectedId ? entityMap()[selectedId] : null;
          }),
        }))
      )
    )
  );

const testPassingGenericType = signalStore(
  withEntities<Book>(),
  withSelectedEntity((store) => selectedEntitySelector(store.entityMap)) 👈 I find no way to simplify this part 
);
const myStore = new testPassingGenericType();

const result = myStore.selectedEntity; // Signal<Book | null>

The createGenericFeature, can be a little bit simplify, if their is a pipe function that return the SignalStoreResult instead of a SignalStoreFeature like toSignalStoreFeatureResult.

const { selector: selectedEntitySelector, withFeature: withSelectedEntity } =
  createGenericFeature(<Entity>(entityMap: Signal<EntityMap<Entity>>) =>
    toSignalStoreFeatureResult(
      withState<{ selectedEntityId: string | null }>({
        selectedEntityId: null,
      }),
      withComputed(({ selectedEntityId }) => ({
        selectedEntity: computed(() => {
          const selectedId = selectedEntityId();
          return selectedId ? entityMap()[selectedId] : null;
        }),
      }))
    )
  );

I hope their is other way to handle features with generic type. During all my test, it was required to use 2 functions (withSelectedEntity and selectedEntitySelector), I can not use only one function without loosing the generic type.

Here a reproduction: https://stackblitz.com/edit/stackblitz-starters-31qrd2nq?file=withFeature%2Fhandle-feature-with-generic.ts

What do you think ?

[ronnain]

Feature with Generic types proposition 2

Another way that is, I think acceptable is something like that:

function withSelectedEntity2<
  Input extends SignalStoreFeatureResult, // required
  Store extends StoreInput<Input>,  // required
  Entity // Generic type parameter
>(entries: (store: Store) => Signal<EntityMap<Entity>>) {
  const entityMap = entries({} as Store);
  const feature = signalStoreFeature(
    withState<{ selectedEntityId: string | null }>({
      selectedEntityId: null,
    }),
    withComputed(({ selectedEntityId }) => ({
      selectedEntity: computed(() => {
        const selectedId = selectedEntityId();
        return selectedId ? entityMap()[selectedId] : null;
      }),
    }))
  );
  //                      👇 pass explicitly the types parameters
  return toGenericFeature<Input, GenericFeatureResult<typeof feature>>(feature);
}

const Test2FeatureWithGenericStore = signalStore(
  withEntities<Book>(),
  withSelectedEntity2((store) => store.entityMap)
);

const test2FeatureWithGenericStoreImpl = new Test2FeatureWithGenericStore();
test2FeatureWithGenericStoreImpl.selectedEntity; // Signal<Book | null>

This proposition needs to expose some functions and types helper but, it think it is pretty ok to use it like that.
Here the demo: https://stackblitz.com/edit/stackblitz-starters-31qrd2nq?file=withFeature%2Fhandle-feature-with-generic-2.ts

Note: the examples does not handle the logic, It just handle the typing part

[rainerhahnekamp]

@RomainDood good work! That said, I think withFeatureFactory should aim to match or improve the DX for generics as well. At the moment, withFeature still feels more straightforward in these cases.