[Feature Request] Support for "Splice" patches in arrays for CRDT/Y.js integration (and others)

[xaviergonz]

Currently, when performing array operations like splice(), shift(), or unshift(), Immer generates standard JSON patches (RFC 6902). While spec-compliant, this approach is inefficient for arrays when items are added or removed from the middle.

For example, given [1, 2, 3, 4], calling .splice(1, 1) results in:

• replace index 1 with 3
• replace index 2 with 4
• remove index 3

The Problem
This "shifting" behavior is problematic for CRDTs (like Y.js) or observation-based libraries (like MobX).

Performance: Large arrays trigger a cascade of patches for a single deletion.

Convergence: In Y.js, "replacing" an element is different from "shifting" it. If Immer reports that every element after the splice point has been replaced, the CRDT loses the identity of those objects, breaking the ability to merge concurrent changes effectively.

Proposed Solution

I propose an optional configuration (e.g., arraySplice: true) that generates a non-standard splice operation for array mutations. This would group push, pop, shift, unshift, and splice into a single descriptive patch.

Example Proposed Patch Format:

{
  "op": "splice",
  "path": "/arr",
  "index": 1,
  "deleteCount": 1,
  "items": [...]
}

Use Case

Y.js / Automerge integration: Directly mapping a splice patch to yArray.delete(index, count) and yArray.insert(index, items).

In MobX / other libs it is just calling a splice operation instead.

Performance Optimization: Reducing the payload size when syncing state across WebSockets.

Identity Preservation: Ensuring that elements not being deleted maintain their reference/identity in the eyes of the consumer.

Additional Context

Libraries like mobx use this observation pattern successfully. While I understand Immer aims for JSON Patch compatibility, providing an opt-in for "Rich Patches" or "Splice Patches" would make it the go-to library for distributed state management.

[xaviergonz]

I just realized that to implement this it probably would be easier to add another mode of operation that generates the patches as soon as the operation is made, rather than comparison at the end.

The pro is that it should be much faster to generate (we don't have to compare the whole initial array with the final one). The con is that there might be extra "patches" for idempotent operations (for example, a push+pull from an array would generate two patches rather than 0).