Real-time collaboration: Add more robust mergeCrdtBlocks() testing

[alecgeatches]

As part of the work in add/flattened-rtc-blocks, we're making significant changes to the Y.Doc block data structure. This PR adds more complex and edge-case testing for mergeCrdtBlocks(), and also fixes a couple of bugs found during the process.

We will use these tests to reduce the risk that block data structure changes introduce merge errors.

Fixed bugs

1. The handles block type changes from non-rich-text to rich-text test was failing when an attribute transitioned from a raw string to rich-text (Y.Text) content when the string value was the same. The fix is the attributeHasTypeChange boolean which ensure both the data type and content must be the same to skip a merge.

2. Client Id deduplication was only running on a single level of blocks, which caused the removes duplicate clientIds across different nesting levels test. This meant a client ID could be freely duplicated as long as it was not in the same nesting level within the block structure. The code has been changed to:

   1. Merge blocks, then
   2. Check at the top level that all client IDs are unique.

   This required making an internal mergeCrdtBlocksInternal() function that does the normal work of what mergeCrdtBlocks() did previously, then run the top level logic after. This ensures the whole block structure of client IDs are deduplicated and avoids recursively making that check.

Testing Instructions

To run the CRDT test suite:

npm run test:unit -- --testPathPattern=crdt-blocks

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: [Package] Core data.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: alecgeatches <[email protected]>
Co-authored-by: chriszarate <[email protected]>
Co-authored-by: SirLouen <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[alecgeatches]

@chriszarate Added a few new tests for mergeCrdtBlocks() and a couple of bug fixes. Please take a look when you have a chance.

[chriszarate]

is this logic inverted for any particular reason?

[alecgeatches]

This just allows the recursion on innerBlocks to run even if the current block is missing a client ID. I'm not clear on when a clientId will be missing from a block or if that's even a real possibility, but it was accounted for in the original code. Do you have any insight on when this happens? Should we also bail on innerBlocks in this unusual case?

[SirLouen]

@alecgeatches this patch is not applying for me. It's rebased to the lastest trunk?

I cannot find a cursorPosition in crdt-blocks-ts

https://github.com/WordPress/gutenberg/blob/trunk/packages/core-data/src/utils/crdt-blocks.ts

[alecgeatches]

@SirLouen This PR is currently into our WordPress:wpvip/rtc-plugin branch, which we use to make changes upstream of actual Gutenberg trunk.

You can see cursorPosition in the branch: https://github.com/WordPress/gutenberg/blob/wpvip/rtc-plugin/packages/core-data/src/utils/crdt-blocks.ts#L195

[SirLouen]

@alecgeatches is this an unofficial fork or something? Isn't planned to be merged into trunk?