Over the weekend, David Gwyer announced a custom server-side render component for block plugins. The co-founder of WPGO Plugins primarily built his component to speed up the rendering process for dynamic blocks within his own plugins. However, he has now released this component for other block developers in the WordPress community.

Most blocks are static. Their output remains the same and has no need to change. However, some blocks are dynamic. Their output needs to change based on a variety of reasons, such as the context they are output in or other changes within the WordPress system. For example, the core Latest Posts block is dynamic because the posts that it displays change as new posts are written. If they were output as a static block, the end-user would need to update the block each time a new post was written. Therefore, dynamic blocks come in handy because they are rendered by the server in the editor and on the front end.

The problem with rendering from the server is that it can be slow, especially if the user is making several successive options changes to a particular block. With each change, the block must be re-rendered. The core experience with dynamic blocks has not been ideal.

Gwyer’s new component is available via GitHub. The project has little code, and its primary JavaScript file weighs in at just over 4kb (uncompressed). It introduces a new component, which works similarly to WordPress’s existing . Block developers should have little trouble switching to this version for a quick test.

He is currently using his component within the Flexible FAQs plugin. After running through a few tests, the plugin’s dynamic blocks feel much more responsive, almost to the point where there is little difference between it and a JavaScript-rendered static block.

Example of how the <ServerSideRenderX /> component works when updating a block.” class=”wp-image-103253″><figcaption>Live rendering when updating a dynamic block’s options in the editor.</figcaption></figure> <p>He also has plans to use it within his <a href=Simple Sitemap plugin and any other future dynamic blocks. That is assuming WordPress does not improve its server-side rendering component in the meantime.

How the Component Works

Gwyer’s component is a fork of the core component, which he says works well aside from the point where it transitions between render states. His custom component seeks to rectify that issue. “The main additions were a new piece of state to track the previous block content to use as placeholder content, and a new component prop to handle the spinner location,” he said.

He laid out how both the core and his component works with the core component rendering as follows:

  1. Render block.
  2. Block attribute(s) updated.
  3. Replace entire block content with spinner.
  4. Render new block content.

His new component makes an important change that creates at least a perceived visual speed increase:

  1. Render block.
  2. Block attribute(s) updated.
  3. Replace entire block content with placeholder content (current/previous content), plus spinner in the top right corner.
  4. Render new block content.

“Because the block content is essentially left unaltered until the new content is ready to be rendered it looks a lot faster as well as smoother,” said Gwyer.

The real question is whether this fork should make its way into the Gutenberg project and eventually merged into WordPress. WordPress developer Ben Gillbanks thinks so and has created a new GitHub ticket with the request.

“I’d like to see it added to Gutenberg as it’s a much better rendering experience for dynamic blocks,” said Gwyer. “I’d happily liaise with the team if they’re are interested in including it in core.”