@ngrx/entity add setOne (replaceOne?) method

[dmytro-gokun]

Currently, the only way to replace an item is by using upsertOne. That does not work well with 'undefined' though (which is the case when the backend omits nulls when serializing to JSON). For example, i have an entity in the collection: {id: 1, name: 'foo', note: 'lorem ipsum'}. I want to replace it with {id: 1, name: 'foo'}. Obviously, upsertOne does not do the job well. Since the object is already there, it attempts to perform an update, thus treating the new object as a patch and leaving 'note' value unchanged. So, a new method 'setOne' is needed here.

Describe any alternatives/workarounds you're currently using

removeOne/addOne does the trick, but is not very efficient.

If accepted, I would be willing to submit a PR for this feature

[X ] Yes (Assistance is provided if you need help submitting a pull request)
[ ] No

[AdditionAddict]

Note upsertOne treats the passed entity as an update as does @ngrx/entity. In fact, previous interface was that the payload was an Update<T>. I'd say how upsertOne is behaving is intended behaviour which has been assessed in previous issues - #1604 (closed) #2061 (open)

I think upsertOne should have Partial <T> though.

Also every dictionary definition I've found has upsert means insert or update.
I think replaceOne is closer to the equivalent database term though I'd still vote for setOne if approved

[dmytro-gokun]

@AdditionAddict I do not think there is any issue with upsertOne. It behaves in accordance with ngrx's update semantic. All is well here. It's just that it does not cover all possible scenarios. That's why i think setOne is needed.

As to name, i chose setOne to follow the pattern which is already here after a recent rename of addAll to setAll: #2347

[AdditionAddict]

@dmytro-gokun I agree

[timdeschryver]

I think adding a setOne makes sense, now that we have setAll.
Also, this is an issue that comes up regurarly (as pointed out)

[dmytro-gokun]

@timdeschryver Great, i'll work on a PR

[timdeschryver]

@dmytro-gokun can you hold it off for a bit?
I want to hear @brandonroberts 's thought about this first.

[dmytro-gokun]

@timdeschryver sure

[brandonroberts]

Sounds good to me