Gutenberg: Filter Image Block attributes (or markup) when image is selected in Media Library

[danielbachhuber]

One of the plugins I work on, Tasty Pins, offers the ability to add "Pinterest Text" to an image (related #8473).

In the Classic Editor, the user can edit their Pinterest Text in the Media Library:

When the image is inserted into the post, the Pinterest Text is included as a data-pinterest-description data attribute:

Even though all of this interaction is clientside, a plugin can modify the <img> image markup sent to the editor via the image_send_to_editor filter (ref):

/**
 * Append Pinterest Text to markup sent to editor
 *
 * @param string $html The image HTML markup to send.
 * @param int    $id   The attachment id.
 * @return string
 */
public static function filter_image_send_to_editor( $html, $id ) {
    if ( ! empty( $_POST['props']['tp_pinterest_text'] ) ) {
        $html = str_replace( '<img ', '<img data-pin-description="' . esc_attr( wp_unslash( $_POST['props']['tp_pinterest_text'] ) ) . '" ', $html );
    }
    if ( ! empty( $_POST['props']['tp_pinterest_nopin'] ) ) {
        $html = str_replace( '<img ', '<img data-pin-nopin="true" ', $html );
    }
    return $html;
}

What's the best way to achieve equivalent behavior in Gutenberg?

One idea, albeit not necessarily a good one, is to make onSelectImage filterable:

https://github.com/WordPress/gutenberg/blob/abb14b109141964e3768a7667a29252f5a47b9a7/core-blocks/image/edit.js#L113-L128

onSelectImage seems to be common across Image, Cover Image, and Gallery Blocks. Other approaches?

[macemmek]

It's a similar problem I've met: I'd like to output the image description field on the front-end.

[joemcgill]

Per @mtias in Slack, we should look at handling this server side by adding a render_callback to the image block (and other blocks requiring similar ability to filter the rendered markup.

[getsource]

I'm a bit concerned about a front-end approach, since, if I'm understanding correctly, it'd move code written to be run once on image insert in the backend, to being run for every image every time a page is loaded on the frontend.

In case it helps for context in a decision in either direction, here's the usage in the repo:
Plugins: https://wpdirectory.net/search/01CV8EY1AEVZQTNKVNTNECKQ4Y
Themes: https://wpdirectory.net/search/01CV8EZMQTWEC2R26FGANCXJNF

[mtias]

Extending to add attributes on save should happen as block extension, with the caveat that it modifies source so it couples the source with the plugin (as already happens). The server extension keeps the markup source clean and flexible. It will always be a matter of tradeoffs.

Pushing this to follow up milestones in case there are tangible proposals for improvements.

[danielbachhuber]

Extending to add attributes on save should happen as block extension, with the caveat that it modifies source so it couples the source with the plugin (as already happens). The server extension keeps the markup source clean and flexible. It will always be a matter of tradeoffs.

@mtias This isn't quite a correct assessment of the issue. For this particular issue, we need a way of detecting _when a new Image Block_ is inserted in order to only apply the behavior at that point. In Slack, you had mentioned something about comparing an empty id value in old props and a full id value in new props, which I think would be sufficient. Can you point me to documentation on how to access old props?