Note: This post is a little different than what we normally post here; it contains details of the inner workings of Gutenberg. The information is not entirely relevant for most WordPress users, but if you’re creating your own blocks or just interested in what goes into it, read on.
In part one of this post, we looked at the two types of blocks and the benefits of using dynamic blocks, even for what you would not typically consider dynamic content. If you haven’t read that post, I would recommend doing that first. In this post, I’ll talk about the challenges of using dynamic blocks and how you should choose when it comes down to brass tacks.
Challenges
Different Languages
Static blocks exist entirely within React-land. While dynamic blocks use React for the edit method, the render method must be written in PHP. Now, rewriting some view logic and echoing some HTML in the first place is not too hard, but the challenges arise as you make changes and fix bugs in your markup. It requires a lot of care to make sure those changes are transcribed to the other side. Any testing, utility functions or other features will have to be ported back and forth as well.
No Nested Blocks
It requires a pretty hacky solution to get nested blocks to work in dynamic blocks. It is possible to turn nested blocks at save time into HTML and assign that string to an attribute on a dynamic block and then have that input output to the screen, but it’s quite brittle and won’t work if any of the inner blocks are also dynamic. Needing nested blocks is one of the strongest cases for using static blocks. The only block in our campus block library that is a static block is one that needs inner content to work.
Performance
We haven’t really seen an issue with this so far, and certainly with static there is still some work being done, but there is more work that the server has to do when a page is rendered full of dynamic blocks versus just the static content.
Longevity
For any dynamic block to work, the plugin registering it needs to be active. If for whatever reason your plugin breaks or gets deactivated, any blocks that it registers will cease to work. In the case of static blocks, because the HTML is saved in the database, there will still be content rendered (it will still give an error when the page is edited). You will likely be missing some styles, but that’s not quite as bad as nothing being there and may be much more helpful if you are coming back to a site after a while and finding some broken plugins and you don’t know exactly what they were supposed to do.
The Dark Unknown of Eternity
Gutenberg is still changing, and it’s likely it will have some changes that might alter the way we see these benefits and challenges of dynamic blocks. Maybe the validation issues we are having go away. Maybe static blocks get some huge speed improvements or other fancy features. It’s arguable that static blocks are the more standard/default way to be, so it would not be surprising if that’s where the improvements go. Choosing dynamic blocks may mean that you find yourself on the other side of that. I hope that we won’t be left holding an HD-DVD player in the end, but we do zig while others zag.
How to Choose (Reprise)
When to choose a dynamic block:
- If you need dynamic content (most recent post, category number counts, etc.)
- You think you will be changing the markup frequently
- You want to include dangerous markup (Iframes, SVG, javascript) as part of the output of your block
- You have a large site and want changes to be instant across the board
When to choose a static block:
- You want nest blocks inside your block
- You hate writing PHP
- You don’t think you will be changing your block very much
- You’re using the block on small sites, so updating all of the pages or fixing validation errors as they occur won’t be too big of a burden
So there you have it! Hopefully you now have a solid grasp of how static and dynamic blocks differ, and why we chose to go all in with dynamic blocks for our campus block library. Certainly some of the decisions we have made are because of the way we use WordPress on our campus and how our resources are allocated. If you are running your own site that you are also building for, some of these decisions might be different.
I’m hopeful that there will be more control given to developers over the block validation process to avoid some of these common validation issues, but for the time being, this is how we do it.