-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Extract the getSupportedStyles selector to the blocks store as a private selector #47606
Conversation
Size Change: +1.6 kB (0%) Total Size: 1.31 MB
ℹ️ View Unchanged
|
Flaky tests detected in 81c1807. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4082324020
|
The failing unit test is a bit weird here, I think it's somehow related to "mocking" and "private selectors in store". For some reason the mocking is not working properly. Can you help @adamziel ? |
@youknowriad |
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.
Nice! I like the hooks and that you added unit tests.
It seems to me that getSupportedStyles
is two functions smooshed together:
(1) If name
is provided then it looks up what styles are supported via getBlockType( name ).supports
.
(2) If element
is provided then it computes what styles are supported using ROOT_BLOCK_SUPPORTS
and some custom logic.
Do you think it would be easier to reason about if we split them apart?
So have wp.data.select( 'core/blocks' ).getSupportedStyles( name )
which does (1) and then maybe wp.blockEditor.getSupportedStyles( element )
which does (2).
Then wp-blocks
doesn't have to know what an "element" is which doesn't really feel right to me.
Lmkwyt. I might be misunderstanding something!
} | ||
} ); | ||
|
||
return filterElementBlockSupports( supportKeys, name, element ); |
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.
Calling filterElementBlockSupports
here should have no effect, right? Because we know that name
is truthy and all but one of the branches in filterElementBlockSupports
contain a ! name
check meaning they won't execute. The one exception is the support === 'fontSize' && element === 'heading'
branch but I think that might never execute here either because otherwise there wouldn't be a Font size control in Styles → Blocks → Heading → Typography.
It's not easy to split this PR like you suggested because there's some logic that needs to know both at the same time. Like links have this particular style only in root or something like that. I think as it stands, element only impacts "root" but for me, this is just a temporary thing. In other words, when we added this logic, we only thought about the root use case but It doesn't seem crazy for me that we'd add "supports" for elements as well and have some logic like also note that root block supports also make sense even without passing an "element". I'm hesitant here. |
52d4e32
to
bd27573
Compare
Thanks @adamziel I've managed to remove the mocking. |
After thinking about it, it's about getting the supported styles for a couple (element, blockName) when both of these arguments are nullable. In other words, while getting supports for an element make sense on its own, getting the supports for a block also make sense, what this function is about is the combination of both. It's also a private selector so we can adapt. |
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 👍 Things worked as expected.
'letterSpacing', | ||
]; | ||
|
||
function filterElementBlockSupports( blockSuppots, name, element ) { |
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.
Could we include some minor docs for this function?
|
||
function filterElementBlockSupports( blockSuppots, name, element ) { | ||
return blockSuppots.filter( ( support ) => { | ||
if ( support === 'fontSize' && element === 'heading' ) { |
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 somehow encode these rules in a declarative approach as a JavaScript object. But unfortunately, that is not simple to do.
STYLE_PROPERTY[ styleName ].support | ||
) !== false | ||
) { | ||
return supportKeys.push( styleName ); |
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.
nitpick: given that a forEach does not returns, I would do:
supportKeys.push( styleName );
return;
To make it clear we are in a function that does not return.
blockType.supports && | ||
get( | ||
blockType.supports, | ||
STYLE_PROPERTY[ styleName ].support |
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.
Do we need this logic STYLE_PROPERTY[ styleName ].support[ 0 ] in blockType.supports ? Could we simply get(blockType.supports, STYLE_PROPERTY[ styleName ].support ) !== false without that part?
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.
To be honest I'm not entirely sure, this was just copied as is.
Extracted from #47356
What?
This is a small refactoring that extracts the
getSupportedStyles
function as a private selector into the blocks store.Why?
In #47356, we moved the
getSupportedGlobalStylesPanels
function to the block-editor package but in reality it's better suited for the blocks package because it only needs the block registration.Also, I'd like to use this function in a follow-up to build a "theme.json" like settings object based on a blockName, selector pair using this function as a starting point.
See related discussion #47356 (comment) and #47356 (comment)
Testing Instructions
1- Open the global styles UI (especially typography)
2- Ensure that they show the exact same panels as in trunk.
I've also added some unit tests to this function.