Expose selectId As a Prop When Using withEntities

[JordanW9232]

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

signals

Information

When calling withEntities with a config like this:

withEntities(entityConfig({
  entity: type<ExampleEntity>(),
  selectId: entity => entity.customId
})),

I would like the selectId function to be populated in the props of the store so I can reference it later. Maybe call it entitySelectId in the EntityProps<Entity> type. That way when using one of the entity updaters I could just call it like this:

patchState(store, setAllEntities(entities, { selectId: store.entitySelectId });

If using a named entity store, then it might look like this:

withEntities(entityConfig({
  entity: type<ExampleEntity>(),
  selectId: entity => entity.customId,
  collection: 'custom'
})),

The entitySelectId would then be prepended with the collection specified. Like customEntitySelectId. Then we could use it like this:

patchState(store, setAllEntities(entities, { selectId: store.customEntitySelectId, collection: 'custom' });

Describe any alternatives/workarounds you're currently using

In more simple scenarios this isn't really a problem since you can just do this:

const config = entityConfig({
  entity: type<ExampleEntity>(),
  selectId: entity => entity.customId
});

const MyStore = signalStore(
  withEntities(config),
  withMethods(store => ({
    update(entities: ExampleEntity[]) {
      patchState(store, setAllEntities(entities, { selectId: config.selectId });
    }
  }))
);

But in a more complex scenario when you have a custom store feature that expects withEntities to already have been called, you basically need your feature to specify the selectId again:

function withMyCustomEntities<Entity>(customSelectId: SelectEntityId<NoInfer<Entity>>)
{
  return signalStoreFeature(
    {
      state: type<EntityState<Entity>>(),
      props: type<EntityProps<Entity>>()
    },
    withMethods(store => ({
      update(entities: Entity[]) {
        patchState(store, setAllEntities(entities, { selectId: customSelectId }));
      }
    }))
  );
}

Which you would use like this:

const config = entityConfig({
  entity: type<ExampleEntity>(),
  selectId: entity => entity.customId
});

const MyStore = signalStore(
  withEntities(config),
  withMyCustomEntities(config.selectId)
);

But if it was just attached to the store I wouldn't need the extra parameter in my custom feature. I could just do this:

function withMyCustomEntities<Entity>()
{
  return signalStoreFeature(
    {
      state: type<EntityState<Entity>>(),
      props: type<EntityProps<Entity>>()
    },
    withMethods(store => ({
      update(entities: Entity[]) {
        patchState(store, setAllEntities(entities, { selectId: store.entitySelectId }));
      }
    }))
  );
}

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

• Yes
• No

[markostanimirovic]

If you need selectId to be attached to the store instance, you can add it directly in a store where needed (1):

const todoConfig = entityConfig({
  entity: type<Todo>(),
  selectId: (todo) => todo.key,
});

const TodosStore = signalStore(
  withEntities(todoConfig),
  withProps(() => ({ selectId: todoConfig.selectId })),
);

create a custom feature withSelectId (2):

const TodosStore = signalStore(
  withEntities(todoConfig),
  withSelectId(todoConfig.selectId),
);

or create a custom feature that wraps withEntities and adds selectId property:

const TodosStore = signalStore(
  withMyCustomEntities(todoConfig), // uses `withEntities` internally and adds `selectId`
);

---

However, I don't see a significant benefit in doing this. You can directly provide the entity config object to updaters as shown in the official documentation: https://ngrx.io/guide/signals/signal-store/entity-management#entityconfig

const todoConfig = entityConfig({
  entity: type<Todo>(),
  selectId: (todo) => todo.key,
});

const TodosStore = signalStore(
  withEntities(todoConfig),
  withMethods((store) => ({
    addTodo(todo: Todo): void {
      patchState(store, addEntity(todo, todoConfig));
    },
  })),
);

[JordanW9232]

If you need selectId to be attached to the store instance, you can add it directly in a store where needed (1):

const todoConfig = entityConfig({
  entity: type<Todo>(),
  selectId: (todo) => todo.key,
});

const TodosStore = signalStore(
  withEntities(todoConfig),
  withProps(() => ({ selectId: todoConfig.selectId })),
);

Admittedly I don't know how I didn't think of this option initially, which is essentially what I want, but I just think it would be useful to be the default. I suppose it could have the entire config object as a prop as well rather than just selectId, that would probably be better.

However, I don't see a significant benefit in doing this. You can directly provide the entity config object to updaters as shown in the official documentation: https://ngrx.io/guide/signals/signal-store/entity-management#entityconfig

const todoConfig = entityConfig({
  entity: type<Todo>(),
  selectId: (todo) => todo.key,
});

const TodosStore = signalStore(
  withEntities(todoConfig),
  withMethods((store) => ({
    addTodo(todo: Todo): void {
      patchState(store, addEntity(todo, todoConfig));
    },
  })),
);

As mentioned in my post, you're right. It is not really beneficial in this scenario. It's mainly just useful when you have a custom store feature and DON'T already wrap withEntities inside of it. Like from my last snippet. (tweaked slightly to work with the entire config object)

function withMyCustomEntities<Entity>()
{
  return signalStoreFeature(
    {
      state: type<EntityState<Entity>>(),
      props: type<EntityProps<Entity>>()
    },
    withMethods(store => ({
      update(entities: Entity[]) {
        patchState(store, setAllEntities(entities, store.entityConfig));
      }
   }))
 );
}

I know the easy solution is to just wrap withEntities in here too. I'm just stubborn and wanted to be able to have them separate for whatever reason haha