-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat(search): add support for expandable variant #8101
feat(search): add support for expandable variant #8101
Conversation
Deploy preview for carbon-elements ready! Built with commit f442072 |
Deploy preview for carbon-components-react ready! Built without sensitive environment variables with commit f442072 https://deploy-preview-8101--carbon-components-react.netlify.app |
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.
width: 0; | ||
padding: 0; | ||
transition-timing-function: motion(standard, productive); | ||
transition-duration: $duration--fast-01; | ||
transition-property: width, padding; |
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.
Cool, so it looks like this will inherently support animating leftwards, rightwards, or both from the center 👍
/** | ||
* Optional prop to specify the kind of this component | ||
*/ | ||
kind: PropTypes.oneOf(['default', 'expandable']), |
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.
One quick question, curious what you think between using kind
props versus named variants of a component.
e.g. we have <Search kind="expandable" />
or <ExpandableSearch />
I've definitely leaned towards the latter since the kind
prop makes it harder to group related functionality around a variant but I'm super curious what you think @janhassel
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.
Could the prop name also be something like isExpandable
?
Or we could mimic the TableToolbarSearch
prop, and use persistent
and default that to true
? (perhaps renamed in both places to isPersistent
in v11)
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.
I initially thought this variant would not be big enough to make into its own component but after looking further into some other components, maybe the guidance could be to use kind
whenever the appearance is the main differentiator and creating a new component whenever the behaviour is affected. In that case, this should be an <ExpandableSearch />
as @joshblack mentioned.
This is based on the following:
Component | kind |
wrapper | Effect |
---|---|---|---|
Button | X | Changes appearance: primary, secondary, ghost, danger | |
Notification | X | Changes apperance: success, error, warning, information | |
Tile | X | Changes behaviour: ClickableTile, SelectableTile, RadioTile | |
ContextMenu | X | Changes behaviour: ContextMenuItem, ContextMenuSelectableItem, ContextMenu |
The (somewhat) recent change in Toggle
/ ToggleSmall
also reflects this rule: #7380
Let me know what you think about this approach and I'll update the PR accordingly.
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.
@janhassel that's a great breakdown. When the prop controls behavior (or even something like markup potentially) the wrapper approach works great. If it's a visual change only (like classes) then inlining in the component makes more sense.
Following that chart, does it make sense for ExpandableSearch
to be a wrapper, or am I misunderstanding? 👀
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.
@joshblack Yes, I'd say this should be a wrapper component called ExpandableSearch
following above's approach. If you agree, @tw15egan then I'll go ahead and update the PR.
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.
Let's do it! 👍🏻
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.
@joshblack @tw15egan Just pushed an update. I tried syncing the prop types with ExpandableSearch.propTypes = Search.propTypes
which seems to work fine for validation but the storybook docs don't pick them up. Do you guys have any idea on how to solve this?
@tay1orjones Good catch! This was caused by the change class name change. Just pushed an update! |
@carbon-design-system/design just wanted to tap yall in for a sign off here Specifically want to call attention to the animation behavior where the search expands on focus -- which seems different than what we do on carbondesignsystem.com (expand on focus is better 👍🏽) |
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.
@laurenmrice Should be fixed now! |
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.
looks good 👍
packages/react/src/components/ExpandableSearch/ExpandableSearch.js
Outdated
Show resolved
Hide resolved
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.
Looking great!
bump @tay1orjones @tw15egan when you have a sec to re-review 👀 |
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.
Sorry, thought I had already put an approve on here.
The storybook prop table is a bummer but I don't think there's a workaround since it's probably blowing up react-docgen. The easiest way I know of to fix is to just copy/paste the proptypes 😞
Closes #6360
Adds an expandable variant to the search component.
Changelog
New
Changed
bx--search-magnifier
classname tobx--search-magnifier-icon
bx--search-magnifier
tobx--search-magnifier-container
– just let me know!Testing / Reviewing
When
props.kind = 'expandable'
, the search component should