-
Notifications
You must be signed in to change notification settings - Fork 4.7k
BorderBoxControl: Promote to stable #65586
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
Changes from all commits
b7f9af8
cd0dfa9
826febe
ea1e333
8e2e94e
ffdc78a
6b20fd8
e0db488
da75c57
d2ca3f6
4460745
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,7 +33,9 @@ export { | |
| } from './autocomplete'; | ||
| export { default as BaseControl, useBaseControlProps } from './base-control'; | ||
| export { | ||
| /** @deprecated Import `BorderBoxControl` instead. */ | ||
| BorderBoxControl as __experimentalBorderBoxControl, | ||
| BorderBoxControl, | ||
| hasSplitBorders as __experimentalHasSplitBorders, | ||
| isDefinedBorder as __experimentalIsDefinedBorder, | ||
| isEmptyBorder as __experimentalIsEmptyBorder, | ||
|
Comment on lines
39
to
41
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about those experimental utils? They are part of the component's API, but they remain experimental. Should we stabilize them as well?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is something I want to address in a follow-up. I already gave it a few iterations some time ago, and even paired on it with Marcelo over a donut chat which resulted in a draft PR I plan on reviving. There was some consensus about not exporting these from the component package, though the details remain to be discussed and iterated on. I don't think it should block stabilization of this component though.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Why, though, aren't those part of the component's public API? I'd expect it would be the other way around, and we'd figure these out first, especially if we plan not to export them from the components package / deprecate them.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Related: #61135
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not strongly opposed that that, but to answer your question, my opinion is: no, they are not part of the component's API. I think these utils shouldn't have been exported here in the first place, and it's just an odd occurrence of misplaced utils. They're definitely related to the component, in that they apply to borders, but the component is its own thing. So, the way I see it: stabilizing the component, moving the utilities somewhere else - these are separate tasks. Should they be tackled somewhat close to each other? I think so. Should one block the other? I think not. That's just my 2 cents though. I'm good to go with another approach if someone feels more strongly about it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fair enough. Let's keep the utils a separate problem and solve it as part of #61135 👍 |
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.