feat(accordion)!: add sections prop

[Francois-Esquire]

• BREAKING CHANGE?

Description

Adds a new sections prop to explicitly define each section. Moving forward, sections will be needed for the useAccordion container to work properly. There have been additional changes to the distribution exports.

Checklist

• 🌐 demo is up-to-date (yarn start)
• 💂‍♂️ includes new unit tests
• ♿ tested for WCAG 2.1 AA compliance
• 📝 tested in Chrome, Firefox, Safari, and Edge

[coveralls]

coverage: 95.623% (-0.04%) from 95.665% when pulling 501fe2c on mike/refactor/accordion into 8a30d4b on main.

[geotrev]

Happy to chat in more depth if anything is unclear. Thanks

[jzempel]

Why is this falling back to an expansion state on the first section? Feels like we should be accepting undefined as a valid state.

[Francois-Esquire]

Could you explain more on this? expandedState does have dependents (like disabledState, etc) which does need it to be an Array in certain conditions.

[geotrev]

Not strictly related to JZ's comment, but I would expect expandedSections to come before defaultExpandedSections - controlled value takes priority, and the default as the fallback, if given.

Getting back to JZ's comment, I'm curious on the thinking there as well. Not opposed to it, but keeping the type consistent does help with the internal logic type reliability from the get go. I could also see defaultExpandedSections having a default arg value of [] to make it simpler.

[Francois-Esquire]

Lines 31-36 use the internalExpandedState which resolves to the expandedSections before defaultExpandedSections 😄:

// lines 31-36
  const isControlled = expandedSections !== null && expandedSections !== undefined;
  const [expandedState, setExpandedState] = useState<Value[]>(
    defaultExpandedSections || sections.slice(0, 1)
  );
  const [disabledState, setDisabledState] = useState(collapsible ? [] : expandedState);
  const internalExpandedState = getControlledValue(expandedSections, expandedState)!;

On the second point, it will change the logic indeed.

[geotrev]

I like the closer alignment with with other containers a la sections. Other than JZ's remaining comments, it's looking much better!

[jzempel]

looks good, @Francois-Esquire