What Gutenberg Means for Headless/Decoupled CMS

WordPress is currently changing a lot in terms of how we develop for it. The new “Gutenberg” editor is built using React. React is a very popular framework for building component-based interfaces that encourages us to develop our applications in reusable pieces. This is part of a larger trend in web application development - we are moving from building one large, monolithic app to developing collections of services.

This trend - decoupling different parts of the application from each other - has a lot of benefits. For example, we can decouple the front-end of a WordPress site by replacing the WordPress theme with a React or Vue JS single page web application (SPA) that is deployed on a separate server and connects to the WordPress site via the WordPress REST API, or using WP GraphQL. This way the front-end is more scalable and more joyful to develop and the back-end can be locked down to improve security.

WordPress can do everything. There are many things it shouldn’t do. For example, Jetpack decouples related post suggestions from WordPress - offloading that expensive computation to a technology better suited to the use case - or email, which should always be sent through a separate transactional email provider such as Mailgun or SendGrid. These services - Algolia for search or transactional email services - fill a growing market need. As web app development becomes more monolithic, web development requires more single-use services either developed bespoke or via a service like Mailgun.

In this post, I’m going to look at what decoupled development means for WordPress. Adding Gutenberg to our toolkit we can use as WordPress developers, creates new opportunities, as well as new challenges.

Headless and Decoupled WordPress Development

Benefits Of Decoupled Development

Headless CMSes are a part of a strategy to decouple different components of a web application from each other. Doing so allows for more flexibility - in general, you can more easily swap out one component in a collection of components than rewrite one portion of a monolithic app. It also means that developers can focus on one thing and one language at a time.

These benefits play out in a lot of ways. It leads to fewer compromises. WordPress is good enough for most things. Decoupling part of the application to a better-suited technology - for example, off-loading search to ElasticSearch can provide a better user experience and better search results. It also can help the core application - no expensive WordPress database queries.

Downsides Of Decoupled Development

Decoupled is great! So why isn’t everyone doing it? Well first, it’s not easy to switch from monolithic to decoupled and most people are already using the traditional, monolithic patterns.

In some cases, it can be very simple - for a developer. Platforms such as Netlify and Now are bringing the one click or one CLI command setup for fairly sophisticated web application stacks. They are not yet something that is “prosumer-friendly” like WordPress is. But I suspect that will change soon. And that’s good. WordPress themes are a very old system that could use some updating. Which brings us back to Gutenberg.

 

Gutenberg, WordPress, React and Beyond

Gutenberg is the new React-powered UI framework that the WordPress 5.0+ post editor is built with. Gutenberg is being used to improve widget and theme customization and can also be used in plugins and themes. Gutenberg is developed as a collection of packages that can be installed with npm and used anywhere. This decoupling has allowed for the Gutenberg system to be used to create a Drupal and October CMS editor.

So what does that mean for WordPress and your WordPress development?

Gutenberg Decoupling

WordPress is now following this pattern. The WordPress REST API in core and the WP GraphQL project let WordPress act as a headless CMS and interact with frameworks such as React or Vue. The WordPress post editor now works via the WordPress REST API and any app, which could be built with some or all of the Gutenberg components can interact with the same API.

Developing blocks for the WordPress post editor is in many ways React development. React is a component-based system. With proper architecture, a WordPress plugin could have components that are shared between blocks and one or more apps, which may or may not be built into WordPress.

For example, consider this directory structure

/src

/src/components

/src/app

/src/blocks

In this structure, all components are developed in /src/components and then can be imported into blocks or the app. If there was a component called “Editor” at /src/components/Editor then we can use it in our block, like this:

The block is responsible for managing state. Editor needs two pairs of values and setter functions. In this example, the block’s attributes and function created with the supplied setAttributes() function are passed to the component.

Here is the same component, used in “normal” React app:

That looks pretty similar. Instead of using Gutenberg to manage state, local state is supplied using React’s useState hook. None of this matters to the Editor component. It’s totally decoupled from its parent.

Blocks (May) Just Be HTML!

Gutenberg blocks do have a lot of complexity to them. Sometimes, we forget that Gutenberg is an interface for authoring HTML. Yes, we enhance that HTML with CSS and JavaScript in the client, but it’s just HTML. Any web platform can consume HTML.  Yes, some blocks use a PHP render callback, but what comes out of the WordPress REST API, for those are the HTML result of that render callback.

Reusing or sharing React components -- or any other JavaScript or CSS -- from your WordPress site and a decoupled front-end is cool. It also adds additional complexity. None of that extra complexity is required and if it’s not worth it, then don’t do it, just use the HTML.

Testing! Testing! Testing!

A key benefit of developing blocks loosely coupled to WordPress is you can reuse the components anywhere. This is great - you spend less time developing duplicate functionality, and a more consistent user experience. The downside is if any component becomes buggy or defective it affects every client consuming it. That’s a big risk and if you’re not developing the component in every single context it’s used, then the bug or defect may not be obvious.

That is why testing is so important.  Because of how this component is designed, it is also easily testable. We can test this component’s functionality totally isolated from Gutenberg, which makes testing faster and ensures the component can be used elsewhere:

Of course, these are just unit tests. We still need to test how the component is integrated into each larger system. Those tests require more of the application to be loaded, so we want to have unit tests running first to ensure that the component works as expected. Integration and e2e tests ensure that when the component works as expected the environment it is in works as expected.

✅ unit test ❌ integration test pic.twitter.com/SDxzRYRRrz

— Danny (@malware_sec) May 6, 2019

A Better Experience For Developers And Site Builders?

Traditionally, the developer experience with WordPress has been seen as not so good. I tend to agree. But, I am super excited about Gutenberg, WP GraphQL and other projects that improve the quality of the software for developers and users. I think that users want to author content and create interfaces visually. As developers, we can provide that, if we follow best practices in terms of how we write our components so they can be reused.

Our assumption is that site builders and people who visit their sites want consistency. Consistency in terms of a WYSIWYG experience and in terms of the components working consistently. If we develop our Gutenberg blocks correctly, we can do that and have components that can be reused in other clients - other parts of wp-admin, a decoupled front-end or a mobile app.