Toggle a pattern category to enable/disable it

[andrewserong]

What problem does this address?

When a user selects a pattern category in the pattern inserter, an additional sidebar opens up on the left that lists out all the patterns within that category. Once that sidebar is open, it doesn't appear to be possible to close it unless you close the overall inserter.

What is your proposed solution?

It should be possible to close the additional left-hand sidebar that previews the patterns within the selected category. For example, what if clicking on the pattern category toggles the sidebar closed again?

Here is a quick screengrab of the current behaviour:

2024-09-19.11.19.02.mp4

[ntsekouras]

Currently pattern categories use tabs and I'm not sure the toggling on click is part of the Tabs pattern. I'll cc @afercia and @ciampo for possible feedback.

Could a close (x) button in the opened tab work for this use case?

[afercia]

I'd argue the Tabs pattern is broken anyways as there should always be an 'active' tab and an opened Tabpanel.

https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

When a tabbed interface is initialized, one tab panel is displayed and its associated tab is styled to indicate that it is active [...]

[ciampo]

The suggested behaviour

It should be possible to close the additional left-hand sidebar that previews the patterns within the selected category.

Is technically possible by setting the selectedTabId prop on the Tabs component to null, which means there's no selected tab, which means that there's no visible tabpanel.

For example, what if clicking on the pattern category toggles the sidebar closed again?

I would recommend against this since tab buttons are not expected to be "toggleable"

Could a close (x) button in the opened tab work for this use case?

That would be a better behaviour — basically clicking the close button would somehow change the value of the selectedTabId prop on the Tabs component to null.

Having said that, I'm not sure if having no selected tabs at any given time is a good idea in terms of accessibility / UX (including the initial tab), as @afercia mentioned above. (cc @diegohaz — maybe you have a good example of when having no selected tabs is appropriate?)

[diegohaz]

cc @diegohaz — maybe you have a good example of when having no selected tabs is appropriate?

It's less common, but I can think of use cases where having no default selected tab can reduce bloat when the tabs widget is secondary or auxiliary content.

For example: https://rsc-parser.vercel.app

[afercia]

The provided example at https://rsc-parser.vercel.app/ isn't appropriate. Actually, there is always an active Tabpanel there. The initial one is the one that contains the text 'Please select a chunk'.

I would recommend against closing all tabs ant not having one that is always visible. As mentioned, that breaks the Tabs pattern and it's just not the expected behavior.