Using the WordPress JavaScript APIs for fun and profit part six - The recap

Welcome to part six of our series on using WordPress JavaScript APIs, in which we explore the APIs that were introduced in WordPress 5.0. We'll have a look at how we can use them to better integrate with other plugins, in a reliable and safe way. Make sure to also check out our repository on GitHub, which contains all the code we’ve written in this series.

In the previous chapter, we explored Slots and Fills that are part of the @wordpress/components package and showed you how to make your own plugin better integrate with the WordPress UI, bringing us one step closer to being more interoperable with WordPress.

In this final chapter, we’ll look back at what we’ve created and discuss a few points of interest that we didn’t cover in this series of posts.

Looking back

The beginning

In the first chapter of our adventure, we dove into the basic setup of our project and the initial building of two forms, one in jQuery and one in React, that we later used to simulate a WordPress-like environment when it comes to editing a post or page.

Introducing Redux

After this, in chapter two, we introduced Redux, a framework that ensures that data always flows in a single, consistent direction, ensuring data behaves predictably. We also touched on the subject of stores and reducers and introduced a way to connect these Redux principles to our forms.

Connecting to the WordPress API

Chapter three brought us one step closer to integrating with WordPress’ APIs, where we move from our bare bones Redux implementation and move to the @wordpress/data package, which introduces a similar approach to managing data, but in a more WordPress-compatible way. We also introduce a new concept: Selectors. These selectors are the way WordPress allows developers to retrieve data in a simplified and structural manner.

Using the core/editor store in your plugin

In chapter four, we looked at the core/editor package, which is used to manage data from the WordPress editor and makes us more interoperable with WordPress. We altered our project to utilize a ‘dummy’ version of this package to demonstrate its usage and how plugin developers can call functions within this package to retrieve data from the WordPress editor for usage in their own plugins.

Using Slots and Fills

Finally, in chapter five, we looked at the concept of Slots and Fills, which is another method that WordPress 5.0 introduced to allow plugin developers to integrate with the sidebar of the WordPress editor. In this chapter, we created another ‘dummy’ implementation of the WordPress editor, including a sidebar and the underlying parts that ensure data is properly propagated. Implementing this brings us another step closer to our goal of full interoperability with WordPress and its APIs.

The Blocks API

Now, the concepts of blocks might seem familiar. Most page builders use the same concept to make editing the layout for users as intuitive as possible, as it seems almost natural for most people to stack blocks as if they were working with LEGO! However, these implementations mostly use a custom data structure and ‘hijack’ the WordPress editor to achieve this. Unfortunately, this frequently leads to interoperability problems with other plugins, necessitating everyone to start using unreliable methods, such as directly reading out the DOM to retrieve data… So how does the new WordPress editor deal with this?

The answer to this is the Blocks API. This API opens up WordPress like never before, making it possible for plugins to integrate even more and expand the number of available blocks currently present within the editor. Furthermore, it allows developers to translate complex concepts, into a single and contained element within the editor, with a user-friendly UI. One example is the HowTo block we’ve created here at Yoast, which makes the creation of ‘how-to’ articles easier, whilst also ensuring the proper Schema output is added to the HTML of the website.

Blockify everything!

Sadly, not everything is sunshine and rainbows with the introduction of these APIs. The custom data structures that we mentioned earlier aren’t something that can quickly be converted into something that is 100% compatible with the WordPress APIs. Additionally, the Blocks API is still lacking in a few other areas. For example, widgets are still not available in a block-like manner, which is something that some page builders might rely on.

A possible solution

Luckily, not all hope is lost! If you’re a page builder that wants to integrate into the WordPress editor, there's an option in the form of Dynamic Blocks. What this allows you to do, is register separate blocks that have a (as the name suggests) dynamic component to them. Usually, this dynamic component is something that uses its own data structure internally and communicates with WordPress via a server component, which is written in PHP. What this means is that plugins such as page builders, largely only need to focus on integrating a UI that is compatible with WordPress and don’t need to rewrite everything they’ve created thus far.

One plugin that utilizes these Dynamic Blocks rather well is ACF Pro. We’ve even written an article on the usage of Dynamic Blocks via ACF and how you can use this in your own plugin because it’s rather robust and easy to learn, as they utilize a PHP-based approach. This takes out a large part of the learning curve when switching to React and Redux. At Yoast, we also utilized Dynamic Blocks in our digital story on the subject of diversity, inequality, and prejudice to speed up the development process and have an easier to maintain a project. We’ve also written an article on how that project was built if you’d like to know more.

The future and the role of the JavaScript APIs

Currently, the JavaScript APIs still require some extra effort from (plugin) developers. Especially page builders still have quite some work left ahead of them before they can call themselves fully interoperable. Hopefully, the future of the JavaScript APIs will be such, that all plugins (but even more so: page builders), can solely focus on their strengths and not have to worry about other plugins and whether or not they seamlessly integrate with one another.

Conclusion

We hope that you were able to learn a thing or two from this series of posts regarding the JavaScript APIs. As WordPress evolves over the coming years, so will the various APIs, up to a point where we might be able to forget all the struggles we used to have with page builders and other plugins and push WordPress even further.