dequelabs / dequelabs/cauldron

Standardize common component props

Open
#1,423 0 comments 0 reactions 0 assignees View on GitHub
breaking enhancement rfc
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.