gutenberg block work flow?

[yangkennyk]

is there a recommended work flow when working with gutenberg blocks?

Is it better to render individual block assets (block.js/block.css) and enqueue them in register_block_type or just have it all included in one main.js?

[swashata]

Hi,

I will create a workflow guide when I get some time. The concept is to think gutenberg blocks as any react app. So have one main.js file enqueued through gutenberg hooks. That main.js file would instantiate your blocks as needed.

[mmartin1023]

Hi @swashata, just wondering if you've had time to create a guide for your Gutenberg workflow yet. I have a fairly well working method currently, but I'd love to have a more "official" way to hook things up. I'm currently running into issues trying to take advantage of the 5.8 changes to how block assets can be more efficiently loaded. Thanks!

[lmartins]

Having some direction on this would be really great. I've been using wpack for the frontend build so I thought I'd give it a go with the bundle for Gutenberg blocks as well. It almost works, but something's not right.

Here's my setup:

wpackio.project.js

files: [
    {
      name: 'blocks',
      entry: {
        main: ['./src/js/blocks.js'],
      },
    },
  ],

That blocks.js entrypoint calls the individual blocks:

import '../../blocks/test';

The entry point for each block is simply running the registerBlockType function passing the barebones for a custom block:

import { registerBlockType } from '@wordpress/blocks';
import './styles.scss';

import metadata from './block.json';
const { name, title } = metadata;

const blockData = { ...metadata };

export const settings = {
  ...blockData,
  edit(props) {
    return (
      <div>
        <div>Edit test block.</div>
      </div>
    );
  },
  save(props) {
    return (
      <div>
        <div>Save test block</div>
      </div>
    );
  },
};

registerBlockType(name, settings);

With this setup, any edits to the edit method inside the settings object causes a full reload. However if I abstract the edit property to another file, as typically you'll want to do for organization, you'll end up with something like:

import { registerBlockType } from '@wordpress/blocks';
import './styles.scss';

import metadata from './block.json';
const { name, title } = metadata;

import edit from './edit';

const blockData = { ...metadata };

export const settings = {
  ...blockData,
  edit,
  save(props) {
    return (
      <div>
        <div>Save test block</div>
      </div>
    );
  },
};

registerBlockType(name, settings);

In this scenario edit is exporting a standard React component:

import { Panel, PanelBody, TextControl } from '@wordpress/components';

const Edit = (props) => {
  const { attributes, setAttributes } = props;
  const { gwm_test } = attributes;
  // console.log(attributes);
  return (
    <div>
      <div>Edit Test Block..</div>
      <Panel>
        <PanelBody title={'example meta box'} icon="admin-plugins">
          <TextControl
            label={'Example Meta'}
            help={'This is an example meta field.'}
            onChange={(text) => setAttributes({ gwm_test: text })}
            value={gwm_test}
          />
        </PanelBody>
      </Panel>
    </div>
  );
};

export default Edit;

However, in this scenario any changes to edit.js produce no effect in the browser, despite console showing some awareness to the changes: https://share.cleanshot.com/Eey5Fp

Had anyone successfully got this working?