applyPatches produces same result, but should it also preserve identity?
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 29k
- Forks
- 881
- PR merge metrics
- No merged PRs in 30d
Description
🙋♂ Question
Consider the following code:
https://codesandbox.io/s/immer-sandbox-forked-t7ghd9?file=/src/index.ts
While patchedState is indeed deep equal to producedState, there is a difference in that produce preserves object identity, but applyPatches does not.
Is this a property that would be useful? I arrived at this during a different route, which may be my real question: when an unshift happens, instead of an add op for path ["items", 0], which I expected, instead the patches include a replace op for the first two items in the array, and then an add op for position ["items", 2]. Applying these patches will result in object identity being broken.
I am experimenting with using Immer for change tracking, and this makes life more complicated: I want to track whether I need to update paths if their indices have shifted, but I don't get sufficient information from the patch to determine that.
Link to repro
https://codesandbox.io/s/immer-sandbox-forked-t7ghd9?file=/src/index.ts
Environment
We only accept questions against the latest Immer version.
- Immer version: 9.0.12
- Occurs with
setUseProxies(true) - Occurs with
setUseProxies(false)(ES5 only)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked CodeSandbox reproduction and compare the identity behavior of produce and applyPatches for the unshift example. Review the generated replace and add operations for items, then establish whether preserving object identity and providing enough information about shifted indices are intended requirements. Done means a documented decision or an agreed implementation scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100