Skip to content

Guty Blocks 2 – A Simple, Fast Gutenberg Block Boilerplate

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.

Comment from Sallie Goetsch: "If this is the easy way, I'm not at all sure I want to know the hard way."
A common complaint 🙂

Introducing Guty Blocks 2! My goals in making this boilerplate/build environment:

  1. Reduce the time to development by making block generation and enqueuing fast
  2. Have 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!

Comments

  1. Thanks for this! Does this handle JSX syntax? When running “npm run build” I am getting “SyntaxError”…”Unexpected token” with an arrow pointing at my first JSX tag. This typically happens when babel isn’t properly transpiling JSX in react. Do you know what might need to be changed in the package.json or webpack.config.js?

    1. I would agree that that would be the issue from that message. It may be babel-loader or the .babelrc… Just to be sure, I created a fresh WordPress, cloned my repo in, and ran npm install. I didn’t have an issue with JSX. The blocks are loading a WordPress React component and using jsx (the InspectorControls.) are you having the issue without adding any of your own code?

      It may be worth trying to do ‘npm install @babel/core @babel/preset-env @babel-preset-react babel-loader’ again just to be sure a dependency isn’t missing for some reason. Or you could delete your node_modules and fresh install.

      I’m curious if I ‘m missing something though, because while I haven’t had issues, every once and a while I get a comment about this message in particular. I would be thrilled if someone could tell me.

  2. Hi,
    Thank you so much. Your boilerplate is extreme helpful! Is it possible to custom global styles? e.g. to overwrite stylings of existing blocks within the plugin?

    1. I think a lot of people would say that overriding global things would be the job of the theme. In my personal projects I create a custom theme and style all of the common elements there. If you want to you can enqueue your own css inside this plugin using wp_enqueue_style() in the plugin.php.

      1. Thanks for your response. Im gonna try this out. Where in your boilerplate structure should I place file(s) for extend existing blocks? e.g. core/paragraph with wp.blocks.unregisterBlockStyle?

        1. I don’t have yet an option for block extensions, but I’d love suggestions. If you wouldn’t mind going to https://github.com/JimSchofield/Guty-Blocks-2/issues and submitting an issue request and possibly what a “blank” block extentsion template would look like, I would really appreciate it. Or better yet, a pulll request if you’re so inclined 🙂 That way I could keep track of some things I should improve in this boilerplate.

  3. So i’ve implemented this as a plugin and is working fantastic, I’m in the middle of editing css for the view and the editor. but the styles dont load on the view side of things.
    What could be going wrong here?

    1. Hmm, I just tried using this plugin on a clean new WP instance, and I realized I needed to clean some things up! 🙂 . But I’m not able to reproduce the issue- my styles are loading in the editor and the view.

      My instinct is to turn off the gutenberg plugin if you have that installed. There are some weird things happening if you’re using the latest gutenberg plugin sometimes, so I generally use the default gutenberg that comes with core WP. Gutenberg changes fast, so you may want to avoid developing with the latest gutenberg builds.

      If that’s not the issue, you may have to do the old-school disabling plugins one at a time method… or you may need to tinker with enqueuing styles. Without seeing your setup I can’t really tell more. Sorry :/

  4. Hi Jim,

    I am in the process of building a custom block/module system for my team. I have explored a few different approaches such as create-guten-block, acf custom blocks, and just manually creating the plugin and blocks. I see it has been a few months since you last worked on Guty-Blocks-2 and was wondering if your methodology has changed in the last few months or if there are things that you would like to do differently.

    1. Hi Shawn, the problem with Gutenberg is it is notoriously fast-developing, and I honestly haven’t been on a project that required Gutenberg for a few months (hence the slow updating). But, If I were in the drivers seat, I would stick with my boilerplate for a next project for sure. I prefer enqueuing one javascript file and adding one stylesheet for my block collection. And this is also what I’ve seen a few prominent WP shops doing.

      Also, there have been a few developments that are really worth looking at, like wp-scripts now has a “webpack config” of sorts that might work for you. https://javascriptforwp.com/wordpress-scripts-build-tool-tutorial/ might be a good place to check that out.

      1. Also, I forgot to mention two things about the methods you mentioned:

        I hear the acf custom blocks is really enjoyable to work with, but I haven’t yet. I think I would prefer to keep ACF out of the picture and let my blocks not be dependent on them.

        create-guten-block is a fine choice, but I found that that environment was rather bloated for my taste. I know a lot of people really like it though.

Leave a Reply

Your email address will not be published. Required fields are marked *