How post_meta is handled on multiple instances of the same block?

[diegoliv]

Issue Overview

Right now, when you set an attribute as source: 'meta', Gutenberg stores the meta on the database properly:

attributes: {
    fontSize: {
        type: 'number',
	default: 10,
        source: 'meta',
        meta: 'font_size',
    },
},

And then we declare the existence of this meta like this, so the REST API will know how to handle the meta:

function my_blocks_meta_init(){
    register_meta('post', 'font_size', array(
        'show_in_rest' => true,
        'type' => 'integer',
    ));
}
add_action('init', 'my_blocks_meta_init');

But, when you add multiple instances of the same block, all of the instances will pull data from the same post meta. This means that, if you change the attribute on one block, it will change on all blocks. It makes sense when your post meta is something that should be set globally for the post. But what if I want to store some post meta specifically for your block?

A real example: I'm creating a block that has some styles attributes. If I have two of these blocks, fontSize, for example, should be a post meta that returns an array with two values, each one for each block. I'm doing this because I'm trying to use wp_add_inline_style to generate styles for each instance of my block and add it to the head of the page.

Steps to Reproduce (for bugs)

1. Create a custom block with an attribute set as post meta.
2. Create multiple instances of this block on a post / page.
3. Change the value of this attribute on one instance.
4. What the other instances change their values as well.

Expected Behavior

While the current behavior makes sense, we should also allow to store post meta per block, and not only per post. There might be a better approach for this, rather than using post meta, but it makes sense to have something like this if we want more flexibility with block attributes. I tried using the render_callback for the register_block_type php method, and generate the whole markup with PHP. You can use wp_add_inline_style there, but it won't be printed on the head of the page. It will be printed in the body, which works but it is not valid html.

Screenshots / Video

https://drive.google.com/file/d/1yeMU1yRWrvsTYSYCBKjhE7cWh3m2PmIa/view?usp=sharing

[aduth]

Question: Why were you inclined to use meta for font size, and not the default comment attributes, which are just as well supported on the server for varying inline style?

To me, one of the advantages of meta as an attribute source is that it applies globally to all instances of the block.

[aduth]

Discussed in #core-editor weekly triage: https://wordpress.slack.com/archives/C02QB2JS7/p1522944073000951

[diegoliv]

@aduth yes, you're right. After more research, I found a better solution for this, and keeping the current behavior for post meta makes sense. #5705 is a better fit to solve this issue. I think you can close this one if you want.

[abder]

We need to create block meta that could be registered with a function named for example: register_block_meta

[aduth]

@DOUARA Could you please create a separate issue which explains your use-case and the proposed benefit of what you're requesting?

[abder]

@aduth With attributes stored only in the comment delimiter, css could be added inline only, and when we have style rules with media queries and pseudo selectors we will be forced to add css with style tag on the body which is a bad practice.