-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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 a function to unregister a block style variation #10654
Conversation
* @param {string} styleVariationName Name of class applied to the block. | ||
*/ | ||
export const unregisterBlockStyle = ( blockName, styleVariationName ) => { | ||
addFilter( 'blocks.registerBlockType', `${ blockName }/${ styleVariationName }/unregister`, ( settings, name ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we have to rethink the namespace for this and registerBlockStyle
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I'd personally like to see if we could avoid the filter altogether, and instead make style a proper data type of its own than force-fit it into the block definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to avoid using the filter in the first place.
In regards to the propose PR, why not use buil-int removeFilter
instead?
removeFilter( 'blocks.registerBlockType', `${ blockName }/${ styleVariation.name }` );
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gziolo Because you can't remove built-in style variations with this.
|
||
return { | ||
...settings, | ||
styles: remove( get( settings, [ 'styles' ], [] ), ( style ) => styleVariationName !== style.name ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
is mutative, which we should avoid. Consider reject
or filter
instead:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading this, it seems like it should be the opposite equality check, removing those variations where the style name matches the function argument.
* @param {string} styleVariationName Name of class applied to the block. | ||
*/ | ||
export const unregisterBlockStyle = ( blockName, styleVariationName ) => { | ||
addFilter( 'blocks.registerBlockType', `${ blockName }/${ styleVariationName }/unregister`, ( settings, name ) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I'd personally like to see if we could avoid the filter altogether, and instead make style a proper data type of its own than force-fit it into the block definition.
A paragraph or two in https://github.com/WordPress/gutenberg/blob/377c222ebaecdab3771dfd3e66f940aa1fe94954/docs/extensibility/extending-blocks.md about this function can't hurt. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the documentation front, we should consider also adding a note of this new addition to packages/blocks/CHANGELOG.md
.
https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md#maintaining-changelogs
Otherwise, code-wise, this is looking good, with notes for future iterations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 Feel free to rebase and merge.
Thanks for the useful addition! |
This PR is a follow-up to #7997 and adds a helper function to remove an existing block style variation.
Related: #7551