refactor(ui): use the Radio component instead of RadioGroup.Option - #3454
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe create-issue modal now uses Headless UI’s standalone ChangesIssue modal radio migration
Estimated code review effort: 2 (Simple) | ~5 minutes Suggested reviewers: Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
59e9472 to
5acf3c4
Compare
Pull Request is not mergeable
Pull Request is not mergeable
5acf3c4 to
6a95adc
Compare
The merge-base changed after approval.
|
This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged. |
v2 deprecates RadioGroup.Option in favour of Radio. The two are not drop-in as Radio defaults to rendering a span where RadioGroup.Option rendered a div, so passed `as="div"` to keep the option a block-level flex row. Radio's render prop also drops `active` entirely rather than deprecating it, so used `focus`, which is the same state under its current name.
6a95adc to
556f5a2
Compare
Description
v2 deprecates RadioGroup.Option in favour of Radio. The two are not drop-in as Radio defaults to rendering a span where RadioGroup.Option rendered a div, so passed
as="div"to keep the option a block-level flex row. Radio's render prop also dropsactiveentirely rather than deprecating it, so usedfocus, which is the same state under its current name.How Has This Been Tested?
Screenshots / Logs (if applicable)
Checklist:
pnpm buildpnpm i18n:extractSummary by CodeRabbit