Releases: springload/react-accessible-accordion
v2.2.1
Changed
- Fixes mixed up filenames in the README
v2.2.0
Added
- Demo styles added to the bundle as two optional files:
minimal-example.css: 'Minimal' theme - hide/show the AccordionBody componentfancy-example.css: 'Fancy' theme - boilerplate styles for all components, as seen on our demo
v2.1.0
Added
- Publish flow types.
Changed
- Update all React components to accept arbitrary HTMLDivElement props (eg. 'lang', 'role' etc).
- Upgrade all dev-dependencies except the eslint configs.
- Replace snapshot tests with explicit assertions in AccordionItemBody and AccordionItemTitle.
- Add specific assertions to tests in accordionStore.
- Minor syntax change in AccordionItemBody
v2.0.0
Version 2.0 represents a total refactor, with a new context-based approach which should make this library more flexible, more maintainable and more comprehensively testable.
As this is a major release, users should expect some breaking changes - though they should be limited to the removal of the activeItems prop (read more below).
Added
- Exports
resetNextId(#41).
Fixed
- Defect where controlled components' props were overridden by React.Children.map (#33).
- Defect where accordion crashed with unexpected
childrentypes (#45). - Defect where React Accessible Accordion's components could not be extended.
- Defect where the
childrenofAccordionorAccordionItemcould not be arbitrary. - Defect where
AccordionItemhad to be a child ofAccordion(as opposed to to an arbitrary-level descendant). - Defect where
AccordionItemBodyandAccordionItemTitlehad to be children ofAccordionItem(as opposed to arbitrary-level descendants).
Removed:
- 🚨 Breaking change 🚨
activeItemsproperty is no longer supported.
Control at the Accordion level (via the activeItems prop) and AccordionItem level (via the expanded prop) fought against one another, and choosing which control mechanism to give preference to would have been an arbitrary decision - and whichever way we went, we would have had test cases which demonstrated unusual/unpredictable behaviour. The activeItems mechanism was the obvious one to remove - it was arguably the "less React-y way", and we considered it more of a convenience than a feature. Crucially though, it fought too hard against the new architecture of the library, and keeping it would have prevented us enabling lots of other new features or resolving some of the issues that our users had raised.
If you're currently using activeItems, you're upgrade path might look like this:
const items = ['Foo', 'Bar'];
const activeItems = [0];
return (
- <Accordion activeItems={activeItems} />
+ <Accordion />
{activeItems.forEach((item, i) => (
- <AccordionItem key={item}>{item}</AccordionItem>
+ <AccordionItem key={item} expanded={activeItems.includes(i)}>{item}</AccordionItem>
)}
</Accordion>
);Please don't hesitate to reach out to one of the maintainers (or raise an issue) if you're having trouble upgrading - we're happy to help!