{
  "$type": "site.standard.document",
  "canonicalUrl": "https://bradestey.com/writing/react-boolean-prop-variants/",
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreib46n5qc3hii3w2itwqmiy6ilha5wjoskjbjqcyrkbhsgbbyzkrjq"
    },
    "mimeType": "image/png",
    "size": 156904
  },
  "description": "Using a higher-order component to add boolean prop variants to React components.",
  "path": "/writing/writing/react-boolean-prop-variants",
  "publishedAt": "2025-08-09T04:00:00.000Z",
  "site": "at://did:plc:gjryzxv62p6dfiy4knry3mzt/site.standard.publication/3mn73eclrks2d",
  "tags": [
    "react"
  ],
  "textContent": "After years of using Tailwind <abbr title=\"Cascading style sheet\">CSS</abbr>, whenever I use <abbr title=\"Cascading style sheet\">CSS</abbr> Modules or go back to using styled components or basic <abbr title=\"Cascading style sheet\">CSS</abbr> I'm struck by how wordy they are. Take this block for example:\n\nAnd compare it to Tailwind <abbr title=\"Cascading style sheet\">CSS</abbr>:\n\nSo many times the value of a <abbr title=\"Cascading style sheet\">CSS</abbr> property is explicit enough to not even need the property definition. inline, block, inline-block, flex, hidden are all unique to the display property, so why not drop the display keyword all together? That's exactly what Tailwind <abbr title=\"Cascading style sheet\">CSS</abbr> does and it's great!\n\nReact Props\n\nThis is often the case with React component <abbr title=\"Application programming interfaces\">API</abbr> design as well. The shadcn/<abbr title=\"User interface\">ui</abbr> button component is a good example of this. A variant prop is used to define the type of button.\n\nVariant options include default, secondary, destructive, outline, ghost, and link. With maybe the exception of link, these prop values are all unique enough that they could be their own boolean props, simplifying the <abbr title=\"Application programming interfaces\">API</abbr> down to the bare minimum.\n\nActually implementing these boolean props can be a pain. Having to check for collisions when someone uses two of the same prop type. It also makes styling more difficult when checking a bunch of booleans rather than a single prop value.\n\nHigher-Order Components\n\nThankfully React still supports higher-order components! So a <abbr title=\"Higher-order components\">HOC</abbr> can be written to wrap an existing component to add these boolean prop variants and in the background pass the originally expected props down into the original component. This way the original component doesn't have to change at all, but the extra boolean props can be added as an additional option.\n\nBy passing an array of acceptable values, but leaving out the ones that aren't needed (Like default), this <abbr title=\"Higher-order components\">HOC</abbr> will return a new Button component with additional boolean props available. I like this solution because it doesn't impose my unique preferences onto package maintainers. You can also have multiple groups of boolean props, like if you wanted to add type or size.\n\nNPM Package\n\nI've published a small <abbr title=\"Node package manager\">NPM</abbr> package called boolean-variants that makes this possible.",
  "title": "React Boolean Prop Variants"
}