-
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
Components: remove createPrivateSlotFill function #67238
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: -46 B (0%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
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 looks like this idea was already floated in the original issue. The arguments given against it were code deduplication, consistency, and convenience. I don't have enough awareness of how private slot fills are used across the app, but judging only from the code changes in this PR, it doesn't seem much more complicated or boilerplate-y. It's arguably more simple because it exposes the standard privacy mechanism (Symbol) rather than blackbox it.
Would the consistency and convenience angle be mitigated by documentation perhaps? What if we documented how to do private slot fills in the README and reference guide?
@@ -84,17 +84,12 @@ export function createSlotFill( key: SlotKey ) { | |||
props: DistributiveOmit< SlotComponentProps, 'name' > | |||
) => <Slot name={ key } { ...props } />; | |||
SlotComponent.displayName = `${ baseName }Slot`; | |||
// deprecated legacy property, should use `slotFill.name` instead of `slotFill.Slot.__unstableName` |
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.
This will make it show up in IntelliSense when accessed.
// deprecated legacy property, should use `slotFill.name` instead of `slotFill.Slot.__unstableName` | |
/** @deprecated Use `slotFill.name` instead of `slotFill.Slot.__unstableName`. */ |
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 the ping 👍
I don't have any strong opinions on the API for creating private SlotFills. As @mirka notes there were discussions around it on the original PR as well as some offline conversations.
The end result, createPrivateSlotFill
, was the consensus at the time. That also involved some consideration that we weren't certain on the API or whether we even wanted to set public examples of defining private slot fills.
wpdirectory.net says that there are usages in plugins (Kubio), but they are in a safe form: ( createPrivateSlotFill || createSlotFill )( name ).
To my last point above, createPrivateSlotFill
was a private API itself, so there should be no uses of it outside the project. At least none that didn't come with the promise that it might be removed or break.
Would the consistency and convenience angle be mitigated by documentation perhaps? What if we documented how to do private slot fills in the README and reference guide?
Sounds like a plan to land this. If we're pushing this more into the public space, should it also then be documented via the Storybook too?
Since the original PR was landed, the slot/fill implementation got rewritten into TypeScript (#51350) where the Additionally I also pushed a commit now where I update the
Today this API is used at exactly two places, one in
Nice idea, implemented 👍 |
One motivation for this PR was when I was reviewing #66825 and noticed that the dataviews + components bundle includes the entire Removing or stabilizing private APIs can also have impact on bundle size. After this PR |
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.
Thank you, @jsnajdr!
The reason for the changes here makes sense. It's also nice to see the name
property stabilized.
Props for updating the documentation 🦸♂️
P.S. In the future, we could also include examples of when to use bubblesVirtually=true
vs. bubblesVirtually=false
. I always forget it 😅
We should almost always use |
However, plenty of |
In #49819 @aaronrobertshaw added private API function
createPrivateSlotFill
but on a closer look, I don't think this function does anything that the publiccreateSlotFill
couldn't do. You can create a slotfill with aSymbol
name:and if you don't expose any of the return value fields publicly, nobody unauthorized can use that slot. All you need for privacy is that the name is a symbol, because different instances of a symbol are not equal even if they have the same
description
:If the name is a string then anyone who knows the name can use it:
In this PR I'm removing
createPrivateSlotFill
and replacing usages withcreateSlotFill( Symbol() )
. The return value ofcreateSlotFill
has a newname
field that contains the name. This is commonly used withuseSlotFills( name )
. This field is supposed to replace the semi-privateslotFill.Slot.__unstableName
that's been used for this purpose until now.wpdirectory.net says that there are usages in plugins (Kubio), but they are in a safe form:
( createPrivateSlotFill || createSlotFill )( name )
.