Block API: Allow for internal, non-duplicable block attributes

[stacimc]

What problem does this address?

Blocks cannot use attributes to store information that is unique internal to the block instance but also persisted across page loads. Here's an illustrative example:

I'm working on the Jetpack Pay with PayPal block. It contains a productId attribute which uniquely identifies the actual product record referenced by the block. When a new block is inserted this attribute will be undefined; we hit the API to create a new product, and store the returned id in this attribute.

When the block is duplicated, I'd like to create a new product record with identical fields (title/price/etc). But because the productId is cloned along with all the other attributes, both blocks will point to the same resource. It's possible to keep track of the block's unique clientId and reset the product when this value changes — but while this detects block duplication, it also changes every time the post loads, and I only want to reset the product on duplication.

What is your proposed solution?

A couple of options as a starting point for discussion:

1. Add support for unique internal attributes, which do not get copied during block duplication.
2. Allow blocks to listen for/handle the duplication event.

[Tropicalista]

I have similar problem.

Here's my issue: #29694

I'm creating a form builder. I need a way to store reference to form id in database. When a block is made reusable it stores the reference, but if a user convert to normal block I need a way to detach the old reference in DB and create a new one.

I've just discovered that there's a new __experimentalIsEditingReusableBlock that probably can suite for my use case.

[talldan]

Also related is the difficulty in declaring and using unique HTML ids within a block - #17246

[ntsekouras]

I've been thinking about this and a possible solution I had in mind to try out involves these:

1. Set the unique attribute value on load only if it doesn't exist and mark this change as persistent or not depending on your needs (add undo level). Something like this: https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/query/edit/index.js#L94
2. Use the __experimentalRole attribute to something like id or unique etc.., and then use the existing __experimentalGetBlockAttributesNamesByRole util to get them.
3. Handle them in the appropriate places, like in the duplicate function and where is needed.

All the above are using experimental APIs though which were introduced here: #30469. I guess this could be okay though as the new functionality should also be experimental for start.

[talldan]

This could also be relevant for the widget editors, which store an internal widgetId as an attribute. (cc @kevin940726 @noisysocks).

[gziolo]

This could also be relevant for the widget editors, which store an internal widgetId as an attribute. (cc @kevin940726 @noisysocks).

The related PR #28379. We discussed the potential new APIs for block attributes with @spacedmonkey on Twitter. Related thread:

https://twitter.com/thespacedmonkey/status/1435530281595846663

Well this is a question. I think they could be two kind of attribute. Internal and private/sensitive. Internal attributes, could used for data that is not sensitive but not design to be public. Private / sensitive, like api keys, personal information (like email) or passwords.

The conclusion in the discussion is that "internal" attribute is more something stored in the memory during the block editor's runtime and __internalWidgetId from the linked PR would be a good example. Here, @stacimc desribes the use case where an attribute (productId) should be persisted between the page edits but doesn't necessarily need to be secret. So I have a feeling that it's something between the shared definition of internal and private/sensitive 😄 Well, unless we introduce three types:

• internal - in memory only, not persisted in HTML, not shared when duplicating
• private - persisted in the HTML, not shared when duplicating
• secret - persisted in secure location, not shared when duplicating