Query: Fix add new post link position via private SlotFill #49819
Conversation
aaronrobertshaw
added
[Type] Bug
|
Size Change: +45 B (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
It's nice that this didn't require too many modifications. I think being able to create private slots will be really useful.
I checked out the branch and tried a few things to see if there were any ways to render in the slot without unlocking the private API:
<Fill name="BlockInformation">TEST</Fill>- didn't work as expected.<Fill name={ Symbol.for( 'BlockInformation' ) }>Test</BlockInformation>- didn't work as expected, since the symbols created for the slot fill aren't in the symbol registry.
It'd be good to get thoughts from @youknowriad and @adamziel on this approach.
packages/block-editor/src/components/block-info-slot-fill/index.js
Outdated
Show resolved
Hide resolved
|
Thanks for the early review @talldan 🚀 A lot of the feedback is on my radar for further polishing before making this ready for final review. The plan is to address it all first thing next week. That said, getting some early feedback, sanity checking just how "private" the SlotFill would be sounds wise. Thanks for sending out the pings 🙇 |
|
Since this is all private, I don't mind it too much but it seems to me that if |
aaronrobertshaw
force-pushed
the
try/private-slot-fills
branch
from
af0ee96
to
57bae09
Compare
|
Thanks for weighing in @youknowriad 👍
Unfortunately, no, unless I'm missing something. If we rely on rendering the Block Styles into existing InspectorControls slots, we can't guarantee order and end up with 3rd parties easily being able to push their controls to a higher prominence than warranted and above the Block Styles. If we were to add a new InspectorControls group slot for the block styles and explicitly position that slot above the default InspectorControls slot, we end up back where we started needing the means to allow the Query block to position its additional block info (i.e. the new post link) above the Block Styles. The current approach in this PR only adds a single new SlotFill. I don't think having an additional private slot dedicated to the Block Styles only provides much value. |
|
If I'm not mistake @mtias had some resistance in the past to adding such a slot or URLs to blocks there. So, I'm just looping him in just in case. |
I'm happy to wait for @mtias to weigh in, if needed. For historical context, Matías was involved in #45437 where we explored a new slot when first rolling out the Block Inspector tabs. The concerns there were the slot being abused by 3rd parties. It was this concern that the private SlotFill aims to mitigate. It's my understanding we can accept that the private APIs lock/unlock feature is sufficient to consider the new SlotFill private and secure enough. |
aaronrobertshaw
changed the title
| @@ -115,6 +116,7 @@ function BlockInspectorLockedBlocks( { topLevelLockedBlock } ) { | |||
| className={ blockInformation.isSynced && 'is-synced' } | |||
| /> | |||
| <BlockVariationTransforms blockClientId={ topLevelLockedBlock } /> | |||
| <BlockInfo.Slot /> | |||
There was a problem hiding this comment.
Shouldn't this be above BlockVariationTransforms? Also related issue about slot in BlockCard.
There was a problem hiding this comment.
When the block inspector tabs were being introduced, we explored adding a new slot above the tabs for items that related to the block as a whole but weren't really a setting or style. At that time the direction was that it should occur the block transforms as those should still have a higher prominence.
In the Query block's use case with the "add new post" link, it doesn't particularly matter.
It's worth noting that the earlier exploration into adding a slot above the block inspector tabs was blocked due to concerns about the slot being abused by 3rd parties that might promote their controls in ways detrimental to the end-user experience. The potential "resistance" to a new slot fill here was questioned again in earlier comments on this PR. It was these concerns that drove the approach in this PR to make this proposed slot "private".
A "private" slot as proposed here wouldn't solve the need expressed in #49887 as the use case there requires it to be available for public consumption.
So that leaves me a little unsure of how best to proceed here. Some options are:
- Proceed with this private slot approach to solve the Query block's immediate need.
- Buys time to get consensus on if we are in fact happy to add a public slot
- Allows time for exploration to see if we might mitigate misuse of the public slot by filtering allowed fills or something
- It can easily be changed or removed should we land a new public slot and the private slot fills might be beneficial elsewhere.
- Shelve this fix until we get consensus on a new public slot, including what is acceptable to be added above the block transforms
- Bite the bullet and add a public slot to the BlockCard now
- Rework this PR to only add the private SlotFill feature omitting its use in the block inspector and query block for now
While I don't feel strongly, I'm leaning more towards option 1, landing this PR and iterating from there. That leaning was reinforced further after some internal discussions with @talldan.
What do you think? Are there any better options I haven't considered?
There was a problem hiding this comment.
Sounds good, thank you Aaron!
There was a problem hiding this comment.
I think it's worth landing this. There's been so much back and forth on this tiny piece of UI, it's been a lot of effort for little reward. I don't think it's worth stretching it out even further.
The implementation here looks good, it avoids introducing code that has tech debt and it can all be removed in the future if a better solution comes along, I personally see no issues.
aaronrobertshaw
force-pushed
the
try/private-slot-fills
branch
from
57bae09
to
59bbb58
Compare
|
Late to the party but I like this implementation and I'm glad to see that |
|
Out of curiosity, is creating a "private slotfill" API necessary? Could we just rely on having the locked |
I’d say it would be possible to avoid the private SlotFill API. The Private SlotFills have already been added in a few more places within Gutenberg, I think providing the API will help reduce code duplication and increase consistency & convenience. If the API isn’t something that you think fits alongside the component package’s SlotFill API, we could look at relocating it. |
Thank you for the extra context, I was not aware of this.
My comment above was mostly trying to gather more context and understand if we were talking about a single exception, or if the "private slot fill" is a repeated pattern that is worth addressing at the components' package level. I'm happy to keep it as is if we feel that's a correct decision. @youknowriad , what's your stance, as someone with tons of experience on slot fill ? |
I agree with the sentiment, but at the same time, it was previously possible to hack the I would be in favor of opening this new slot for every plugin author. If necessary, it can be wrapped into an HTML element like |
|
One thing to consider is that block info / description can be used in multiple places where you wouldn't expect to be extended — for example, on block previews that include the block description the link for the query block would never be accessible. It seems the semantics should be closely tied to the inspector rendering of this unit. |
Fixes: #49327
What?
SlotFillcomponent to allowSymbolkeys instead of string names only.BlockInfo).BlockInfocomponent as a private API in the block-editor packageBlockInfoslot in the block inspectorBlockInfofill.BlockInfofill.🤖 Generated by Copilot at e46f7af
This pull request adds a new
BlockInfocomponent that can show information about the selected block in the block toolbar. It uses a private slot-fill pair to render the component in different parts of the block editor UI. It also updates the query block UI to use the new component and improves the slot-fill module to support symbols as keys.Why?
When plugins register Block Styles for the Query block the Block Styles UI is rendered above the "Add new post" link which should sit immediately below the Block Card or the block's variation transforms if it has them.
We can't use a normal
SlotFillas anyone with that name could abuse the slot to render anything above the tabs undermining the proper prominence for controls.The proposed "private"
SlotFillis only private as far as our Private/Experimental API can make it. A determined individual can still unlock experimental or private APIs even though they shouldn't. It has been generally accepted that we can still consider anything locked via the private API, to in fact be private for our purposes.The ability to use a private
SlotFillallows us to avoid introducing block-specific code into the block-editor package simply to restore the position of the Query block's link.How?
It might be easiest to review the PR commit-by-commit as they are all pretty small and self-contained.
Next Steps
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast