Skip to content

Commit

Permalink
Add a README about the development of custom blocks.
Browse files Browse the repository at this point in the history
  • Loading branch information
eason9487 committed Nov 30, 2023
1 parent 9d445df commit 6f17074
Showing 1 changed file with 74 additions and 0 deletions.
74 changes: 74 additions & 0 deletions js/src/blocks/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
# Custom product blocks

To make this extension compatible with the Product Block Editor, it needs to implement a few custom blocks to map all classical fields to product editor blocks.

## Development

Implementing custom blocks by the default development way, each block will be built as a separate script and will need to be loaded into the browser separately at runtime.

Since this extension requires a few custom blocks, and considering these custom blocks will not be used individually, and in order to reduce the number of scripts loaded, here are some adjustments that differ from the default way.

### Directory structure of source code

```
/js/src/blocks/ # The root directory of custom blocks
├── product-select-field/ # A custom block
│ ├── block.json # The metadata file of this block and also the canonical way to register this block with both PHP and JavaScript side
│ └── edit.js # The component to work with the `edit` function when registering this block, and it's the interface for how this block is going to be rendered within the Product Block Editor
├── another-field/ # Another custom block
│ ├── block.json
│ └── edit.js
├── components/ # The shared components within custom blocks
│ ├── index.js # The main file to export components
│ └── label.js # A shared component
└── index.js # The main file to import and register all custom blocks via JavaScript
```

### Directory structure of built code

```
/js/build/ # The root directory of built code
├── product-select-field/ # A custom block
│ └── block.json # The copied metadata file to be used to register this block via PHP
├── another-field/ # Another custom block
│ └── block.json
├── blocks.js # The built script to register all custom blocks via JavaScript and to be registered and enqueued via PHP
└── blocks.asset.php # The dependencies of blocks.js to be used when registering blocks.js via PHP
```

### Infrastructure adjustments

#### block.json and edit.js

By default, it should specify the `editorScript` with the relative path of edit.js, so that the `wp-scripts build` and `wp-scripts start` provided by `@wordpress/scripts` will also parse and build each block separately, and the edit.js needs to register itself along with its block.json.

With the adjusted setup:

- Every block.json should **not** specify the `editorScript` to avoid building blocks separately.
- Every edit.js should **not** do the registration.
- All block.json and edit.js files should be imported and registered via JavaScript by the index.js file at the root directory of custom blocks.

#### webpack.config.js

By default, when building, the [webpack config](https://github.com/WordPress/gutenberg/tree/%40wordpress/scripts%4024.6.0/packages/scripts#default-webpack-config) imported from `@wordpress/scripts` will find all block.json files within the given source code directory [specified by `--webpack-src-dir`](https://github.com/WordPress/gutenberg/tree/%40wordpress/scripts%4024.6.0/packages/scripts#automatic-blockjson-detection-and-the-source-code-directory), and then parse and build each block as per block.json.

With the adjusted setup:

- Build the index.js file in the root directory of custom blocks as the blocks.js at the root directory of built code.
- The blocks.asset.php file will be generated along with the build of the blocks.js. The `dependencies` value in the file is related to the mechanism of DEWP. See [Working with DEWP.md](../../../Working%20with%20DEWP.md) for more details.

#### Registration on the PHP side

By default, when each block is registered via PHP in the [AttributesBlock](../../../src/Admin/Product/Attributes/AttributesBlock.php) class, the `register_block_type` function will also register and enqueue the related scripts and styles such as the built edit.js.

The same part is the separate registration for each block, therefore all blocks should be listed in the `CUSTOM_BLOCKS` array of the `AttributesBlock` class.

With the adjusted setup:

- The scripts and styles of blocks are not specified in block.json files, so they won't be registered or enqueued via the `register_block_type` function.
- Instead, the blocks.js script is registered and enqueued by `AttributesBlock`.

## Related documentation

- [Woo - Product Editor Development](https://github.com/woocommerce/woocommerce/tree/trunk/docs/product-editor-development)
- [WordPress - Block Editor Handbook](https://developer.wordpress.org/block-editor/)

0 comments on commit 6f17074

Please sign in to comment.