How does interactive block rendering work?

[johnhooks]

I wanted the discussion started in WordPress/block-interactivity-experiments#136 (comment) to continue. I find it really interesting. I'm new to WordPress and it seems like a real struggle that a JS environment isn't available on the server. I read through the Gutenberg issue @michalczaplinski linked.

#38224

Is interactivity experiments an evolution of how to solve this issue? Render on the server in PHP and add declarative inactivity through the markup.

Is the technique of using the block render function in PHP stable in WordPress? (Sorry for any questions that may seem obvious)

[michalczaplinski]

it seems like a real struggle that a JS environment isn't available on the server

Yup, that is one of the major constraints of the system that we are developing in this repo 🙂 .

Is interactivity experiments an evolution of how to solve this issue?

Sort of. It doesn't address the problem of the duplication of the markup across the edit and render_callback (Challange 1.) but it IS designed to help with Challange 2. (Make it easier to create interactive blocks (block hydration)).

Render on the server in PHP and add declarative inactivity through the markup.

That's exactly the idea!

Is the technique of using the block render function in PHP stable in WordPress? (Sorry for any questions that may seem obvious)

I'm not 100% sure if this is what you mean, but the render_block function has been included in WordPress 5.0 a few years ago, so it can definitely be considered "stable".

[johnhooks]

I'm not 100% sure if this is what you mean, but the render_block function has been included in WordPress 5.0 a few years ago, so it can definitely be considered "stable".

@michalczaplinski that is what I meant. I had seen a note in the Block Handbook discouraging SSR rendering of blocks.

Server-side render is meant as a fallback; client-side rendering in JavaScript is always preferred (client rendering is faster and allows better editor manipulation).

https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/creating-dynamic-blocks/

I may have misconstrued that initially, as on a second read it specifies it's referring to inside the editor. Is rendering of blocks currently done outside the editor in any context of WordPress?

[michalczaplinski]

Server-side render is meant as a fallback; client-side rendering in JavaScript is always preferred (client rendering is faster and allows better editor manipulation).

developer.wordpress.org/block-editor/how-to-guides/block-tutorial/creating-dynamic-blocks

I may have misconstrued that initially, as on a second read it specifies it's referring to inside the editor. Is rendering of blocks currently done outside the editor in any context of WordPress?

Exactly! This refers to rendering inside of the block editor. This repo is about rendering on the frontend of the site (the visitor-facing content).

[johnhooks]

Does this currently do any rerendering of components though calls to the server, similar to LiveWire in Laravel?

[michalczaplinski]

Nope! But it can do something somewhat similar that is conceptually similar to React Server Components 🙂

It can receive the updated HTML from the server, and instead of doing a full page reload, it can re-render only the bits of the old page that are different on the "new" page. Take a look at this experiment to understand a bit better what I mean: #49305

It's also possible that we'll work on ways to not send the HTML for the full page when the client-side navigations are enabled and only send a diff in a way similar to LiveWire. But that's just a very distant possibility at the moment.

[johnhooks]

Thank you for the clarification