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

Update/stricter block validation #1345

Merged

Conversation

njpanderson
Copy link
Contributor

This is a PR for resolution to issue #362.

This is a required method and all tests which use registerBlockType as some form of fixture will need to be updated.
This will enforce the following:

 - `save` will be a required method when registering a block type.
 - `edit` will be an optional method, but must be a callable function.
@njpanderson
Copy link
Contributor Author

Anyone fancying a look at this? It's regarding #362.

@@ -44,6 +44,19 @@ export function registerBlockType( name, settings ) {
);
return;
}
if ( ! settings ||
( settings && typeof settings.save !== 'function' ) ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we write this like?

if ( 
  ! settings  ||
  ( settings && typeof settings.save !== 'function' )
)

I think this pattern is the one used in the Gutenberg code

Copy link
Contributor

Choose a reason for hiding this comment

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

Minor: should we use isFunction from lodash? It handles a special case for us.

@njpanderson
Copy link
Contributor Author

Have amended, @youknowriad.

@@ -44,6 +49,19 @@ export function registerBlockType( name, settings ) {
);
return;
}
if ( ! settings ||
( settings && ! isFunction( settings.save ) ) ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we put this test in one line too?

);
return;
}
if ( settings && 'edit' in settings && ! isFunction( settings.edit ) ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess the settings test is useless here, because we already checked for its existence above?

@njpanderson
Copy link
Contributor Author

Both issues sorted in latest push.

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

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

LGTM 👍 Thanks for the updates

@youknowriad
Copy link
Contributor

@nylen do you have any other thoughts on this. I know you're behind the validation we had in the first place.

Copy link
Member

@nylen nylen left a comment

Choose a reason for hiding this comment

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

Generally seems fine to me. Some notes above. We should also make sure similar validation is in place on the server side, but for now this would be for the render function.

@@ -44,6 +49,18 @@ export function registerBlockType( name, settings ) {
);
return;
}
if ( ! settings || ( settings && ! isFunction( settings.save ) ) ) {
Copy link
Member

Choose a reason for hiding this comment

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

The settings && check here is redundant - by this point in the conditional, we already know that settings is set.

@@ -44,6 +49,18 @@ export function registerBlockType( name, settings ) {
);
return;
}
if ( ! settings || ( settings && ! isFunction( settings.save ) ) ) {
console.error(
'A "save" function must be created within the block settings.'
Copy link
Member

Choose a reason for hiding this comment

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

Let's clean up this message a bit:

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

@@ -10,6 +11,8 @@ import { createBlock, switchToBlockType } from '../factory';
import { getBlockTypes, unregisterBlockType, setUnknownTypeHandler, registerBlockType } from '../registration';

describe( 'block factory', () => {
const defaultBlockType = { save: noop };
Copy link
Member

Choose a reason for hiding this comment

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

defaultBlockSettings would be a better name here and below.

@nylen
Copy link
Member

nylen commented Jun 29, 2017

We should also make sure similar validation is in place on the server side, but for now this would be for the render function.

To clarify: this is fine for a separate PR.

@njpanderson
Copy link
Contributor Author

@nylen / @youknowriad - Both changes above have been made.

Copy link
Member

@nylen nylen left a comment

Choose a reason for hiding this comment

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

Looks good to me. Thanks for working on this!

@nylen nylen merged commit 6c6d682 into WordPress:master Jul 3, 2017
@swissspidy
Copy link
Member

Note that because of this there's a bunch of warnings when running the unit tests.

@swissspidy
Copy link
Member

Can de validate-block-settings branch be deleted?

@njpanderson njpanderson deleted the update/stricter-block-validation branch July 5, 2017 18:38
@njpanderson
Copy link
Contributor Author

njpanderson commented Jul 5, 2017

Apologies - I've been quite tied up for a few days.

My own branch has been deleted, not sure about the other one.

In answer to your remark regarding warnings, @swissspidy - I'd fixed all of them on the tip of my branch but I suspect due to the lead time more old patterns of use for the registration have crept in. Not sure who's down for fixing them but happy to work on another issue for it if there is one.

@nylen
Copy link
Member

nylen commented Jul 6, 2017

These warnings should really be errors that fail the build, which will prevent them from reoccurring. See #1769.

youknowriad pushed a commit that referenced this pull request Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants