Composable Tailwind

A guide to composing Tailwind CSS classes in JSX

2-3 minute read

Guide ->

Tailwind CSS is one of the most popular Atomic CSS frameworks. The API is excellent, adding minimal mental overhead and no code bloat once set up. Their documentation is extensive, covering their API, as well as nearly all other use cases imaginable.However, there is a relatively common issue that is not mentioned – one that is inherent to all class-based styling solutions in JSX1. This issue is composing styles.

Utility classes work great when there is a single source of truth for styling. However, once faced with more complex scenarios such as conditional styling or prop-based styling, one can easily end up with a mess of template literals:

  className={`m-4 p-4 ${condition1 == true ? 'text-white' : 'text-black'} ${
    condition2 == true ? 'bg-white' : 'bg-black'

The above can quickly become unreadable.

Fortunately, there are other ways we can approach this. As I have previously proposed in my guide to CSS Modules, we can instead reach for string concatenation to compose classes. The above example would now look like this:

    'm-4 p-4',
    condition1 == true ? 'text-white' : 'text-black',
    condition2 == true ? 'bg-white' : 'bg-black',
  ].join(' ')}

This approach brings a few clear benefits to the table:

  • More readable code
  • Grouping by source
  • Clear order of execution2

Let us apply this to a real-world example. We'll have a button with two variants (primary and secondary), with an escape hatch for the possibility of customising the button, should that be necessary (this happens more often than you would expect).

// Button.tsx
type ButtonProps = {
  variant: 'primary' | 'secondary'
  className?: string

export const Button: React.FC<ButtonProps> = ({
}) => (
      'rounded border border-black px-8 py-4',
      variant == 'primary' ? 'bg-black' : 'bg-inherit',
    ].join(' ')}

Now we can consume this button as expected:

<Button variant="primary" className="mt-4">


  1. This is not an issue with CSS-in-JS styling solutions, such as Stitches. While they compile down to classes at the end of the day, the authoring is done as individual styles (in JS Object format), which are much easier to compose.

  2. What is meant by this is that the styles at the end override the styles at the beginning.

Last Updated:

Edit on GitHub ->