[Blocks] Development and debugging tooling

[vladolaru]

Intro

A block configuration and, more so, a block hierarchy can become complex, very fast, especially with complex themes. Even the blocks introduced by only the blog component are quite hard to grasp in behavior.

Since the blocks are fundamentally about visual blocks on the frontend and how we can better make them reusable and have a predictable (complex) behavior, I say we rely on this and introduce a frontend development mode or how @georgeolaru suggested, visual blocks guide.

Current State of Affairs

Currently, we have a blocks debug mode controlled by the PIXELGRADE_BLOCK_DEBUG constant and the pixelgrade_is_block_debug() function. We output a series of heavy duty HTML comments that help one get a grasp of the steps taken in rendering a block and it's child blocks. It is helpful but only so far. It is quite clumsy, it offers only a partial understanding of the block tree, and I believe we can do much better.

Proposal

An interactive frontend overlay over each block (and sub-block) on a page. Imagine a series of borders and labels that highlight each block, it's ID, and various other details about that block depending on the block type (like what template part has a TemplatePart block has selected to use). WYSIBFR - What You See Is Blocks Final Render :)

We could take this one step further and provide a (side) panel with details about the selected block and maybe the opportunity to play with its configuration (it's just an array so any code editor with PHP syntax highlighting would do - WordPress has it in core now).

Such an interface would open up the way towards defining and configuring the blocks in the frontend, at the end producing a copy&paste blocks configuration. We can also take advantage of the fact that blocks are registered ahead of their display and thus take advantage of the default blocks provided by various components or other entities. Think of wanting to extend a block and getting a select with all the blocks suitable for extension; or constructing the list of child blocks and choosing them from a list.

This visual block "builder" would reduce development time, reduce bugs, and encourage more complex block setups due to more (safer) experimentation.

This whole behavior would be initially tied to a constant, maybe the same PIXELGRADE_BLOCK_DEBUG constant. We could also look into having an admin bar trigger button for easier switching.

Next Steps

1. Bounce ideas around and settle on a clear goal, if any. In case we come to the conclusion that we don't need such a thing, you can ignore the following steps :)
2. Detail each of the needed features and estimate the needed effort;
3. Prioritize the features by their potential impact;
4. Do the work and make it happen.

---

@pixelgrade/everybody I encourage developers (especially frontend devs) and non-developers to pitch-in and provide their valuable input. It is very much needed and appreciated. Thank you.

[georgeolaru]

@vladolaru that could be a great way to speed-up theme development and to encourage non-developers to contribute more to this project.

Not sure if it relates, but I remember how eye-opening it was when I found out the Visual Hook Guide for WooCommerce. If this is something similar, but applied to blocks, I would love to see and play with an early working prototype.

Is there anything specific that I could help at this stage?

[vladolaru]

Exactly @georgeolaru. A visual block guide but better in the sense that we could provide a two-way link to the actual block config and let you play with it via the side-panel. But initially, it will only be a visual blocks guide.

Glad to hear you dig it :)

As for helping, I am hoping that @razwan would jump on board and make this happen with me. He is at the business end of the blocks system so it more attuned to the blockages and difficulties he encountered in using it.

So, @razwan I am very keen on hearing you perspective regarding my proposal. Thanks.