Possible unintended interaction with duplicating a query loop block.

[albanyacademy]

Description

When duplicating a query loop block, a query ID is also duplicated along with it.

This means that on the page, things like pagination or taxonomy filtering gets applied to all of the duplicated blocks.

The average (re: lazy) user will likely want to duplicate a block they've spent time carefully crafting, so this interaction may not be what they have in mind when they do this. There's also zero feedback to the user that this linked effect is taking place, they can only observe it on the front end.

This behaviour is also true when copying and pasting, or when converting a query block stored as a Reusable block back into a regular block.

There's definitely a use case for having multiple query blocks respond to the same query, though for the most part I would suggest that this shouldn't be the default behaviour - that should be an explicit user action, and they should be allowed to specify which Query Blocks are linked (i.e. share the same query).

Something like this would address it:

At query-block/edit/query-content.js

useEffect( () => {
  if ( ! Number.isFinite( queryId ) || instanceId !== queryId ) {
          __unstableMarkNextChangeAsNotPersistent();
	  setAttributes( { queryId: instanceId } );
  }
}, [ queryId, instanceId ] );

As an aside, outside of the query block afaik there's not really any support for the concept of a "unique" attribute either - such as auto-generating an element ID in a custom block - within the context of editing a page. It would be good to have this set to an attribute property, ala:
"blockId": { "type":"string", "isUnique": true }

I'm not sure how much of a valid use case there is with the builtin blocks beyond query block for such a feature, and for customizing blocks it's easy enough to add it yourself, but food for thought.

Step-by-step reproduction instructions

• Add a query block
• Duplicate, copy and paste, or convert to a reusable block, duplicate and convert the duplicate back to normal blocks

observe on the front end that pagination is applied to all query blocks added via the above method.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[albanyacademy]

The full-site editor would likely prove using instanceId as unreliable for requiring a truly unique queryId. Perhaps prefixing it based on edit context (edit-post vs edit-site) could help.

[ndiego]

This issue was reviewed in today's Editor Bug Scrub. We were able to replicate and also confirmed that manually changing the queryId allows pagination to work independently on the copy and the original.

[ntsekouras]

Thanks for the issue @albanyacademy!

As an aside, outside of the query block afaik there's not really any support for the concept of a "unique" attribute either - such as auto-generating an element ID in a custom block - within the context of editing a page. It would be good to have this set to an attribute property, ala:
"blockId": { "type":"string", "isUnique": true }

I'm not sure how much of a valid use case there is with the builtin blocks beyond query block for such a feature, and for customizing blocks it's easy enough to add it yourself, but food for thought.

There is an issue about this here with lots of discussions and explorations, but haven't made it to the finish line. We'd have to revisit this.

[albanyacademy]

Just getting back to this, __experimentalRole:"internal" is a great idea.

[skorasaurus]

Thanks for reporting and your thorough work; there's additional context and work on this at #55823 so I'm closing this issue to consolidate reports and efforts.