-
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
[Documentation] Add @examples to core/blocks selectors. #42572
[Documentation] Add @examples to core/blocks selectors. #42572
Conversation
getBlockSupport() hasBlockSupport() hasChildBlocks() hasChildBlocksWithInserterSupport
Size Change: -190 B (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
* | ||
* // Return the active block variation for the first block. | ||
* return select( blocksStore ).getActiveBlockVariation( | ||
* 'core/embed', |
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.
How about also using firstBlock
for consistency?:
* 'core/embed', | |
* firstBlock.name, |
I think that it should also contain block attributes: firstBlock.attributes
.
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.
I've simplified the whole example based on your suggestion - thanks!
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.
Excellent work adding all those examples. I left some minor notes.
There is also one general thing I notices. Every occurrence of useSelect
should have the second param included - dependencies used. In most cases, it's going to be []
.
* | ||
* const ExampleComponent = () => { | ||
* const blockNameIsFound = useSelect( ( select ) => | ||
* select( blocksStore ).isMatchingSearchTerm( 'core/navigation' ) |
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.
I think that the second param is missing here. You have to pass the search term to validate it against a given block type.
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.
Updated to provide a much clearer example and explain a little better where the search is happening.
* | ||
* const ExampleComponent = () => { | ||
* const navigationBlockHasChildBlocksWithInserterSupport = useSelect( ( select ) => | ||
* select( blocksStore ).hasChildBlocksWithInserterSupport( |
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.
I'm not sure how popular this function is, but it would be good to explore what role it plays and maybe hide it from the documentation to avoid the noise.
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.
I really have no idea where it's used. An equivalent function is exported here. Perhaps we should @ignore
this one here? That might also be a good idea for all the data store selectors with wrappers in the api
dir?
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.
hasChildBlocksWithInserterSupport
was introduced 4 years ago, so it's hard to tell 😄Although, I see it is no longer used so we might want to mark it as deprecated in both places.
That might also be a good idea for all the data store selectors with wrappers in the api dir?
I don't think it's a good idea overall. All public methods are re-exported in https://github.com/WordPress/gutenberg/blob/trunk/packages/blocks/src/api/index.js. While it's convenient to run some of those selectors through the wrapper exported directly from @wordpress/blocks
, in many cases, it would be anti-pattern when used in React components. The reason for that is that you lose all the handling for re-renders coming from useSelect
when the return value changes over time.
@gziolo while making the update based on your notes, I discovered that the docs are pointing to the store selectors/actions in the tokens i.e:
In this case, an This will mean moving the examples to the corresponding location in |
select( blocksStore ).getCategories() | ||
); |
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.
One more place to fix in the file with original code:
select( blocksStore ).getCategories() | |
); | |
select( blocksStore ).getCategories(), | |
[] | |
); |
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.
Ah! Yes, I added that to the actions.js and didn't update it. Updated now.
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.
Changes in this PR look great 💯
See my comment #42572 (comment). It's more nuanced. It all depends on the context where you use the code. Most of those wrappers around |
@gziolo that makes more sense and thanks for the context there. I think it's probably best to leave things as they are then. |
What?
This PR adds
@example
tags for all non-deprecated, non-experimental selectors for the@wordpress/blocks
package. Part of the effort in #42125.