-
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
Allow setting a defaultBlock
attribute on the navigation block
#51026
Conversation
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @sethrubenstein! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
Thank you very much for contributing @sethrubenstein Seth! It is much appreciated! I will go ahead and ping @getdave and @MaggieCabrera so they know about this PR and can check it out. |
@paaljoachim Thanks! I look forward to any feedback! |
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.
Thanks for your contribution @sethrubenstein.
I left a couple of comments. The biggest issue seems to be that __experimentalDefaultBlock
isn't a stable API, so I don't think we can comfortably expose it via the nav block's attributes.
I think there's some work to do to stabilize __experimentalDefaultBlock
first.
// If the `defaultBlock` attribute is set and itself has an attributes object with values then use it | ||
// otherwise fallback to the DEFAULT_BLOCK constant. | ||
// This allows site owners to set the default `core/navigation-link` variation to use. | ||
const navDefaultBlock = defaultBlock && defaultBlock.attributes && Object.keys(defaultBlock.attributes).length > 0 ? defaultBlock : DEFAULT_BLOCK; |
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 about the part that checks the length of the attributes. Wouldn't that disallow setting a new default that doesn't have any specific default 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.
@talldan Thats correct, my intention here was to assume if a developer/user hasn't included some attributes that actually changes something about the default core/navigation-link
block to be inserted that we'd default to DEFAULT_BLOCK. But I can also see how that might confuse people at first. Ideally I think we'd get rid of DEFAULT_BLOCK
altogether and rely on the block.json defaultBlock
value... but I didn't want to assume I could unilaterally make that call.
So I'm completely open to however you all want this to work this was just my very opinionated approach to respecting the default behavior already present.
@@ -98,7 +104,7 @@ export default function NavigationInnerBlocks( { | |||
onChange, | |||
allowedBlocks: ALLOWED_BLOCKS, | |||
prioritizedInserterBlocks: PRIORITIZED_INSERTER_BLOCKS, | |||
__experimentalDefaultBlock: DEFAULT_BLOCK, | |||
__experimentalDefaultBlock: navDefaultBlock, |
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.
Given this was introduced as an experimental API, I'm not sure about exposing it as a stable attribute of a block.
It might be worth stabilizing the __experimentalDefaultBlock
API first so that this becomes defaultBlock: navDefaultBlock
and deprecating the __experimentalDefaultBlock
property.
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.
Resolved by #52083
@@ -98,7 +104,7 @@ export default function NavigationInnerBlocks( { | |||
onChange, | |||
allowedBlocks: ALLOWED_BLOCKS, | |||
prioritizedInserterBlocks: PRIORITIZED_INSERTER_BLOCKS, | |||
__experimentalDefaultBlock: DEFAULT_BLOCK, | |||
__experimentalDefaultBlock: navDefaultBlock, | |||
__experimentalDirectInsert: shouldDirectInsert, |
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.
In terms of stabilizing __experimentalDefaultBlock
, I think it could be worth looking at stabilizing __experimentalDirectInsert
too, as I believe the two props were designed to work together.
Perhaps if there's consensus that defaultBlock
should be added as a block attribute, the same should also apply to directInsert
. 🤔
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.
Resolved by #52083
@talldan I think we're at a point where those two "__experimental" properties have been used extensively for several releases. Based on that do you agree we can stablise them for 6.3? If so next steps would be:
|
Looks ok to stabilize to me 👍 Not sure if there's anyone else you want to run it past. I think @tellthemachines originally implemented it, but hasn't worked on these blocks for a while. |
I'll just say now that - as much as I'd like to - I will not have capacity to work on this in time for WordPress 6.3. Happy to work on it afterwards though. |
@getdave I'm not sure if you want to give first time contributors such a large ticket but I'd be happy to offer up some of our teams time to stabilize |
@sethrubenstein That would be fantastic. Thank you. I would recommend separate PRs for:
My understanding is that we would remove the prefix, but also retain the original in its entirity for backwards compatibility purposes. We would likely also add This is a procedure for legacy code, whereas in future all "experiments" will be hidden via the private apis mechanism that is now available. |
This PR might serve as an example the process - #47183. Though it's stabilizing a slightly different API, it still showcases keeping the original with the __experimental prefix but adding a deprecation message to it. |
@getdave @talldan I have a PR ready for stabilizing those API's and related selectors: #52083. I'll re-work this pr to get rid of the |
* Add new state handlers for setting Nav Menu Fixing unlocking Avoid unnecessarily effectful code Fix bug with persistent Nav block locking Reinstate effect to limit calls to selectBlock Reinstate effect to run selectively Isolate Nav specific code Refactor settings to hook Isolate Editor Canvas to component Extract mode statuses to hook Colocate editor canvas dependencies Remove requirement for Nav hook to return data Extract entire canvas to component Get blocks directly from the store Use factory to provide default editor component Extract independent components for default and wp_navigation Remove template dep from Navigation focus hook Delete redundant hook Remove need for settings prop Extract hooks to files Export boolean to avoid render Remove redundant prop and var Extract Site Editor Canvas component to file Extract factory to file Remove need to pass props to abstract component Improve abstract component and factory naming Improve usage of constants Be explicit about entity mapping in factory Remove templateType prop from SiteEditorCanvas component Improve variable naming Use more performant selector Improve documenting rule for showing appender Move Navigation specific editor settings to relevant provider Remove useSiteEditorMode hook See WordPress#39286 (comment) Reintstate bug fix with comment Fix error in rebase Add edit button Use Navigation icon and label Use correct labels * Add descriptive text as instructed See WordPress#39286 * Update edit link for Navigation post type Fixes revisions link * Fix PHPCS
…ss#51254) * Update: Adjust modal radius to be between frame and buttons. * Update changelog. * Try moving changelog.
…rdPress#51463) * Mobile - Image block - Fix issue with set width and height images * Mobile - Update changelog
Oy vey, I messed up my merge. Going to open a new pull request with this change reflecting the latest from trunk. I'll open a new PR shortly @getdave |
What?
This adds a new
defaultBlock
attribute to allow site owners to customize thecore/navigation
block experience for end users.Why?
This solves for #50982
How?
This adds a new
defaultBlock
attribute and a check for it along with a quick sanity check if it fails it falls back to theDEFAULT_BLOCK
constant.Testing Instructions
Testing Instructions for Keyboard
n/a