Add support for DropdownV2 to have categories

[meganwalker-ibm]

Summary

In Dropdown we managed to get categories of items rendered like so, by using fake items in the data structure, and ignoring the click events etc.

(This example is from existing public functionality and shows a list of places a slack message could be sent. After the end of the list of channels, you see the category heading 'USERS' followed by a list of selectable user options).

In DropdownV2 we have to pass in just an array of plain objects that, as far as I can see, have no way of specifying categories. We need to be able to specify categories to migrate to DropdownV2. Ideally we don't want to have to hack them in either, but instead have first class support like the Select component does.

Justification

Dropdown is disappearing, and being replaced with DropdownV2. This would also provide feature parity with the Select carbon component.

Desired UX and success metrics

Items should be able to be grouped under unselectable categories. This provides structure to what could be a long list of otherwise indistinguishable options. Ideally it should look similar to what we have for our existing Dropdown usage.

"Must have" functionality

• Ability to provide category information in some format.
• Categories should not be selectable
• Categories should be rendered differently to provide differentiation.

Specific timeline issues / requests

Before Dropdown disappears.

Available extra resources

It's unclear if we'll have the time or resource to implement such functionality ourselves - even if we can reach an agreement here for how categories should be injected and styling should look.

[joshblack]

cc @IBM/carbon-designers to weigh in on if we're supporting this pattern in Dropdown, or if this should be a select use-case 👍

[lovemecomputer]

@meganwalker-ibm cool yeah, this functionality would be rad! like @joshblack said yeah design will weigh in on this, and determine if we would just do this implementation or if it could fit in the context of other patterns :) but if y'all end up with a new component/option to commit, we'll definitely look at that too!

[meganwalker-ibm]

Thanks folks! I shall await some design input :)

[designertyler]

@meganwalker-ibm This make sense as an improvement. Thanks for the suggestion! We will probably want to align the category label type to the other labels in the system (semi-bold, sentence case, and text-01 color) and see how spacing could help group the categories. Maybe a line between categories could help, too.

[aagonzales]

Yes, I agree with @designertyler it needs a little polish. Except I hesitate to use semi-bold for categories since it could be mistaken for a selected state because of its emphasis.

Or if they don't need labels maybe just dividers to show association, like on os menu. Just some ideas

[meganwalker-ibm]

Headers are essential for our use-cases

[aagonzales]

Sure, I was merely showing other ways of addressing the situation and other enhancements we could make to the component. You may only need one solution but our job is the think of it from a holistic system approach.

[meganwalker-ibm]

What's the possibility of getting this implemented before Dropdown is removed in the next major release? As it's a blocker for us moving we'd end up having to stay behind if Dropdown is removed before this is implemented.

[chrisconnors-ibm]

@meganwalker-ibm the Open Source model we're operating under assumes teams out in the world who need specific deviations from existing components design, develop, and submit them back for consideration to include in our master branch. It's the only way we can scale our system to accomodate the breadth of needs in our organization. so if there are immediate needs by external teams, they are encouraged to create issues, design and build what they need, and submit them back to us in a pull request.

If teams don't have that capability at all (no designers or FEDs), an issue like this one is subject to our broader priorities, which right now are very oversubscribed, so it'd be hard to estimate a timeframe for turn around on something like this. cc @alisonjoseph

[aagonzales]

Dropdown is NOT being removed in the next major release. Its being updated.

[joshblack]

@aagonzales this is around our migration from the Dropdown to DropdownV2 component in Carbon X 👍

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. Thanks for your contributions.

[carbon-bot]

Hi there! :wave: If you're wondering why this issue was moved, we're currently updating our repo structure so that every package is found in the same project.

This should not have any impact for you, but we wanted to give you a heads up in case you were wondering what is going on. If you have any questions, feel free to reach out to us on Slack or contact us at: [email protected]. Thanks!

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[stale[bot]]

As there's been no activity since this issue was marked as stale, we are auto-closing it.

[ashharrison90]

Hi, can someone reopen this issue? I'm about to start work on it. In terms of implementation, my initial thought is something like passing a categoryKey to Dropdown

So say your items look something like:

const items = [
  {
    id: 'germany',
    text: 'Germany',
    continent: 'Europe',
  },
  {
    id: 'uk',
    text: 'United Kingdom',
    continent: 'Europe',
  },
  {
    id: 'china',
    text: 'China',
    continent: 'Asia',
  },
  {
    id: 'japan',
    text: 'Japan',
    continent: 'Asia',
  },
];

Then you'd have:

<Dropdown
  ...normalProps
  categoryKey='continent'
\>

And Dropdown would then group options under the category headers of Asia and Europe.

How does this sound?

[ashharrison90]

which ends up looking something like this:

[asudoh]

@carbon-design-system/design Are we still interested in this feature? Thanks!

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[tw15egan]

@joshblack this still something we plan on supporting? Looking at https://github.com/carbon-design-system/carbon/pull/4449 and trying to see what the next step is for this feature

[joshblack]

@tw15egan I think we definitely want to, but IIRC there were some issues with a11y that @dakahn flagged. I think on our end we wanted to fix up the a11y issues in these components first and then move forward with category support emulating: https://dequelabs.github.io/combobo/demo/ but I'm not sure if there was a hiccup with that and screen readers, or not, so will defer to DA 🤔

[dakahn]

We need to figure out which dropdown menu style components should have category support and which should not. Category support will be tricky to get right from an accessibility perspective (functioning cross browser, cross screen reader, cross platform).

Actually @joshblack last I remember us discussing this we did not want to move forward with categories in Dropdown and wanted to point interested users toward another component? @abbeyhrt pinging you in here since I remember you being part of this discussion

[joshblack]

@dakahn if I understand correctly, I think most variants could need category support, including:

• Listbox (dropdown)
  • Single select
  • Multi select
• Combobox
  • Single select
  • Multi select

Not sure about other components, I think we'd need to include them here unless we're unable to make them work accessibly 🤔

[designertyler]

Next steps for design is to define rules for usage and final spec. Maybe look at existing components with category labels.