dequelabs / dequelabs/cauldron
Standardize common component props
- Dominant language
- TypeScript
- Stars
- 127
- Forks
- 31
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 8
Description
We have a number of component props that differ between their usage and aren't consistent, examples below:
## Refs
There's a mix of `[componentName]Ref` and `ref`. Generally speaking, _every_ component should be using `React.forwardRef` and standardize on allowing `ref`. This is already part of of our component guidelines so new components should already be adhering to this:
> Primitive/Pattern components should always use React.forwardRef to provide direct access to the component's primary element
However, we need to do the work to remove existing props (likely as a future breaking change) to standardize on `ref`.
## Sizing
There's a mix of "sizing" props to allow for different "sizes" of components. This differs from `variant` as variant tends to be purely aesthetic. Some examples:
* ``
* ``
* ``
* ``
* ``
* ``
For the most part we've been using `thin` to indicate a more lightweight variant, but that hasn't always worked where the smaller version was already the (e.g. `IconButton`). The current methodology of using `thin` may be limiting in the future if we need to add additional sizes later considering we're treating these sizing props as boolean values. We would not want to allow `` as that would not be a valid combination of props.
Instead, we should migrate over to using `size` to allow for greater flexibility in the future. This would allow us to better constrain our types as `size="small" size="large"` would be much easier to handle vs ``.
## Shared Component Props
When a component is "composed", we should have a scalable way of specifying props on the composed component. Some examples:
* ``
* ``
* ``
The primary issue with the specifying individual custom props is if additional props are added to the underlying component or if certain props aren't included, it makes the composed component less flexible. In some cases this may be the desired behavior, but a nested component that receives props via composition should generally have a single prop on the composed component ideally with the pattern `[componentName]Props`.
Contributor guide
Research direction
The issue names no files, tests, or entry points. Start by inventorying the component implementations and their existing ref, sizing, and composed-prop APIs, then confirm the migration decisions and breaking-change scope before changing them; done means the agreed component props are consistent and their types and usages are updated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100