Component patterns (3): Boolean props
When we translate ideas from design tools into code, it’s tempting to map things directly. If Figma has a boolean property, why not add the same boolean prop in React? It feels like a straightforward approach. But while this works well in design files, in code it often creates APIs that are harder to use, maintain, and extend.
Boolean props in design tools vs. code
In Figma, boolean properties like hasIcon or hasLabel feel natural. They are switches that designers can flip on and off. In React, though, these booleans usually lead to APIs that are rigid and unclear.
Why avoid booleans in code
Boolean props look simple at first, but they cause problems as soon as you scale:
- They create too many conditional paths.
- They make the API harder to understand.
- They don’t scale when more states are added.
- They obscure what will actually be rendered.
Example:
<Checkbox isIndeterminate={true} checked={true} />
// Which icon should render? Checked or indeterminate?A better API
Instead of stacking boolean props, I prefer a single, descriptive prop:
<Checkbox checked="indeterminate" />
// checked can be: 'checked' | 'unchecked' | 'indeterminate'This makes the component easier to read, keeps the state explicit, and avoids conflicts between props.
Props vs. Composition
| Aspect | Props (Current) | Composition (Proposed) |
|---|---|---|
| Ease of use | Simple for basics | Slightly more setup |
| Flexibility | Limited to predefined cases | Fully flexible layout |
| API complexity | Grows over time | Stays minimal |
| Custom content | Hard to support | Very easy |
| Boolean props | Common but risky | Avoided |
| React alignment | Less aligned | Fully aligned |
Conclusion
It’s not a 1:1 translation from Figma to React. Booleans are fine in design tools, but in code they create more problems than they solve. Using explicit values or composition keeps APIs clean, predictable, and aligned with React’s model.