fix(chipGroup): Allow variable number of chips to be displayed - #2878
Conversation
|
PatternFly-React preview: https://patternfly-react-pr-2878.surge.sh |
mcarrano
left a comment
mcarrano
left a comment
There was a problem hiding this comment.
Does this setting apply to the ChipGroup Toolbar, ChipGroup Multi-Select, or both?
|
@mcarrano the prop is on the ChipGroup component so it should work for both ChipGroup Toolbar and ChipGroup Multi-Select. :) |
|
@jessiehuff I guess that the reason I asked this question was that the default for setting how many chips to show before overflow is 3, however in the ChipGroup Toolbar example you are showing 4 chips without overflow. I would have expected to see the overflow on the fourth chip unless you set the overflow to greater. Am I understanding this correctly? |
|
@mcarrano Since the prop is on the ChipGroup component itself, it sets the children of ChipGroup to the default numChips. So in the case of ChipGroup Toolbar, it's showing 3 ChipGroupToolbarItems, not necessarily the chips inside each ChipGroupToolbarItem. |
| withToolbar?: boolean; | ||
| /** Set heading level to the chip item label */ | ||
| headingLevel?: 'h1' | 'h2' | 'h3' | 'h4' | 'h5' | 'h6'; | ||
| /** Set number of chips to show before overflow */ |
There was a problem hiding this comment.
Maybe change this to say Set number of items to show before overflow since or number of chips\chip groups to show before overflow
|
@jessiehuff @tlabaj it sounds like there is a misunderstanding about what is intended. I see this as 3 separate chip groups, not as one chip group with 3 items. I don't think we want to hide an entire category of chips. It's also the case that we would not want to show a large number of chips in a grouping even if there were less than 3 groups. Will be glad to talk this through live if that helps to clarify the intended behavior. This document talks a bit more about how I am seeing the ChipGroup from a design perspective. |
mcarrano
left a comment
mcarrano
left a comment
There was a problem hiding this comment.
After further conversations, I think that this PR satisfies it's aims within the context of the current implementation of ChipGroups. There is currently an issue open on Core to refactor implementation of Chips Groups to be more consistent with design intent as described here: patternfly/patternfly#1837
|
Your changes have been released in:
Thanks for your contribution! 🎉 |
5 participants
Fixes #1855