Review of gatsbywpgutenberg

This is a package which allows using gutenberg with gatsby. I’ve had a look at it to see if we can extract some ideas and put them in frontity. Here are my impressions:


This package allows you to create blocks in the WP block editor and then use them in the gatsby app or write your own block “implementations” in react. In that sense it’s quite similar to html2react.

  • It’s not that easy to set up (as far as I can see it requires requires 3 different wp plugins: wp-gatsby, wp-graphql & wp-graphql-gutenberg and then installing 2 gatsby plugins on the frontend.

  • The way that it works is very similar to html2react. Instead of writing a selector like with html2react, you write a graphql query which will return you a particular block. You can then modify the block and return new react components or just pass the content to dangerouslySetInnerHTML (again, like in html2react)

  • A difference is that because it uses a WP plugin, it returns more a bit more data about a block than just the HTML content. E.g. it gives you the name of the Gutenberg block that you are using, so that you don’t have to match the nodes on class names. This is how they implemented the functionality that gives you the name of the block on hover (see the tweet). The data also includes e.g. the attributes and metadate of a particular block that you can set inside of the block editor so that you can modify them in your custom implementation, like:

  • The preview functionality required installing another plugin into WP and setting it up or using the Gatsby Cloud :slight_smile:

Hey, great review @mmczaplinski.

A while ago Jonny Harris tried to do a similar plugin but it had to add manual support for each block, because some of the blocks didn’t expose the attribute sourcing in PHP, only in JavaScript:

I wonder if that has changed now because there’s been some progress recently in this matter:

So I’d love to know how “hacky” this plugin is. If the approach it’s using is stable or if it’s going to break easily or if it only works for built-in blocks.

Apart from that, I like the idea of doing the parsing on the WP server, so we can get rid of that work on the client. And I’d love to have more info on our nodes, like or node.block.attributes.

In terms of their approach vs our approach, I think the important aspects for us are:

  • Extensibility
  • Performance

Extensibility comes first, because it can affect performance, although performance is still quite important.

For extensibility, we cannot asume that all the code that is going to be applied to the HTML/blocks will be controlled by the same person. For example: maybe multiple packages need to modify the same block.

In terms of performance, if we would have block names, maybe we could use object indexes instead of test functions to gain some performance. Although I don’t know how much gain would be that, to be honest.

1 Like

I will unassign myself for the time being. We can do more research in the future when this comes up again.