-
Notifications
You must be signed in to change notification settings - Fork 9
feat: add RadioCard slot-based styling and recipe story #1726
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
base: main
Are you sure you want to change the base?
Conversation
- Add slot='card' styling to Radio component for enhanced card layout - Implement slot-based styling for icon, label, and description content - Add RadioCardGroup recipe story for experiment type selection patterns - Follow existing component patterns from Menu component slot styling - Support all radio states (selected, disabled, focus, hover) in card mode Co-Authored-By: Naomi Hironaka <[email protected]>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
🦋 Changeset detectedLatest commit: 374e709 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
Size Change: +584 B (+0.11%) Total Size: 527 kB
ℹ️ View Unchanged
|
- Wrap icon and label elements in heading slot container - Add conditional border radius styling when no description present - Update RadioCardGroup story to use new heading slot structure - Add test case without description to verify border radius behavior - Use CSS Grid layout with heading and radio areas for proper alignment Co-Authored-By: Naomi Hironaka <[email protected]>
After reading your PR description, variants came to mind, not slots. Did you consider that too and decided slots were more appropriate? |
Great question! I did consider variants vs slots and chose slots for several key reasons: Flexibility & Composition: Slots allow for much more flexible content composition. With slots, the icon, label, and description can contain any React content (custom icons, formatted text, etc.), whereas variants would typically be more restrictive with predefined styling. Existing Patterns: The codebase already uses slot-based styling patterns extensively (like in the Menu component), so this approach maintains consistency with established patterns. User Requirements: The original task specifically requested slot-based styling with Content Structure: The heading slot wrapper allows for semantic grouping of icon+label while keeping description separate, which provides better layout control and accessibility structure. Extensibility: Slots make it easier to add new content areas in the future without breaking changes to the API. Variants would have been simpler for basic styling differences, but wouldn't provide the same level of compositional flexibility that this use case requires. The slot approach follows React Aria Components' patterns and gives consumers more control over their content structure. What are your thoughts on this approach? |
(aside)
@apucacao I remember Robb saying that recipes use a composition of different components so thought that approach was more appropriate, but I guess since Radio will only be used under RadioGroup a variant would also make sense! I think we still may want to use slots for styling the labels/description/icons thoughts? |
(aside) Yeah, I think slots are still useful for passing context down to certain props and to style certain descendants of each Do we ever want to have radios that look like cards and others that do no, within the same radio group? If not, should we move the prop to the group itself? |
(aside)
So true, let me put devin to work |
- Add variant support to RadioGroup component with card variant - Update Radio component to consume variant context from RadioGroup - Convert slot-based CSS selectors to variant classes in Radio.module.css - Update RadioCardGroup story to use variant='card' prop instead of slot='card' - Maintain existing heading slot structure for content composition - Preserve conditional border radius and grid layout features Co-Authored-By: Naomi Hironaka <[email protected]>
Co-Authored-By: Naomi Hironaka <[email protected]>
- Remove JavaScript context passing from RadioGroup and Radio components - Add data-variant attribute to RadioGroup for CSS targeting - Move card styling from Radio.module.css to RadioGroup.module.css using descendant selectors - Maintain existing slot-based content structure and functionality - Use pure CSS parent-to-child styling instead of Provider/useContext pattern Co-Authored-By: Naomi Hironaka <[email protected]>
- Add subtitle slot styling to RadioGroup.module.css with secondary text color - Update selected state styling to use primary color and medium font weight - Update RadioCardGroup story to demonstrate subtitle slot usage - Maintain CSS-only approach using descendant selectors for styling Co-Authored-By: Naomi Hironaka <[email protected]>
Summary
This PR implements a CSS-only RadioCard variant for RadioGroup components using react-aria-components, replacing the previous JavaScript context-based approach with pure CSS descendant selectors.
Key Changes:
variant="card"
prop to RadioGroup that applies card styling to child Radio componentsdata-variant
attributes and descendant selectorsshortDescription
styling (secondary text color, body-2-regular font, primary color when selected)Technical Approach:
data-variant="card"
attribute on container.group[data-variant='card'] label[data-rac]
selectorScreenshots
The RadioCardGroup story demonstrates the card styling with all slot types:
Testing approaches
composition.stories.tsx
demonstrating all slot combinationsHuman Review Checklist
Additional Context