-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Stabilize LinkControl
Component
#56384
Conversation
At the same the this retains the experimental versions of the exported component for better backwards compatibility for the wide usage of the LinkComponent already out there
Size Change: +121 B (+0.01%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
Flaky tests detected in 3c1b6a2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6944693938
|
I would defer to @getdave and @richtabor on this one. I believe there's still some ongoing work to polish the component. |
This component has existed in Gutenberg for a long time as experimental. However in many ways it could be considered a public API because it's been adopted and used by many extenders (as it was available prior to the advent of the private APIs system). The component is still undergoing a round of polish. Once we make this stable changes to the API will be officially disallowed if they break backwards compatibility. On the other hand, this component is already heavily used and thus changes to the API may already be considered "breaking". Also interested to hear Rich's thoughts on this. |
I agree with all of this. My take is that even in the multiple refactors / UI Polishes this component has already seen in the 3 years since it was introduced as So essentially in all but name the component already is stabile in core and has been for the last 3 years. Which is why I created this PR to make that commitment official :) |
We should revisit this. This is the control extenders should be using, and having it be experimental leads developers to build their own. What do you think @fabiankaegy @richtabor @getdave? |
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. |
I've been trying to get this stabilized since September 2021. The API hasn't changed since then and it is widely adopted :) I'm all for releasing it finally. I know @richtabor was against it for a while so I am looking to his guidance :) |
I think given it's been around for so long it's pretty much defacto stable anyway. We should formalise that. The last 2 releases saw a lot of UX work going on here so @richtabor and I were reluctant to stablise whilst that was happening. Now we're in a better place I'd be ok to stablise. |
# Conflicts: # packages/block-library/src/button/edit.js # packages/block-library/src/navigation-link/link-ui.js
This PR has been updated to only stabilize the |
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 look good. No longer exporting sub components. Tested and all instances are still working.
Thanks for pushing this forward.
I wonder if we should deprecated the experimental exports for the sub components (without exposing them as stable) |
@youknowriad done in ae6170a |
Thanks :) |
Co-authored-by: fabiankaegy <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: ndiego <[email protected]>
What?
Stabilize the
LinkControl
component. (Closing #35073)Why?
Looking at the usage stats there are over 200 plugins in the official Repo already using the component in its current
__experimental
state. Many of which have a really large user base.Regardless of us continuing to evolve the actual UI of the component, I think it is way past time for us to stabilize the API of the component.
How?
Changes the default export of the component to no longer use the
__experimental
prefix whilst at the same time adding new additional pass-through components that contain a deprecation warning for anyone using the__experimental
version of the component.Testing Instructions
Ensure the Button Block or adding a link inside a paragraph for example still functions as expected.