Open Conversation - What if Static Block didn't exists....

[tresorama]

Disclaimer

I followed the Gutenberg repo only recently, so I can only imagine the amount of work done on this project.
This issue wants to be constructive and informative for "newcomers" (like me) that don't know much about the Design of the Gutenberg system and want to understand some "why".

I imagine that static block could be a "sensible" topic because it is one of the main features of Gutenberg, and I imagine the conservative attitude that can emerge.

Maybe this issue is unnecessary because already been answered.
Any resources linked here are helpful.

---

Question

Static block is the main thing that I don't see clearly why they are there.

Q1 - If today static blocks are not available, what do you miss from them?

This is the most important of questions.

In an hypothesis that static blocks are removed from the system, and you can't use them anymore, meaning that:

• Wp Core Blocks are converted and available as dynamic blocks, so the UX is the same
• Custom block you code must be dynamic block

By "dynamic" I mean one of these "methods" of coding :

1. Using "render_callback" property that points to a PHP template, so no React side.
   This is how ACF Custom Blocks are right now, meaning that you can't input text directly on the canvas, and use the sidebar instead.
2. Using a React Component for "Edit" property, but don't use React Component for "Save" property.
   The best UX for final user for input value because you have React, but saving JSON in DB.

What you will miss from static block ?
What you cannot do any more now that static blocks are gone?

---

Q2 - Why save HTML in the database instead of a tabular format (JSON-like)?

First consideration.

Matt (in 2021) said that

...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
link here

• Why is "worth serializing an intrinsic semantic representation" (aka HTML) of a block in the database?
• As opposed to saving a tabular format in the DB (like JSON) and producing the HTML part on demand in the server? We have a runtime (the PHP server) that we use any way to fetch things, so why don't use it also for rendering to HTML? When fetching with REST API we can skip the render phase (that I assume is in place at the time of writing).
• If we want to be able to show a block HTML markup even if that block is not registered (block has updates, block is no longer available, ...) why don't saving both raw JSON data and also the HTML rendered version?

Second consideration.

When Wordpress gets the "post_content" string from DB and needs to pass the Block tree to the Editor frontend, it needs to parse from HTML-like code to JSON.

I think that this is why the HTML API is under construction.
If it's the case, the amount of work to parse every HTML and all possible HTML attributes from a raw string is not worth creating if we can use a JSON format in the first place.
JSON strings are already structured, so is extremely easier to work with them.

Also, JSX (for React) is compiled to JSON format before using React.createElement, so we can use it for "free".
I'm not sure if we can get the JSON format from React in browser runtime or only on Node/Webpack compilation runtime (?).

Using JSON format as source of truth help also when fetching over REST API, because no need to convert HTML to JSON.

HTML like

<section data-attribute-1="hello" data-attribute="56">
  <article>....</article>
</section>

vs JSON

{
  "tag" : "section"
  "attributes": [
    "data-attribute-1": "hello",
    "data-attribute-2": "56",
  ],
  "children": [
    {
      "tag" : "article",
      "attributes": [],
      "children": [],
    }
  ],
}

But maybe I've misunderstood what the HTML API is for.

---

Considerations - CONS of static block vs dynamic block

Stale Markup

With Static block, when markup of the block changes in code, maybe because you updated it, the user needs to re-open the editor and re-save the post in the Editor screen in order to save the updated value to the DB, because "Save" React Component need to re-run to create the new HTML outcome that is saved in the "post_content" value in DB.

In custom block this happens a lot.

Especially when you perform a visual redesign of the website, likely you need to update the markup.
In that scenario, you must re-open every page where the block it's used.
Ideally, if you iterate between Figma and code, and data (for attributes values) stay the same, it seems unnecessary and tedious to have to re open the editor.

---

What are other ADVANTAGES of a static block over dynamic block ?

No idea, please share your toughs.

What are other DISADVANTAGES of a static block over dynamic block ?

No idea, please share your toughs.

---