[DTO-5100] BpkChipGroup

[Iain530]

Figma link

The BpkChipGroup is used to group a list of chips (bpk-component-chip) in either a wrapped layout or rail (single row with scroll. See image above or Figma or all examples.

Changes

• Created new component BpkChipGroup

Remember to include the following changes:

• Ensure the PR title includes the name of the component you are changing so it's clear in the release notes for consumers of the changes in the version e.g [KOA-123][BpkButton] Updating the colour
• README.md (If you have created a new component)
• Component README.md
• Tests
• Storybook examples created/updated
• For breaking changes or deprecating components/properties, migration guides added to the description of the PR. If the guide has large changes, consider creating a new Markdown page inside the component's docs folder and link it here

[Iain530]

The shape of this is a bit different to the figma at the moment but I've tried to keep it as close as possible: https://www.figma.com/file/irZ3YBx8vOm16ICkAr7mB3/Backpack?node-id=30119%3A42328&mode=dev

Currently differs by:

• icon replaced by leadingAccessoryView as this is the prop in BpkSelectableChipProps, although this could be renamed to icon for this prop if preferred.
• component instead of type but could be made to use an enum to choose from selectable, dropdown and dismissable chips.

Since these just passed through to a BpkChip component then a ...rest param seemed sensible at the time, although may not be neccessary now I'm looking back.

[mungodewar]

Following on the conversation from slack: https://skyscanner.slack.com/archives/C0JHPDSSU/p1706274673682399?thread_ts=1706259605.819169&cid=C0JHPDSSU

I’m thinking that the composable pattern is better, as the prop is a hard coupling, however, we could make it looser by the ChipGroup rendering children and managing Chip props via something like context.

eg there would be no need for the custom stickyChip code, the composition would be enough I think?

<BpkChipGroup>
    <BpkChip sticky />
    {myOtherChips.map(chip => <BpkChip {...chip} />)}
</BpkChipGroup>

The dismissed example becomes a lot more concise:

  return (
    <BpkChipGroup>
        <BpkChip disabled />
        <BpkChip dismissable />
        <BpkDropdownChip >
        <BpkChip />
        <BpkChip selected/>
    </BpkChipGroup>
  );

Semantically, the BpkChipGroup manages a group of BpkChips. This reflects other web apis like <select> and <option>.

I can think of future requirements/designs that "clumps" chips together or seperate them. Having this api allows easy extensibility & no change to BpkChipGroup would be required:

  return (
    <BpkChipGroup>
        <BpkChip disabled />
        <BpkChip dismissable />
        <BpkChipSpacer />
        <BpkDropdownChip >
        <BpkChip />
        <BpkChip selected/>
    </BpkChipGroup>
  );

or

  return (
    <BpkChipGroup>
        <BpkChipSpacer >
             <BpkChip disabled />
             <BpkChip dismissable />
        </BpkChipSpacer >
        <BpkDropdownChip >
        <BpkChip />
        <BpkChip selected/>
    </BpkChipGroup>
  );

[mungodewar]

There are a few different types of BpkChipGroup, could you give me a TLDR on when a consumer would use which one and why, are some of these just internal maybe?

[mungodewar]

I'm interested in onItemClick prop, is there a reason that we don't want that on all the different version of BpkChipGroup?

[mungodewar]

Finding: https://react-spectrum.adobe.com/react-spectrum/ActionGroup.html & how similar it is to this component, it might be worth taking a look and doing a contrast and compare to their solution - particularly around the whole api approach and how they manage it.

[Iain530]

Following on the conversation from slack: skyscanner.slack.com/archives/C0JHPDSSU/p1706274673682399?thread_ts=1706259605.819169&cid=C0JHPDSSU

I’m thinking that the composable pattern is better, as the prop is a hard coupling, however, we could make it looser by the ChipGroup rendering children and managing Chip props via something like context.

eg there would be no need for the custom stickyChip code, the composition would be enough I think?

This conversation continued on slack a bit, the main reason for having the ChipItems is to give us more control over the BpkChip components which I think we lose if they become composable?

See:

• https://skyscanner.slack.com/archives/C0JHPDSSU/p1706276915820979?thread_ts=1706259605.819169&cid=C0JHPDSSU
• https://skyscanner.slack.com/archives/C0JHPDSSU/p1706542501214379?thread_ts=1706259605.819169&cid=C0JHPDSSU

I understand this would mean it's harder to migrate to using this component though so if there's a potential middle ground where we still can have control over the props we need but with this pattern that might be ideal. Although I don't know if that's possible?

[Iain530]

There are a few different types of BpkChipGroup, could you give me a TLDR on when a consumer would use which one and why, are some of these just internal maybe?

Yes, so there are two main types MultiSelect and SingleSelect:

• MultiSelect means that any number of chips can be selected
• SingleSelect means that only a single chip can be selected (controlled through the selectedIndex prop)

These two components are not stateful so a consumer should use these if they want to manage the chip states themselves.

Then there are also stateful versions of both of these which wrap the stateless ones and make them stateful, simplifying the job of the consumer if their use case is simple. The stateful ones weren't included in the design but I needed to write them for testing anyway so it seemed like a good idea to include them. If we'd rather not though I can take them out or refactor them to use a wrapping pattern like this:

backpack/packages/bpk-component-info-banner/src/withBannerAlertState.d.ts

Line 25 in 773b1e5

declare const withBannerAlertState: <

The storybook contains examples of both single and multi select (stateful).

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.

[github-actions]

Visit https://backpack.github.io/storybook-prs/3198 to see this build running in a browser.