WordPress Gutenberg import versus Destructuring Global wp

When creating a block for the WordPress block editor (a.k.a. Gutenberg), you are often using existing components. WordPress makes these components available under the global JavaScript variable wp.

Destructuring

We can use these in our code with destructuring. e.g.

const {
    components: {
        Button,
    }
} = wp;

This makes the Button component available to us.

Import

Alternatively, when using npm we can require @wordpress/scripts as one of our devDependencies in package.json. When we add this dependency, we make available modules that we can import. e.g.

import { Button } from '@wordpress/components';

This code also makes the Button component available to us.

Which is better?

At this point, my question is which of these approaches is better.

Destructing Advantage

I like the destructuring because it seems like this should keep our code base smaller (we don’t need to include JavaScript for the component because we’re using it from the global object that already exists in memory).

Notes

Size Advantages

I tried converting a simple block that was using import to instead use the global wp object with destructuring. While the file size was smaller using destructuring, it was not a significant change. It would be interesting to see the size difference in a more complex block.

source

Import Advantage

I’m wondering if using the import would let us be certain about the version of the component we’re using. It seems that things move quickly in Gutenberg development and I want to avoid writing code that stops working when Gutenberg updates to a new version.

Notes:

Moving to a Newer Version of WordPress

When using a block written for an earlier version of WordPress and using the wp global, deprecation notices are thrown in the browser console but the block continues to work properly.

Moving to an Older Version of WordPress

Regardless of whether I using the wp global or an import statement, when I tried to run a modern block on an older version of WordPress, I was greeted with the message

Your site doesn’t include support for the “salcode/markdown” block. You can leave this block intact, convert its content to a Custom HTML block, or remove it entirely.

source

Examples

The Jetpack plugin from Automattic uses import for blocks (see code).

The CoBlocks set of blocks uses import (see code).

The Ultimate Blocks set of blocks uses destructuring (see code).

The Atomic Blocks set of blocks uses destructuring (see code)

I don’t know

At this point, I don’t know which is a better approach however I wanted to get these thoughts down and hopefully I can update this with something more definitive when I know more.

In response to my inquiry on Twitter

Use import, it's what the official packages use, the official examples, and it has the blessing of the official wp-scripts setup. It might use the other method internally, but that could change in the future. Destructuring a global variable to get dependencies in JSX is weird

— Tom J Nowell ✨ (@Tarendai) March 30, 2020

Sal Ferrarello (@salcode)

Sal is a PHP developer with a focus on the WordPress platform. He is a conference speaker with a background including Piano Player, Radio DJ, Magician/Juggler, Beach Photographer, and High School Math Teacher. Sal can be found professionally at WebDevStudios, where he works as a senior backend engineer.