Static vs Dynamic blocks

[gziolo]

The Block Editor Handbook lists on the Glossary page two types of blocks:

Static block
A type of block where the content of which is known at the time of saving a post. A static block will be saved with HTML markup directly in post content.

Dynamic block
A type of block where the content of which may change and cannot be determined at the time of saving a post, instead calculated any time the post is shown on the front of a site. These blocks may save fallback content or no content at all in their JavaScript implementation, instead deferring to a PHP block implementation for runtime rendering.

Challenges

In practice, we see many signals where people decide to stop using the static block where it would fit perfectly fine because they don't want to live in fear of potential validation errors as explained by Joni Halabi in the WPCampus 2021 talk:

You write a brand new custom Gutenberg block. Sometime later, you realize that you need to change your block's markup to either fix a bug or add a new feature. Suddenly, the editor crashes your block. Validation error! You can fix this with a deprecation object. Or… could there be a better way?

You can learn more about the issue by watching the session at https://2021.wpcampus.org/schedule/dynamic-blocks-ftw-customize-gutenberg-without-living-in-fear-of-validation-errors/demand

A recent comment from @landwire left under the discussion about rendering dynamic blocks on the front end in JavaScript instead of PHP in #14446 (comment) sets the same tone:

I really don't care whether a block is rendered with JS/React or PHP or whatever, but what I care about is that the block's markup is written in a well structured templating language. The blocks data is passed to the template and the template consumes it.

Therefore until now I mainly use ACF to build my blocks and PHP/Twig to render them. This gives me the freedom to override a block's markup in every child theme I create and output a totally different design based on the same data. Being able to override a block's markup easily and dynamically (without the need of re-saving it) is crucial for my development workflow with ever changing designs for the same data.

Dynamic blocks have also trade-offs but they are less obvious like:

• PHP callback needs to be executed any time the block is about to be rendered.
• When the dynamic block gets removed from the site, there is no HTML that can be printed as a fallback on the frontend.

Possible solutions

There is a related issue #21703 that aims to improve the developer experience around block validation. It was opened by @mtias over 1.5 years ago but it didn't get enough attention so far. What else can we do to improve the experience?

[thatdevgirl]

I talk a lot in my talk, but I wanted to add that, while the example in my talk is really simple, we've had some bigger issues with more complex custom blocks. We wrote a few custom blocks that:

• Contain attributes that are dependent on other attributes
• Add classes to the front-end markup based on attribute values
• Have changed a lot because of changing business requirements, user requests, etc.

There have been times when we have needed to change a more complex block and then write the deprecation object, only to find that our deprecation object does not cover some edge case of markup that we did not think of.

One change to the validation that would help us would be a way to ignore changes in class names in the markup. That's the bit that I think trips us up the most.

[mtias]

The distinction itself is also a bit spurious — some of the most prominent "static" blocks have dynamic behaviours. For example, the image block gets its srcset applied at render time; block supports are also generated at render time for seemingly static blocks. The question is whether the block has an intrinsic semantic representation that is worth serializing canonically in part or in whole.

[widoz]

For what that matter I've found always more convenient to go with dynamic block even for simple things like Headings or Paragraphs. The main reason is the flexibility. A dynamic block which render the markup entirely server side allow me to have more control over the final output. Sometimes I want to change / remove or add new classes, change a tag or allow actions before within and after a block. Sometimes I want to render or not a portion of an inner markup based on a condition where the value depends on a filter.

The downside of it is that, I have to replicate and keep in sync the markup rendered in the Editor and the one rendered Server Side since most of the time does not make sense to call the server to change a style like a border or a left padding for instance.

Ok now we have the WP_HTML_Tag_Processor to handle the attributes and in future it could even handle other parts of the markup but the amount of code necessary to do that would be huge.

Imo, in my project I always avoided static blocks and even if I have to keep in sync both solutions at the end it was worth the effort because of the flexibility I obtained int integrating third party plugins and/or adapt how other plugins might consume / expose certain features.