@ngrx/signals: updateEntity method don't update key in entityMap about platform HOT 9 OPEN

@markostanimirovic is there any workaround in the meantime?

You can do:

const myEntity = { ...entityMap()['tmp_id'], id: 'real_id' };

patchState(store, removeEntity('tmp_id'), addEntity(myEntity));

from platform.

I'm also not a big fan of updating the ID. 👀 That's the reason why the current implementation does not support it. On the other hand, @ngrx/entity provides the ability to change the ID, so this change may land for compatibility.

from platform.

so this change may land for compatibility

Thank you @markostanimirovic

@markostanimirovic @ducin

IMO changing an ID is doable but is a very bad idea and should not be done

I'm also not a big fan of updating the ID.

I understand your concerns, but there are legitimate cases where it may be necessary to create a temporary ID. If you guys are interested, I can go into this topic in more detail.

However, I think the decision of what do to with the id belongs to the developer or team ✌️☮️

from platform.

This will be a breaking change for entities whose identifier name is different from id. In other words, it will be required to pass idKey in case of a custom identifier for all update... entity updaters which is not the case with the current implementation.

Even though the @ngrx/signals package is in a developer preview, we try to minimize breaking changes, so there is a chance that this change will land in v18 instead of v17.x.

from platform.

@markostanimirovic

I can confirm this behaviour. We have the same expectation as @xSirrioNx .
Additionally to store.entityMap, store.ids() contains also the old tmp id instead of the new id.

from platform.

IMO changing an ID is doable but is a very bad idea and should not be done, as it's a design mistake to change IDs ever.

IDs are meant to be immutable (never change), as they identify entities across systems. Guessing from your code, there is some time span where you don't have any id. Either don't put the object into the store (if the backend hasn't assigned an id, it's NOT an entity YET) - or make the frontend assign a GUID and send it to the backend. I'd go with putting the entity into the store after it's returned from the server (with ID)

to make types bullet proof, I'd go with "strict unions" - disable the ability to pass the id at all:

declare function disable_id_from_partial<T>(withoutId: Partial<T> & { id?: undefined }): void;
disable_id_from_partial<Todo>({ name: 'some_real_name' }) // ✅ OK
disable_id_from_partial<Todo>({ id: 'uuid', name: 'some_real_name' }) // ❌ ID - NOT OT

from platform.

So we can add separeted method to change entity ID

For example:

patchState(store,
  updateEntity({ id: 'old_id', changes: {id: 'new_id'}}),
  changeEntityId('old_id', 'new_id')
)

from platform.

@markostanimirovic is there any workaround in the meantime?

from platform.

@markostanimirovic thanks.

from platform.