Guty Blocks 2 – A Simple, Fast Gutenberg Block Boilerplate February 8, 2019 by Jim Schofield When I first wrote the series on how to build a gutenberg block, I called it Gutenberg Blocks Made Easy… and looking back, I think I did a pretty good job explaining, but not so great of a job making it easy. I walked through how to create a Gutenberg block boilerplate, but for those who don’t want to know about webpack, it was intense. A common complaint 🙂 Introducing Guty Blocks 2! My goals in making this boilerplate/build environment: Reduce the time to development by making block generation and enqueuing fastHave a build that requires minimal enqueuing and minimal file size. Check out the github repo: https://github.com/JimSchofield/Guty-Blocks-2 See it in action: How it’s faster to get to developing Getting the scripts enqueued and running was always a pain even after you had a Gutenberg boilerplate set up. You could simplify the explanation, but really there’s a lot to do: create a php file, create a js build process, create a js file, create css files, create a js enqueue function, create a css enqueue function, add WordPress hooks…. and that’s not all of it. Now, you can use the ‘node generate’ command to get a block up and running immediately. you can focus on development, and not the webpack configuration. A big mistake in my previous examples was that I was not treating React as an external dependency. Meaning, that when I imported React in my gutenberg blocks, webpack bundled it along with my block scripts. But WordPress already had React available and running in the editor! The solution in this boilerplate is to call React and ReactDOM as external dependencies, so bundle sizes are small. Another thing I am really glad to set up is a way to generate a block with a view script. There are many times you create the markup for a block but then need a script to run on the view of the page! The view script is automatically made and included and enqueued so that it runs on the front end. Future plans My most immediate use cases for Gutenberg involve headless WordPress (see Gatsby and a post I wrote about Gatsby + WordPress.) One of the main issues I run into is where to put the styles. Gutenberg is cool in that all the block’s markup and data are stored in ‘content’ string. The problem here is that WordPress then serves up styles through it’s regular hooks. But what if you’re loading the content in a separate environment like Gatsby? You have to include the styles somehow. One way to do this is to include the styles “just in time” next to the content. Maybe there should be an option to include styles in the block? More discussion on that to come. Give me feedback! Is it great? Is it terrible? Do you think it could be better? Is there something I’m not thinking about? Let me know below or on twitter!