refactor: preserve order in patch serialization

[ricokahler]

This PR refactors the internal serializePatches function to use a recursive approach. The primary goal of this change is to better preserve the original order of operations as they are generated by diffItem when they are grouped into SanityPatchOperations.

Previously, serializePatches would filter all patches by type (set, unset, insert, dmp) and then combine them. This could lead to a reordering of operations if, for example, a set operation was diffed before an unset operation that should logically follow it.

The new recursive approach processes patches one by one:

• It attempts to merge consecutive patches of the same type (e.g., multiple set operations can be combined into a single set: {...} object).
• If a patch of a different type is encountered, the current accumulated patch operation object is emitted, and a new one is started for the new type.
• insert operations always result in a new patch object being emitted, as they are not typically batched with other operation types in the same way.

Key Changes:

• Recursive serializePatches:
  • The serializePatches function now takes an optional curr?: SanityPatchOperation parameter to carry the currently accumulating patch object.
  • It processes the head of the patches array:
    • For set and diffMatchPatch: If curr is undefined or of a different type, a new curr is started. Otherwise, the operation is merged into the existing curr.
    • For unset: Similar logic to set, but merges into curr.unset[].
    • For insert: If curr exists, it's emitted first, then the insert operation is emitted as a new patch object.
  • This ensures that if the diffing process generates, for example, set, then unset, then set again, these will be serialized into distinct patch operation objects, preserving that logical sequence.
• Test Snapshot Updates:
  • Snapshots have been updated to reflect the new serialization order. In many cases, this results in more individual patch objects within a SanityPatchMutation[] array where previously operations might have been grouped less granularly or in a different order. For example, a set followed by a diffMatchPatch will now be two separate entries in the SanityPatchMutation[] array if they were generated in that order by diffItem.

Rationale:

• Order Preservation: Ensures that the sequence of operations (e.g., an unset happening before a set on a related path) as determined by the diffing logic is maintained in the serialized output. This can be important for the logical application of patches, especially in more complex scenarios or when patches might be manipulated or inspected before application.
• Clearer Grouping: While potentially leading to more patch objects in the array, the grouping is now more directly reflective of the sequence of changes.
• Foundation for Future Enhancements: This recursive structure might be more adaptable for future features that require more nuanced control over patch grouping or ordering (e.g., reordering patches).

This change primarily affects the internal serialization and the structure of the output array in snapshots, aiming for a more robust and order-preserving serialization.

[ricokahler]

• refactor: preserve order in patch serialization #42 : 2 dependent PRs (#40 , #41 ) 👈 (View in Graphite)
• feat!: replace diffItem with diffValue #39
• feat!: remove undefined-to-null conversion warnings and simplify internal APIs #38
• refactor: simplify array unset logic by removing revision lock check #37
• feat!: replace configurable DMP with perf-based heuristics #36
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[rexxars]

It is unclear to me if this actually fixes any current bugs? I understand that it's needed for later changes, but if there are potential bugs in the current implementation, we should ensure this one has a failing test (that gets fixed by this PR)

[ricokahler]

Merge activity

• Jun 13, 7:24 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jun 13, 7:34 PM UTC: Graphite rebased this pull request as part of a merge.
• Jun 13, 7:36 PM UTC: @ricokahler merged this pull request with Graphite.