The team is now working on the WordPress Interactivity API. This unblocks the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.
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:
Description
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:
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 node.block.name 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
mmczaplinski5
I will unassign myself for the time being. We can do more research in the future when this comes up again.