RadioGroup: Log deprecation warning #68067
Conversation
mirka
added
[Type] Code Quality
|
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. |
|
Flaky tests detected in a78d424. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12380096509
|
mirka
added
has dev note
# Conflicts: # packages/components/CHANGELOG.md
| since: '6.8', | ||
| alternative: 'wp.components.ToggleGroupControl', | ||
| } ); | ||
| if ( ! __shouldNotWarnDeprecated ) { |
There was a problem hiding this comment.
Adds a mechanism to suppress a confusing "double warning" coming from the ButtonGroup used internally in RadioGroup.
There was a problem hiding this comment.
React uses global variables for this purpose:
let didWarnAboutSomething = false;
function something() {
if ( ! didWarnAboutSomething ) {
didWarnAboutSomething = true;
console.error( /* ... */ );
}
}They also use Sets as didWarn* values, when they want to track a warning for each component name or something else separately.
We could use this, too, instead of the semi-official prop.
There was a problem hiding this comment.
If we decide to go the didWarn way, I think it makes sense to implement it directly in the deprecated() helper function.
There was a problem hiding this comment.
I was thinking about smarter ways to implement this mechanism when I started logging the size deprecation warnings, but came to the conclusion that an explicit prop was the only way. I am imagining consumer code like this, where the ButtonGroup warning inside the RadioGroup should be suppressed, but the standalone ButtonGroup instance should still warn:
const MyUI = () => (
<RadioGroup />
<ButtonGroup />
);I'm all ears if you have any clever ideas!
There was a problem hiding this comment.
Could component's internal context system help?
There was a problem hiding this comment.
Not in a way that's "more automatic" than the current manual prop-based system, I don't think. Also context could be problematic when render props or slots are involved (e.g. we don't want to suppress warnings on a component that the consumer passed in through a prefix prop).
| if ( ! __shouldNotWarnDeprecated ) { | ||
| deprecated( 'wp.components.ButtonGroup', { | ||
| since: '6.8', | ||
| alternative: 'wp.components.__experimentalToggleGroupControl', |
There was a problem hiding this comment.
Added the __experimental prefix for consistency.
What?
Soft deprecates (#61099) the RadioGroup component.
Why?
All remaining instances of RadioGroup in the app have been removed as of #67702.
How?
This was already passive deprecated, so just escalating the deprecation so it notifies consumers through a console warning and Dev Note.
Testing Instructions
Go to the Storybook for RadioGroup and check that the deprecation warning is being logged in dev tools.
✍️ Dev Note
The
RadioGroupcomponent has been deprecated. To be consistent with the current WordPress design system, useRadioControlorToggleGroupControlinstead.