Docs: Update creating-dynamic-blocks.md

[thomasverleye]

The save function needs to be included in this example else the user will get an error in the inspector:

The "save" property must be specified and must be a valid function.

Description

Added a obligated save function.

How has this been tested?

Please view screenshots.

Screenshots

Before:

After

Types of changes

Update documentation code example to make sure users learn Gutenberg without any errors in the inspector.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[mkaz]

Thanks for the contribution. I added one suggestion for consistency, but looks good

[gziolo]

Looking at the screenshots I bet you are using an older version of Gutenberg:
https://www.npmjs.com/package/@wordpress/blocks/v/6.2.5

The npm package for @wordpress/blocks@6.2.5 was published over 4 months ago.

It might not include the changes introduced in #14510 which makes save optional when registering a block. Many core blocks don't have save provided and they work properly for months now. I don't think this change in documentation is expected.

[thomasverleye]

It might not include the changes introduced in #14510 which makes save optional when registering a block.

Alright thanks for clearing this out. I guess the copy in this documentation should be updated as well then:

For many dynamic blocks, the save callback function should be returned as null, which tells the editor to save only the block attributes to the database. These attributes are then passed into the server-side rendering callback, so you can decide how to display the block on the front end of your site. When you return null, the editor will skip the block markup validation process, avoiding issues with frequently-changing markup.

Also in one of the further tutorials (meta boxes) has a code-snippet with save functions returning null as well.

https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/tutorials/metabox/meta-block-3-add.md

[thomasverleye]

I've removed the save functions which return null and updated the documentation where it was stating the return function should be null.

[gziolo]

What's the reason for changing this definition? The old one follows the WordPress coding standards. You could also use the following:

Suggested change

	edit: ( props ) => {
	edit( props ) {

[mkaz]

I would love to see clarification on proper standard for function definition. The coding guidelines here does not include anything: https://developer.wordpress.org/block-editor/contributors/develop/coding-guidelines/

I'm unclear if edit: function( props ) { } is preferred to edit: ( props ) => { }

If that is the case, then wouldn't it follow that const varName = function(props) { } would be preferred over const varName = ( props ) => { }

A lot of code across Gutenberg uses the shorter fat arrow syntax, which also seems to be the direction of the larger JS community.

[mkaz]

I think the difference also exists between ES5 format, and ESNext format.

[gziolo]

We have this ESLint rule enabled:
https://eslint.org/docs/rules/object-shorthand

See:

gutenberg/packages/eslint-plugin/configs/esnext.js

Line 26 in 95e769d

'object-shorthand': 'error',

Which favours the following:

/*eslint-env es6*/

// properties
var foo = {x, y, z};

// methods
var foo = {
    a() {},
    b() {}
};

I guess between a regular function and the fat arrow syntax you can't force one as they have some differences in how they behave:

• regular function is hoisted
• arrow function inherits scope from the parent

In general, I'd love us to find a way to start linting code examples in some way. I don't know how, but it feels like this would make it easier to review all documentation changes :)

[gziolo]

This should stay as is, it follows the WordPress coding standards for ESNext codebase.

[gziolo]

Technically speaking, there is save function used which by default returns null. I agree that we should update this paragraph but we should make it more precise to avoid confusion.