Gutenberg, the new and modular editing experience for WordPress, has been in rapid development throughout the past year and will soon arrive to our WordPress installations. Gutenberg will be released along with WordPress 5.0 (which is the next major release), and although no official date has been set for that, it’s safe to assume that it’s not very far away especially judging by the remaining features for MVP completion.
Gutenberg’s API and design patterns are at a stable enough stage where the time is ideal to discuss about the many technology decisions every WordPress developer will soon have to make, and perhaps pose some open questions up for debate.
— Mall Mullenweg, The State of Word, Dec 2015
After its biggest update with the ES2015 version (a.k.a ES6), year after year new features are being added making the language more powerful, user friendly, and trustworthy.
To sum it up, in my personal opinion, being fully ready for advanced Gutenberg development means:
3. React knowledge and most importantly the concepts and paradigms it introduces.
4. Redux knowledge and most importantly the concepts and paradigms it introduces.
6. Expert knowledge with the actual Gutenberg API.
All the above might seem like a lot, and while it’s true that the Gutenberg API provides an abstract layer over React and Redux, the key concepts the two libraries introduce are pervasive throughout it. A strong understanding of concepts such as componetization, props and state, immutability, functional and event based programming, will give anyone a significant head start.
ES5 vs ESNext+JSX
If you’ve ever visited the Gutenberg Handbook, which acts as the official introduction to the project and as part of its documentation, you’ll have noticed that it offers all examples using both versions. Let’s break down the one from the above link and see how ESNext (with a build step) makes more sense.
Method definitions shorthand syntax along with function argument object destructuring.
There has been a lot of debate concerning the usage of JSX when React was at its early stages. The JSX paradigm (“HTML” in JS) seemed to conflict with some puristic ideas and the general “separation of concerns” mantra which was prevalent in the front-end world. This debate has been discussed in countless articles (and still goes strong some times), so I’m not going to touch upon it. All I’m going to say is that I personally can’t fathom building React components without JSX. Use it (or not) at your own preference and coding style.
Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.
For that reason, the Gutenberg community has been working at creating boilerplates and scaffolds that can provide a solid starting point to being productive as fast as possible.
1. The official Gutenberg examples repo contains all versions using ESNext and a webpack configuration.
create-guten-block A CLI tool similar to
create-react-app with bundling, linting, and testing all out of the box.
wp scaffold block command which scaffolds required files for a block to function.
wp scaffold block produces only ES5 code without a build step for now).
It remains to be seen how Gutenberg tooling and scaffolding will evolve over time, especially after the first release is out but the great thing is that we’re already on a great track right now and my educated guess is that we’ll soon see something official and maintained by the core team.
When all the boilerplate gets out of the way, the final piece of the puzzle would be to start developing actual blocks and, to achieve that, mastering Gutenberg’s API and idioms will be paramount. We all know that Gutenberg is built on top of React (and Redux) and follows many of their patterns. Its philosophy closely follows React’s component encapsulation, modularization, and general practices, along with some functional concepts and ideas from the Redux camp. I don’t see prior React expertise ever being a hard requirement in order to develop blocks, but I do feel that it’s helped me a lot and has provided a significant head-start.
And while those ideas are prevalent, Gutenberg abstracts over all of them in a unified API and introduces new concepts in and on itself, as everything is offered as standalone modules, making it simple to use the parts necessary for each use case while limiting complexity. Gutenberg exposes its main API via important JS libraries including (but not limited to):
- @wordpress/components: Generic, reusable UI WordPress components
- @wordpress/i18n: Internationalization utilities
- @wordpress/element: Abstraction on top of React
- @wordpress/date: Date formatting and manipulation utilities
- @wordpress/blocks: Module providing utilities for registering and building blocks
- @wordpress/data: Abstraction on top of Redux
- @wordpress/editor: Module representing the WordPress Editor’s page
From my experience, developing blocks right now is a mix and match approach of:
- Going through the handbook
- Reading the main documentation of an API (i.e. data, element, etc)
- Looking at examples on how something similar is achieved on the actual native blocks section in the GitHub repo
- Use any already existing Components from the @wordpress/components module if applicable
- Create new components out of WordPress’s primitives if necessary
- Trial & error
Should I ditch PHP then?
A lot more to discover
Gutenberg is a journey right now, we’re all under an exploratory mood, figuring out pieces of the puzzle towards a modern publishing experience. There are definitely a lot to digest and a lot more to discover: Creating custom components and primitives, using “native” React or Redux without Gutenberg’s abstraction, making new reusable block UI frameworks for our personal theme and plugin needs, locked block templates in the place of PHP page templates, and so much more. Until the official finalized documentation and best practices emerge we’ll have to follow our engineering curiosity and fill in the blanks ourselves. It’s not going to be on a tour on the express lane, but I’m confident the end result will worth it.
How do you prepare yourself for Gutenberg? What technology choices have you made, and how are you planning on developing for WordPress after its release? Do you have any tips or tricks to share, or any questions that we might be able cover? We’d love to know in the comments section!