[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
User vs Update<User>). See reproduction app/user.reducer.ts#14 & app/user.reducer.ts#18.upsertOne or upsertMany as documenten in Medium Blogpost or github docs. Instead a type of Update<Entity> is expected (which is in the form of {id: number; changes: Partial<Entity>} (See reproduction example)Possibly related to #817.
User vs Update<User>https://stackblitz.com/edit/ngrx-upsert-bug
ngrx store / entity 5.1.0
This is an issue with our docs. You are correct that the type signature is Update<Entity>.
Is this by design or by accident?
I figured I would just pass the entity to the API and it would be handled behind the scenes.
As the docs and medium blogpost do this as well, wouldn't it be the more logical thing to do as more people would expect it to function that way?
For now I agree it is a docs issue, however I think the API consumer shouldn't pass an Update<User> but instead a User.
(Note: The Update object seems to be necessary here, but shouldn't, see #818 )
817 Seems to agree.
I like the way the upsert is being described in the docs:
return adapter.upsertOne(myEntity, state);
IMO, upsert is an insert that silenty updates existing entities. The API for this should be closer to "add" than to "update". Using upsert with the current API will probably always look like this:
const update = { id: myEntity.id, changes: myEntity };
return adapter.upsertOne(update, state);
The Update object always has to be created manually, even though it always looks the same.
I'd really like to see the API in the first proposed way (the one that is in the docs).
Thank you!
I have the same idea too. But there was a long discussion and everyone have agreed that upsert should have the same signature with update so I made PR following that. https://github.com/ngrx/platform/issues/421
Docs fixed in 1ffb5a9bf03ef7932443ab212a165c6e163f530f.
I also believe just the Entity should be the arg instead of Update<Entity>, but let #817 carry on that discussion if needed, no use having 2 open issues for somewhat the same thing.
I'm having an issue with the typing too. When an Object of
@miniplus can you reopen this issue?
Most helpful comment
I'm having an issue with the typing too. When an Object of get's updated in the state, the type is lost and it's just an Object