Further define acceptance criteria for moving components to stable

[tay1orjones]

ContextMenu has been unstable for quite some time. We need to:

• Revisit what steps/criteria are required to move a component from unstable to stable.
  • Storybook stories need playground, controls, etc.
• Document the unstable -> stable process in repo
• Validate the process by going through it with a currently unstable component:
  • ContextMenu: Bring to stable ☂️  #11770

[joshblack]

Draft

Moving a component to stable

• All files have a copyright banner
• All components exported in src/index.js and should not be unstable_ prefixed
• Component has a label in the github repository
• Component should be documented on the website
  • Component should have a usage, style, and code tab
  • Component may have a component demo
• For each component exported:
  • Component is written as a function declaration or uses forwardRef
  • Component has propTypes defined
    • Each prop type has a comment (used in storybook)
    • Prop types are as specific as needed, prefer PropTypes.shape over PropTypes.object if possible
  • Default props are listed as default args in the function definition (not in defaultProps)
    • Note: default props should be stable, in other words props like onClick = () => {} can cause re-renders since the function identity is not stable
  • Component has a story in <ComponentName>.stories.js
    • Component has an mdx document that follows our outline
    • mdx document coverages at least common use-cases and provides a prop table
    • Stories cover at least common use-cases
    • Stories may include a Playground story for controls
    • Stories should mirror intended usage of the component
  • Component has unit/integration tests written in RTL for testing the component API
  • Component is tested via VRT for at least the initial render state
  • Component is tested via AVT for at least the initial render state