Repository navigation
Capture/apply block-remove suggestions - #77968
adamsilverstein wants to merge 7 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: +750 B (+0.01%) Total Size: 7.52 MB 📦 View Changed
|
|
Flaky tests detected in 008eb74. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25406047322
|
f6c4e6f to
b9092d0
Compare
008eb74 to
c2896ac
Compare
b9092d0 to
7259d48
Compare
c2896ac to
838d2f3
Compare
7259d48 to
e6968d3
Compare
838d2f3 to
42d77e8
Compare
e6968d3 to
a9ad146
Compare
42d77e8 to
83baf50
Compare
a9ad146 to
0ba06e2
Compare
83baf50 to
6150237
Compare
In Suggest mode a removeBlock dispatch must not actually remove the
block — the apply-and-tag flow re-inserts the subtree at its previous
position and stamps a metadata.suggestion = { type: 'pending-remove' }
marker on the re-inserted top-level block. Auto-save (in a follow-up)
reads the marker and persists it as a block-remove operation; Apply
later runs the real removeBlock, Reject just clears the marker.
The interceptor maintains a per-tick tree snapshot so the previous
position (parent + index) and full subtree are recoverable after the
block has already been dropped from the live tree. Re-insertion is
limited to top-level removed blocks — descendants of another removed
block ride along with their parent, and re-inserting them separately
would duplicate them.
`metadata.suggestion` is added to SYSTEM_METADATA_KEYS so subsequent
fires fold the marker into the snapshot rather than reverting it,
and so it never leaks into the user-pending overlay.
Refs #77434.
Wires the pending-remove marker through to the existing auto-save and apply/reject paths so a removal in Suggest mode produces a real note comment that the post author can Apply or Reject. - overlay-context: adds a SET_STRUCTURAL_OP reducer action and a setStructuralOp helper. Structural ops live alongside attribute-set diffs in the overlay entry; the interceptor calls setStructuralOp immediately after tagging the live block. - auto-save: operationsForEntry merges any structural op with the existing attribute-set diff before fingerprinting. The structural op leads so a Reject reverts to the pre-suggestion shape. - provider: applySuggestion branches on findStructuralOp; for block- remove it clears the marker, drops the overlay, and dispatches removeBlock — three bypass-guarded dispatches so the interceptor doesn't fight the apply. rejectSuggestion accepts an optional clientId/payload and clears the marker for structural rejects so the dimmed/struck visual treatment goes away. - collab-sidebar suggestion-actions: passes clientId + payload to rejectSuggestion so the marker-clear path runs. Refs #77434.
…ging When another client accepts a pending-remove suggestion, the marker-clear plus the removeBlock arrive on this client through sync, typically batched into a single block-editor update. The interceptor's removal-detection branch was treating the disappearance as a fresh user delete — re-inserting the block and tagging it pending-remove again, which then bounced back through sync and undid the apply on the accepting client a moment after they clicked. Recognize the apply landing by checking the previous-tick tree snapshot for `metadata.suggestion.type === 'pending-remove'` on the disappearing block. When the marker is still there, drop the snapshot entry and let the removal stand. The PRUNE_ORPHANS effect in overlay-context cleans up the matching overlay entry on the next render.
0ba06e2 to
4ef811a
Compare
6150237 to
9fb6c86
Compare
… suggest-mode-6a-remove-mechanism
|
Superseded by the fresh-stack restructure of Suggest mode (#73411). The feature has been re-sliced from this 16-deep stack onto current
The whole feature now sits behind a Suggestion Mode experiment (Settings → Experiments → Collaboration). Closing in favour of the new stack — details: #73411 (comment) |
What
Adds the data-layer mechanism for block-remove suggestions (#77434, task 6a). In Suggest mode a removeBlock dispatch no longer drops the block — the apply-and-tag flow re-inserts the subtree at its previous position and tags it with
metadata.suggestion = { type: 'pending-remove' }. Auto-save persists the marker as ablock-removeoperation; Apply later runs the real removeBlock; Reject just clears the marker.This PR ships the mechanism only — there is no visual treatment yet. Strikethrough/dim styling, summary, and diff variants land in the next PR (#77970).
Two commits
operationsForEntryemits the structural op, provider'sapplySuggestionbranches onfindStructuralOpand dispatchesremoveBlock,rejectSuggestionclears the marker.Testing
Stack
Refs #77434, #73411.