[Accordion] Component naming

[GomezIvann]

During the Accordion refactor to remove material and looking at many design systems, a question came to my head, why do we have two components (Accordion and Accordion Group) for the same thing?

"An Accordion is a vertical stack of interactive headings used to toggle the display of further information; each item can be 'collapsed' with just a short label visible or 'expanded' to show the full content."

After some research, I haven't found anything about an Accordion Group component, as the Accordion concept itself encompasses one to more sets of interactive headings with expandable content. Another idea that may suit better than what we are trying to represent with our current Accordion is an Expandable section/Details/Disclosure component, but that's just a thought.

Bibliography:

1. https://component.gallery/components/accordion/
2. https://www.w3.org/WAI/ARIA/apg/patterns/accordion/
3. https://ant.design/components/collapse/
4. https://carbondesignsystem.com/components/accordion/code/
5. https://www.lightningdesignsystem.com/components/accordion/
6. https://seek-oss.github.io/braid-design-system/components/Accordion
7. https://www.radix-ui.com/docs/primitives/components/accordion

[GomezIvann]

My take on this would be:

1. Remove the export of the single Accordion and rename the Accordion Group as the regular Accordion.

2. Decide if we keep each Accordion item as a compound component or as a prop accordionItems.

3. Rewrite the documentation to help the user understand what an Accordion is (we made the first step by just having a single page for both).

4. A new prop for the component to let the user decide the heading number of all of them (h1, h2, h3, etc).

5. Maybe a new component Expandable section/Details implemented with <details> and <summary> tags for an interactive element to control the visibility of content. Here are some examples:

   • https://design.wonderflow.ai/get-started/components/actions/disclosure
   • https://primer.style/react/Details
   • https://cloudscape.design/components/expandable-section/?tabId=playground
   • https://paste.twilio.design/components/disclosure/
   • https://www.lightningdesignsystem.com/components/expandable-section/

[kukoc]

My first take looking for simplicity would be to keep only the accordionItem rather than the accordion group since I am not aware of any global action applying to all of the items (we have disable, but I was thinking more of a collapseAll action for example)

Then, looking at the design system examples you shared, everybody seems to expose the accordion group instead of the individual accordion section, so that's enough for me to change my mind.

Regarding the disclosure item, I think this is a wider conversation. To delegate the visibility control of components to a higher component is something that doesn't only affect the accordion, but many others, am I right?

[GomezIvann]

If we only shared the AccordionItem we would relay the user the controlled state and that could be very dangerous (an accordion should only have one item expanded at the same time, for example). Also, they would need to change the styles of our AccordionItem to make them look cohesive when they are grouped (for example, borders should change depending on the AccordionItem positioning):

I think we need to give an opinion on all of this to avoid inconsistencies, apart from any additional functionality in the form of props that we may be able to offer.

About the Expandable Section, I agree, it's another topic to discuss, was just an idea 😬.

[raquelarrojo]

This has already been implemented. Now there is only one Accordion component that can be compound of several accordions.
The code is available here.