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
children
types (#45). - Defect where React Accessible Accordion's components could not be extended.
- Defect where the
children
ofAccordion
orAccordionItem
could not be arbitrary. - Defect where
AccordionItem
had to be a child ofAccordion
(as opposed to to an arbitrary-level descendant). - Defect where
AccordionItemBody
andAccordionItemTitle
had to be children ofAccordionItem
(as opposed to arbitrary-level descendants).
Removed:
- 🚨 Breaking change 🚨
activeItems
property 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!