feat: add new "customKey" prop to ExpandableCard

[kajalex]

Description

Adds an optional "key" prop to the ExpandableCard react component.

When using ExpandableCard as a child component to a parent that's re-rendering on prop changes, the component appears to "flicker" due to re-rendering every time the id const changes. Internally, it's set to a new uuid() on every render. We would like to provide an optional stable value via a prop so that we don't need to regenerate the id on every render.

Screenshots

The id field utilized by Button's aria-controls and the child section

(note: the framerate of the GIF recording doesn't catch the flickering super well, but it is visibly noticeable)

Testing in sage-lib

Rails:

• Navigate to Expandable Card
• See the key prop and verify that a key can be provided, which will set the id of the button element. It should be a random uuid otherwise.

React:

• Navigate to Expandable Card
• See the key prop and verify that a key can be provided, which will set the id of the button element. It should be a random uuid otherwise.

Testing in kajabi-products

1. (LOW) Updates ExpandableCard to support custom key prop for assigning IDs to child elements.
   • This is a new prop and should not have any effect on existing components. Should verify consistent behavior of ExpandableCard and Accordion

Related

https://github.com/Kajabi/kajabi-products/pull/37105

[anechol]

Thanks for adding this @kajalex.

Setting the key prop doesn't seem to work for me here as I'm only getting the uuid. If I remove the uuid and test the key alone, then the id doesn't render. However, if I change the prop's name to something like customKey then it works as expected. Do you know why this happens? I've had this issue previously with another component.

[kajalex]

@anechol interesting! I was previously attempting with id and changed it to key to avoid variable name confusion. It appears that React reserves key as a prop keyword: https://legacy.reactjs.org/warnings/special-props.html
I'll go ahead and update this PR to use customKey instead.

I've seen the pattern of passing a key={"some-value"} prop into our components elsewhere in our codebase, so I'm not sure if there are issues with those existing implementations.

[anechol]

This works, thanks a lot for this update, @kajalex

[QuintonJason]

❤️