Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ESNext syntax to meta block tutorial #13954

Merged
merged 3 commits into from
Feb 20, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -10,38 +10,40 @@ By specifying the source of the attributes as `meta`, the Block Editor automatic

Add this code to your JavaScript file (this tutorial will call the file `myguten.js`):

{% codetabs %}
{% ES5 %}
```js
( function( wp ) {
var el = wp.element.createElement;
var registerBlockType = wp.blocks.registerBlockType;
var TextField = wp.components.TextControl;
var TextControl = wp.components.TextControl;

registerBlockType("myguten/meta-block", {
title: "Meta Block",
icon: "smiley",
category: "common",
registerBlockType( 'myguten/meta-block', {
title: 'Meta Block',
icon: 'smiley',
category: 'common',

attributes: {
blockValue: {
type: "string",
source: "meta",
meta: "myguten_meta_block_field"
type: 'string',
source: 'meta',
meta: 'myguten_meta_block_field'
}
},

edit: function(props) {
edit: function( props ) {
var className = props.className;
var setAttributes = props.setAttributes;

function updateBlockValue( blockValue ) {
setAttributes({ blockValue });
}

return el(
"div",
return el(
'div',
{ className: className },
el( TextField, {
label: "Meta Block Field",
el( TextControl, {
label: 'Meta Block Field',
value: props.attributes.blockValue,
onChange: updateBlockValue
} )
Expand All @@ -53,9 +55,52 @@ Add this code to your JavaScript file (this tutorial will call the file `myguten
save: function() {
return null;
}
});
})( window.wp );
} );
} )( window.wp );
```
{% ESNext %}
```jsx
import { registerBlockType } from '@wordpress/blocks';
import { TextControl } from '@wordpress/components';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm personally concerned about the change in the imports as it's something that doesn't work unless you define externals. While using globals signals that we should rely on npm packages to be bundled here. Think of any JavaScript developper reading this, I'm pretty sure they won't understand that this needs point to globals.

Copy link
Member

@oandregal oandregal Feb 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point I missed. Trying to put together my thoughts on this:

  • in tutorials, handbook, etc. we should promote globals. These are tailored for WordPress developers, so the assumption is that they're building something to integrate with WordPress. Having both ES5 and ESNext is helpful for onboarding, but promoting globals makes sense here.

  • in package info (READMEs, JSDoc examples, etc) we should promote import syntax and avoid the globals. Packages should be agnostic of the host they're bundled with (WordPress injecting the globals). It's not that important a goal to have good coverage for ES5 here.

This isn't perfect, though. For example: when we expose JSDoc examples in the handbook, they'll contain the import syntax.

Does this sound like a good compromise? #13995

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference: things will be even more confusing in a few days, once we ship the zero-config wp-scripts build command that include externals (and the reason I thought about proposing this) 🤷‍♂️

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • in package info (READMEs, JSDoc examples, etc) we should promote import syntax and avoid the globals. Packages should be agnostic of the host they're bundled with (WordPress injecting the globals). It's not that important a goal to have good coverage for ES5 here.

Agreed on this one. I would be personally fine of using imports only for ESNext examples.

For tutorials and handbook in general, using wp globals is a very good idea.


registerBlockType( 'myguten/meta-block', {
title: 'Meta Block',
icon: 'smiley',
category: 'common',

attributes: {
blockValue: {
type: 'string',
source: 'meta',
meta: 'myguten_meta_block_field',
},
},

edit( { className, setAttributes, attributes } ) {

function updateBlockValue( blockValue ) {
setAttributes( { blockValue } );
}

return (
<div className={ className }>
<TextControl
label="Meta Block Field"
value={ attributes.blockValue }
onChange={ updateBlockValue }
/>
</div>
);
},

// No information saved to the block
// Data is saved to post meta via attributes
save() {
return null;
}
} );
```
{% end %}

**Important:** Before you test, you need to enqueue your JavaScript file and its dependencies. Note the WordPress packages used above are `wp.element`, `wp.blocks`, and `wp.components`. Each of these need to be included in the array of dependencies. Update the `myguten-meta-block.php` file adding the enqueue function:

Expand Down