Draft: Use IAPI for processing attributes.

[cbravobernal]

I'm just experimenting with the idea of reusing the current Interactivity API approach for block bindings on the render.

I'm listing pros and cons as they come to my mind.

Pros

• Reuse attribute server side rendering done in process directives function.
• Ability to make any attribute compatible with bindings by just adding a data-wp-bind-attribute="custom-source". Easy and already known and used developer experience.
• Block json updates not needed. Compatible with just HTML, not only blocks.
• Remove all manual processing the code presents now.

Cons

• Making bound blocks interactive by default when not needed.
• Extra markup on server (all those data-s).
• Extra not needed store.
• Still need an innerHTML directive. But as far as I know, the iAPI will need it in a future too.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[cbravobernal]

We would need a data-wp-dangerousInnerHTML here.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[gziolo]

Nice experiment. I think reusing the exact mechanism as the directives processor is helpful for prototyping. The most limiting factor is that after the processing is finished on the server, the directive should be fully removed from HTML. In particular, the need to make the block annotated as interactive is concerning to me. However, we could definitely add a cleanup step that removes all such directives in one go before sending the full page HTML to the browser.

[cbravobernal]

Nice experiment. I think reusing the exact mechanism as the directives processor is helpful for prototyping. The most limiting factor is that after the processing is finished on the server, the directive should be fully removed from HTML. In particular, the need to make the block annotated as interactive is concerning to me. However, we could definitely add a cleanup step that removes all such directives in one go before sending the full page HTML to the browser.

Agree on the cleaning step, but, in that case, it would diverge the way that maybe is better to go back to the original implementation, being different from the Interactivity one.

In a future, both processing may depend on a more "Core" approach.