Real-time Collaboration: Regenerate the blocks correctly in RTC mode and allow use of the code editor#75359
Real-time Collaboration: Regenerate the blocks correctly in RTC mode and allow use of the code editor#75359ingeniumed wants to merge 4 commits into
Conversation
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +13 B (0%) Total Size: 3 MB
ℹ️ View Unchanged
|
chriszarate
left a comment
There was a problem hiding this comment.
Looks good, but I don't see a usable code editor in my testing:
Screen.Recording.2026-02-09.at.21.46.20.mov
Ah yes, I should have noted that. You have to hit save draft for the changes to be reflected. It's not reflecting the changes until then. That would need a follow up PR |
…neration-of-the-blocks
| } | ||
|
|
||
| if ( editedBlocks ) { | ||
| if ( editedBlocks && editedBlocks.length > 0 ) { |
There was a problem hiding this comment.
I don't really understand this change, why reparse the blocks if we already have blocks (empty array)
There was a problem hiding this comment.
I think what you should be exploring is syncing "undefined" as a valid value for the "blocks" property in YJS representation.
There was a problem hiding this comment.
Thanks for that feedback @youknowriad. My original intention was to see how I could get the blocks to re-parse before they are fed to Yjs, so that all the peers have the parsed blocks.
I've now re-done it, to support undefined as a valid syncing value for the blocks property in Yjs. Now, the same behaviour I recorded above is visible without any changes to the core parts of Gutenberg that could impact non-rtc mode.
Something I have noticed:
- Any changes in the code editor don't get reflected until
save draftis hit.
My guess is that, save post needs to be run before the blocks are re-parsed and the updated ones are shown for the other collaborators. This needs to be dug into further, but it's not critical for this PR as the code editor wasn't even useable until now. This can be looked at in a follow up PR.
@chriszarate - hopefully I haven't missed anything obvious here that could go wrong with this change. I tested selections and any other areas that could cause problems. I couldn't trigger any errors so this is looking good.
There was a problem hiding this comment.
I opened #75437 after our discussion here and in Slack
There was a problem hiding this comment.
I'll close this PR in favour of that one.
…ntity-block-editor hook
|
The changes from this PR have been incorporated into #75437, with the addition of the content being synced as well. Closing this PR as a result. |
What?
Blocks are not being re-generated automatically within the editor, when RTC is enabled. It's increasingly getting necessary to send parsed blocks down to the
editEntityRecordmethod rather than the default way it's done in Gutenberg which is to not worry as they'd be regenerated.Interestingly, this also rears its head in the code editor where if any modification is made to the blocks (valid or not) they are cleared entirely. There's no follow up parsing that's done.
Partially fixes #74831.
Why?
The hook
use-entity-block-editordoesn't look to see if theeditedBlockswithin a record are empty. When RTC mode isn't enabled it's fine because the blocks will be regenerated before the editor renders them. Within RTC mode however, the YJS doc immediately transmits all the changes to all the collaborators as soon as it receives the empty blocks.This also ensure any changes in the code editor correctly parse the blocks, and doesn't result in any data loss.
Note: you do have to hit save draft to see changes from the code editor
How?
The hook is now tweaked to check if the
editedBlocksare empty or not. If they are empty, it's regenerated rather than just being returned as is which results in data loss.I've also reverted the change that was made in #75233, because that wasn't the correct way to solve this problem. That hid the true underlying problem.
Testing Instructions
settings->writingTesting Instructions for Keyboard
N/A
Screenshots or screencast
Before
RevisionBug.mp4
After
blocksBugFix.mp4
Thank you @youknowriad for pointing me in the right direction for this investigation.