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: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: alecgeatches <alecgeatches@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>

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

Size Change: +252 B (+0.01%)

Total Size: 3.09 MB

_{compressed-size-action}

@youknowriad Thank you for creating a PR for this issue!

I did some local testing, and with the way we currently use block IDs this doesn't solve our problem. I think it could with a way to query internal IDs via store or in the DOM itself.

Here are the two places we use block IDs in awareness:

1. useBlockHighlighting() which directly queries the DOM for a user's selected clientId and draws a border around that block.
2. Similarly, useRenderCursors() finds the block ID in the DOM and then does some calculations to figure out where to draw a user cursor on top of it.

In both cases we have the "real" block ID as an input, and we want to identify the block within the DOM for drawing. Assuming I'm understanding this PR correctly, this approach alone won't work because we're still creating unique block IDs within the DOM when cloning. In "Show Template" mode we still don't know how to locate cloned blocks from their non-cloned IDs.

I have a couple of ideas on how to get closer to what we're hoping for:

1. Have a [data-block-internal-id="..."] within markup for this situation. If we don't find the block by ID, we could also query the internal ID.

2. Or if that's a little too exposed, maybe we could have a store function to translate the block ID. We could use it like:

   const getBlockElementById = ( document, blockId ) => {
       let element = document.querySelector(`[data-block="${blockId}"]`);
   
       if ( !element ) {
           const internalId = select(blockEditorStore).getInternalClientId(blockId);
           element = document.querySelector(`[data-block="${internalId}"]`);
       }
   
       return element;
   };

   This would require a little more code to make the mapping queryable.

Open to other ideas for changing how we approach this from the drawing/plugin side if you have any suggestions.

@alecgeatches Quering the DOM is very fragile, why don't you use the "selection" state in core-data instead?

@alecgeatches, the useBlockElementRef or useBlockElement hooks are probably better suited for your case. They're private APIs at the moment, but we can make them public if there are good use cases outside the core.

@Mamaduka I think for his use-case we shouldn't rely on the internal uids of the block-editor store instead it's better to use the more persistent ones (core-data) which would be more persistent/permanent.

@alecgeatches Quering the DOM is very fragile, why don't you use the "selection" state in core-data instead?

[...] we shouldn't rely on the internal uids of the block-editor store instead it's better to use the more persistent ones (core-data) which would be more persistent/permanent.

Thank you for the quick response! I don't fully understand these comments, but I think I'm missing something on how we can use block IDs once they're cloned, and where core-data comes in. Just so we're on the same page, here are some concrete visual examples of how things usually work:

Selection in RTC-synced blocks

Blocks in real-time collaboration have synced client IDs:

This makes it simple to communicate between clients. Below, the left-side user listens for selection change events from the block editor store and announces to other collaborators "I'm in block a0b60bc3-... at index 4":

This process for collaborators is pretty easy. User 2 knows where the a0b60bc3-... block is, and can locate the coordinates of the block in the local browser and draw the cursor and nametag. This is the main reason we need the DOM at the end, to find the local client areas and calculate where to draw a cursor based on another user's selection data. We can't send position data directly because user 1 and 2 can have different viewport sizes.

Selection in "Show Template" blocks

When user 2 switches into "Show Template" mode, or loads a post with that mode enabled, those block IDs change:

User 2's block ID is now dc35b103-.... User 1 continues to announce "I'm in block a0b60bc3-... at index 4". But now that user 2 is in "Show Template" mode, that block isn't available to find.

Is there a way for user 2 to use that information? How do I take the selection data that user 1 is sending me and know which block they're talking about and where I should draw?

The problem exists in the opposite direction as well - user 2 starts announcing "I'm in block dc35b103-... at index 2". How does user 1 know this corresponds to their local a0b60bc3-... block? Is there a different way to capture selection block IDs?

Thank you! I imagine I'm missing something here.

AFAIK, syncing works at the core-data store level, what we're syncing is the "blocks" property of the entity stored in the core-data store (including the clientUIds of these blocks). We're not syncing the blocks uids that are within the "block-editor" store or any local state that is within block-editor store.

So my feeling is that it makes sense to always sync from the same level: sync also the awareness (selection and all) from the same store (core-data) instead of syncing some data (blocks) from core-data and other (selection) from another state (DOM or block-editor store). This likely leads to ambiguity and issues because there's no guarantee that these match conceptually.

Now, the question is whether we have all the necessary data needed to be synced in "core-data" store and the reality is that I don't really know.

I know we have a "selection" object per entity that represents the cursor position basically within a given entity. I think what we might be missing though is in the case of an entity (think a reusable block) used in two different places, which "instance" of that reusable block has the selection in it. (potentially an information we could "save" in the container's selection object)

I know I'm talking a bit in the abstract here, but I think it's the best way to arrive to the best solution.

If you hope that using two reusable blocks in a block editor will lead to the same clientids used in both positions, this is never going to happen I think because it would be a huge change and at the same time, it won't solve your issues because you won't really know which one of these two reusable blocks is selected when two reusable blocks are used in the editor.

So my feeling is that it makes sense to always sync from the same level: sync also the awareness (selection and all) from the same store (core-data) instead of syncing some data (blocks) from core-data and other (selection) from another state (DOM or block-editor store). This likely leads to ambiguity and issues because there's no guarantee that these match conceptually.

Agreed.

Now, the question is whether we have all the necessary data needed to be synced in "core-data" store and the reality is that I don't really know.

Right, but, starting from the right principle that we should sync at the same level, we can work together to see what can be done in Gutenberg to support third-party collaborative experiences.

I know we have a "selection" object per entity that represents the cursor position basically within a given entity. I think what we might be missing though is in the case of an entity (think a reusable block) used in two different places, which "instance" of that reusable block has the selection in it. (potentially an information we could "save" in the container's selection object)

This is where you lost me. :)

• I know we have block-based selection objects (the selection reducer within block-editor's state tree), but what do you mean with the entities?
• I don't follow where the discussion of reusable blocks came from.

I know we have block-based selection objects (the selection reducer within block-editor's state tree), but what do you mean with the entities?

Each BlockEditorProvider (maybe not all, but maybe it should be for all somehow) has a selection and onChangeSelection props that are used to send the "selection" object to "core-data" store. The main purpose for this has been undo/redo (apply the right selection when undo/redo is triggered) but this can be repurposed maybe to also sync the "selection" of the current user to other peers.

I don't follow where the discussion of reusable blocks came from.

Each reusable block is basically a new BlockEditorProvider so a new useBlockSync that triggers a cloning of ids. So if you use the same reusable block in two places, the editor will be capable to know which block of which instance is selected... (they have different client ids). But we do care about these clientIds being the same outside "block-editor" that way when we "sync" this entity, the uids match.

@mcsf approval? I would like to see if we can remove the block paths introduced in #73737 in a follow-up

Stupid question that I'm sure has been answered somewhere in earlier issues / explorations....

But what is keeping us from just storing the identifier as an actual key in the metadata attribute of blocks? Just in the HTML comment we already strip out whilst rendering the block?

But what is keeping us from just storing the identifier as an actual key in the metadata attribute of blocks? Just in the HTML comment we already strip out whilst rendering the block?

This is a bit unrelated to the current PR IMO. I wish we had a document for it but it's something that has been discussed several times. @mtias reiterated multiple times that it would basically pollute the post content too much I think. But seems like something worth having documented more thoughtfully.

Assuming there's no blockers, I'll be merging this PR soon.

Assuming there's no blockers, I'll be merging this PR soon.

@youknowriad The discussion has been a bit over my head, so I just wanted to double-check that (for the purposes of RTC) we won't have a way to correlate one user's selected block ID with another user's if either is cloned?

If not, would you consider a getInternalClientId() block editor function like the example above or similar, maybe if it the function is locked or something? I was hoping this PR and discussion would give us a foothold to fix our "Show Template" mode, but otherwise I'm not sure where to go from here. Thanks!

The discussion has been a bit over my head, so I just wanted to double-check that (for the purposes of RTC) we won't have a way to correlate one user's selected block ID with another user's if either is cloned?

I think it's possible if you stop relying on DOM and start relying on the "selection" object in core-data for the awareness. If you rely on the rendered block uids, I'm afraid it's not possible. The same block can be present twice and the block editor needs to differentiate between these.

I think it's possible if you stop relying on DOM and start relying on the "selection" object in core-data for the awareness

I can't speak to whether that will solve the collaborative editing problem or not, but for the purpose of keeping track of the selected block when navigating to another entity and back (which is what #73737 does), this will only work if the selection object state is persisted beyond the current screen, which I don't believe is the case? And this PR doesn't solve the clientId inconsistency in the DOM, so we still can't viably substitute the path-based approach in #73737 with clientIds.

I'm probably missing something here 😅 but I don't understand how this will work.

And this PR doesn't solve the clientId inconsistency in the DOM, so we still can't viably substitute the path-based approach in #73737 with clientIds.

I think we can but I'll look at that after this PR is merged.

Block client IDs are not stable within templates because blocks are cloned with randomized UUIDs.

Sorry, if forgot, why do we do this again?

Sorry, if forgot, why do we do this again?

Imagine you have the same pattern in two places in the block editor, you need to know which one of the two the user has selected... for several reasons (insertions, selection indicator..., all the block-editor selectors basically)