DEV Community: Nikolaus Rademacher

A simple strategy for structuring TailwindCSS classnames

Nikolaus Rademacher — Tue, 13 Apr 2021 19:02:15 +0000

This is the third article of my small series about TailwindCSS. If you have not done so already, check out my other posts.

Anyone who has proposed to use TailwindCSS for their project has probably heard something like this:

"Ugh, this looks like inline styles!"

"How should I keep an overview with so many classnames in my component?"

"This seems hard to maintain…"

Yes, I understand these concerns. With Tailwind's utility-first approach, the default procedure is to write any utility-classname directly into the component's markup. With more complicated components this can quickly come out of hand.

In today's post, we will look at a possibly better solution which I am using for my projects for a while now.

A simple example

Let's take this Navigation component as an example:

const Navigation = ({ links }) => {
  const router = useRouter()
  return (
    <nav className="container">
      <ul className="flex flex-col justify-end list-none sm:flex-row">
        {links.map((link, index) => {
          return (
            <li
              key={index}
              className="mb-3 sm:ml-3 sm:mb-0 even:bg-gray-50 odd:bg-white"
            >
              <a
                className={`text-black font-bold inline-block rounded-full bg-yellow-400 py-1 px-3 ${
                  router.pathname === link.path
                    ? 'text-white'
                    : 'hover:bg-yellow-500'
                }`}
                href={link.path}
              >
                {link.name}
              </a>
            </li>
          )
        })}
      </ul>
    </nav>
  )
}

What can we do to not let the component look so messy?

My first rule of thumb is: Do any calculations before your render / return function and only use these calculated flags in your render. That applies for the router.pathname === link.path condition – let's move it into a const and name it isActive.

And while we are at it, let's move the className definitions to consts as well – just name them after their according HTML element (another reason for using semantic elements instead of a bunch of divs ;)):

const Navigation = ({ links }) => {
  const router = useRouter()
  const navClassNames = 'container'
  const listClassNames = 'flex flex-col justify-end list-none sm:flex-row'
  return (
    <nav className={navClassNames}>
      <ul className={listClassNames}>
        {links.map((link, index) => {
          const isActive = router.pathname === link.path
          const listItemClassNames =
            'mb-3 sm:ml-3 sm:mb-0 even:bg-gray-50 odd:bg-white'
          const anchorClassNames = `text-black font-bold inline-block rounded-full bg-yellow-400 py-1 px-3 ${
            isActive ? 'text-white' : 'hover:bg-yellow-500'
          }`
          return (
            <li key={index} className={listItemClassNames}>
              <a className={anchorClassNames} href={link.path}>
                {link.name}
              </a>
            </li>
          )
        })}
      </ul>
    </nav>
  )
}

That looks better already, but there’s still room for improvement.

Use `.join(" ")`

Instead of writing long strings of classNames, let's write arrays and concatenate them automatically. The good thing about arrays is that you can also add entries conditionally – and therefore get rid of the template literal condition:

const Navigation = ({ links }) => {
  const router = useRouter()
  const navClassNames = 'container'
  const listClassNames = [
    'flex',
    'flex-col',
    'justify-end',
    'list-none',
    'sm:flex-row',
  ].join(' ')
  return (
    <nav className={navClassNames}>
      <ul className={listClassNames}>
        {links.map((link, index) => {
          const isActive = router.pathname === link.path
          const listItemClassNames = [
            'mb-3',
            'sm:ml-3',
            'sm:mb-0',
            'even:bg-gray-50',
            'odd:bg-white',
          ].join(' ')
          const anchorClassNames = [
            'text-black',
            'font-bold',
            'inline-block',
            'rounded-full',
            'bg-yellow-400',
            'py-1',
            'px-3',
            isActive ? 'text-white' : 'hover:bg-yellow-500',
          ].join(' ')
          return (
            <li key={index} className={listItemClassNames}>
              <a className={anchorClassNames} href={link.path}>
                {link.name}
              </a>
            </li>
          )
        })}
      </ul>
    </nav>
  )
}

(One note concerning the ternary operator that conditionally adds a className: If you don't have an either/or operation, just add an empty string to the else case (e.g. isCondition ? 'myClass' : '') and don't rely on shorthands like isCondition && 'myClass'. The latter would work for undefined values but add a "false" string to your array in case the condition is false.)

Abstract all component styles into a `styles` object

Let's further work on this approach: In this example with multiple elements in one component especially it might make sense to create a styles object outside of the component's return functions.

But there is one issue: In our anchor link styles definition we rely on having access to the isActive flag. We can easily solve this by transforming its definitions from a string to an arrow function returning a string. With such a function you can provide any condition you need in the scope of your element's styles array:

const styles = {
  nav: 'container',
  ul: [
    'flex',
    'flex-col',
    'justify-end',
    'list-none',
    'sm:flex-row',
  ].join(' '),
  li: [
    'mb-3',
    'sm:ml-3',
    'sm:mb-0',
    'even:bg-gray-50',
    'odd:bg-white',
  ].join(' '),
  a: ({ isActive }) =>
    [
      'text-black',
      'font-bold',
      'inline-block',
      'rounded-full',
      'bg-yellow-400',
      'py-1',
      'px-3',
      isActive ? 'text-white' : 'hover:bg-yellow-500',
    ].join(' '),
}

const Navigation = ({ links }) => {
  const router = useRouter()
  return (
    <nav className={styles.nav}>
      <ul className={styles.ul}>
        {links.map((link, index) => {
          const isActive = router.pathname === link.path
          return (
            <li key={index} className={styles.li}>
              <a className={styles.a({ isActive })} href={link.path}>
                {link.name}
              </a>
            </li>
          )
        })}
      </ul>
    </nav>
  )
}

Another note here: I've put the flag into an object instead of directly into the arguments list (({ isActive }) instead of (isActive)). This makes sense because it is easier to maintain: Otherwise you would have to think of the particular order of your flags in both the function call and its definition within the styles object. With the object's destructuring syntax you can work around this issue and don't need to worry about the object entries' positions – by just adding two more characters.

Put styles into a separate file

I you want to take it even further, you could outsource your styles to a separate file with the same approach:

// Navigation.styles.js
export default {
  nav: 'container',
  ul: [
    'flex',
    'flex-col',
    'justify-end',
    'list-none',
    'sm:flex-row',
  ].join(' '),
  li: [
    'mb-3',
    'sm:ml-3',
    'sm:mb-0',
    'even:bg-gray-50',
    'odd:bg-white',
  ].join(' '),
  a: ({ isActive }) =>
    [
      'text-black',
      'font-bold',
      'inline-block',
      'rounded-full',
      'bg-yellow-400',
      'py-1',
      'px-3',
      isActive ? 'text-white' : 'hover:bg-yellow-500',
    ].join(' '),
}

// Navigation.jsx
import styles from "./Navigation.styles";

const Navigation = ({ links }) => {
  const router = useRouter()
  return (
    <nav className={styles.nav}>
      <ul className={styles.ul}>
        {links.map((link, index) => {
          const isActive = router.pathname === link.path
          return (
            <li key={index} className={styles.li}>
              <a className={styles.a({ isActive })} href={link.path}>
                {link.name}
              </a>
            </li>
          )
        })}
      </ul>
    </nav>
  )
}

I'm working with this approach for a while now and I really like it. It's simple and clean and it allows me to write TailwindCSS without cluttering my components with a bunch of classnames.

Other approaches

There are some other approaches that you can use instead or in combination with the above:

Use `classnames()` (or `clsx()`)

The classnames() library is a simple utility to concatenate your classNames into a string. It has some additional functions built in that might come in handy.

clsx() has the same API but comes with a smaller bundle size:

These libraries makes sense especially when dealing with many conditions like the isActive one in the example above or with nested arrays that you would need to flatten otherwise.

For most cases I'd say that joining an array like above will do the work and that you don't need any additional package for that – but for bigger projects it might make sense to embrace the API of those libraries.

brise

Another interesting approach is pago's brise:

https://github.com/pago/brise

It is using template literals to work with Tailwind styles. And it even allows you to add custom CSS by using emotion's css utility.

It's also definitely worth checking out.

I hope this post inspired you writing cleaner components when using TailwindCSS. If you have any other recommendations feel free to add them to the comments!

Why you don't need every CSS pseudo-selector in Tailwind CSS

Nikolaus Rademacher — Mon, 05 Apr 2021 09:37:27 +0000

Tailwind is great. And it is often misunderstood. If you want to know why Tailwind doesn't have a lot to do with CSS inline styles, read my previous post.

But today it's about something else: People often get confused when it comes to CSS pseudo-selectors in Tailwind.

Tailwind supports the most important pseudo-selectors out of the box, e.g. :hover, :focus and :active. You may use these selectors as "variants" in front of your utility-class like this:

<button class="bg-black hover:bg-gray-500 text-white">
  my button
</button>

As expected, this example would add a gray background on hover to your button element.

It makes sense to use Tailwind variants for different states (e.g. active, hover, visited, focus, …), as rebuilding these states via JavaScript will not give you the same performance. But when it comes to other pseudo selectors than these, it is at least worth discussing:

`::before` and `::after` elements in Tailwind

::before and ::after elements are not supported by Tailwind out of the box. While you can add them via plugins, I would not recommend doing so.

Let's think about what these CSS selectors do: They render pseudo elements that are not directly visible in your DOM. Traditionally this makes sense in order to keep the markup clean. But: "Utility-first" means "component second". And the component abstraction allows us to put any element inside.

Take an external link for example: If you want to add a right arrow (→) after the link, traditionally you could do this with the ::after selector:

/*a*/.external-link {
  text-decoration: underline;
  color: red;
}
/*a*/.external-link::after {
  content: '\u2192';
  color: gray;
}

Nowadays, creating an <ExternalLink> component with Tailwind and React for example would look somewhat like this:

const ExternalLink = ({ children, href }) => (
  <a href={href} classNames="underline text-red-500">
    {children}
    <span className="text-gray-300" aria-hidden="true">
      &#8594;
    </span>
  </a>
);

It is perfectly fine to add an additional element to your render function. Just remember to add an aria-hidden attribute to make the element invisible to screen readers and search robots, just like CSS pseudo-elements would be.

The component would be used like this:

<ExternalLink href="https:://site/path">Link text</ExternalLink>

Numeric operators (`nth-child()`) in Tailwind**

Next, let's have some fun with numbers: What if you want to style a list with alternating background colors? Traditionally with CSS, you would probably do something like this:

li:nth-child(even) { background-color: gray; }
li:nth-child(off) { background-color: white; }

Well, Tailwind got you covered and provides variants for this:

<li class="even:bg-gray-500 odd:bg-white">

Since even: and odd: variants are not enabled by default, you need to configure them in your tailwind.config.js file. Just remember that every variant will increase the size of your CSS output.

Similarly you may activate first: and last: variants if you want to target the first or last element like you would traditionally do with the CSS :first-child and :last-child selectors.

However, if you want to do special ones like nth-child(myIndex) or nth-child(myFormula) (e.g. nth-child(3n+1)), you won't find any Tailwind variants for that.

But: "Utility-first" also means "component second": You will almost certainly use a component abstraction for your Tailwind styles anyways – be it React, Angular, Vue, Svelte or anything else.

Having a component stitched together via JavaScript also means that you already have a place where to put programming logic. So if you don't want to increase your output CSS file size by adding Tailwind variants for every possible utility-class, you actually don't need to do so.

Take the list example: In React, you will probably use a .map() function to map over the list items. Just add the index as the second argument to your arrow function and use it to create booleans (flags) that you can use in your classNames array:

const MyList = ({ items }) => {
  const renderListItems = (item, index) => {
    const isSecond = index === 1;
    const isThird = index === 2;
    const classNames = [
      isSecond && "bg-gray",
      isThird && "bg-white"
    ].join(" ");
    return <li className={classNames}>{item.text}</li>;
  };
  return <ul>{items.map(renderListItems)}</ul>;
};

Admittedly, this example seems a lot more complex than the CSS one, but sometimes using JS logic gives you more flexibility than using CSS logic. This makes sense especially when you need to target the same elements in your JavaScript code anyway – why duplicate this logic in your CSS file? And with the utility-first approach this is perfectly fine as everything will be abstracted away into your component anyway.

Using array as the third argument of your map function you could also target the last element of your list like this:

const MyList = ({ items }) => {
  const renderListItems = (item, index, array) => {
    const isFirst = index === 0;
    const isLast = index === array.length - 1;
    const classNames = [
      isFirst && "bg-gray",
      isLast && "bg-white"
    ].join(" ");
    return <li className={classNames}>{item.text}</li>;
  };
  return <ul>{items.map(renderListItems)}</ul>;
};

So you might not need to activate any needed variant in Tailwind. Just weigh CSS output size against JavaScript complexity. Not only when using JS to build static HTML pages the latter might even be an advantage.

So yes, you actually do not need any CSS pseudo-selector when using Tailwind and a component abstraction :)

Concerns?

But CSS rendering is quicker than JavaScript rendering!

Yes, that's true in most cases. especially for interactive states like :active, :hover, :visited – that's why I would always recommend using Tailwind variants for these.

But when it comes to pseudo-elements (::before and ::after) or numeric operators (:nth-of-child, ::last-of-type, ...), it doesn't make a difference, because you are already using JavaScript for rendering the component and mapping over its children anyway. In fact it's probably even quicker as you don't need to rely on CSS overwrites and can avoid CSS specificity issues.

But I don't like to flood my component's markup with thousands of classnames!

Well, stay tuned for my next post with strategies for structuring Tailwind classes then ;)

Why Tailwind's utility-first approach is more than inline styles

Nikolaus Rademacher — Mon, 22 Mar 2021 18:54:33 +0000

We are using Tailwind CSS for our company's internal design system for over a year now and it is doing its job perfectly. Although most devs new to Tailwind are sceptical in the beginning, they embrace the setup after having written their first components with it, especially as it makes so much sense in a constrained environment like a design system.

In this post I want to explain my take on Tailwind's utility-first approach and what is doesn't have to do with inline styles…

Historically styles were abstracted away into CSS classes...

Historically, CSS styles have been abstracted away into a CSS class in order to be easily used in the HTML markup:

.my-component {
  width: 100%;
  padding: 1.25rem;
  border-radius: 9999px;
  background-color: black;
}

.my-component--text {
  color: white;
  font-weight: bold;
}

So whenever you wanted to use these styles in your components, you would simply add their classnames to their corresponding HTML elements like this:

<div class="my-component">
  <strong class="my-component--text">Hello world</strong>
</div>

This especially makes sense as defining styles with inline style attributes would lead to unnecessary duplication, bad readability and poor maintainability of your components.

... but nowadays the abstraction is the component

With modern JavaScript frameworks and libraries like React, Vue, Angular or Svelte, there is another abstraction: the component.

The above example in React could be abstracted away like this:

const MyComponent = ({ children }) => (
  <div class="my-component">
    <strong class="my-component--text">{children}</strong>
  </div>
);

So now, when using the component you don't need to think about its styles at all. Just write:

<MyComponent>Hello world</MyComponent>

This approach led to a mind shift in using CSS. Suddenly, even inline-styles made sense again: There is no need to abstract away style definitions, as they will only be written once – within the component itself.

The Tailwind approach

Tailwind provides many CSS classes that almost always do only one thing. These classes are referred to as utility classes. As their purpose is so limited they are perfectly suited to be reused in many places:

Utility class	CSS Properties
`.w-full`	`width: 100%;`
`.w-auto`	`width: auto;`
`.mt-5`	`margin-top: 1.25rem;`
`.mb-5`	`margin-bottom: 1.25rem;`
...	...

But this is just a fancy way of writing inline styles, isn't it?

People keep comparing Tailwind utility-classes to inline styles and I certainly get their point. But there is a huge difference: Tailwind classes are constrained by what you define in Tailwind's configuration file:

In the configuration you will define your colors, spacings, fonts, sizes and so on that will be transformed into utility classes. This means that when sticking to Tailwind classes, you can't just write any style you like but you are constrained to what has been defined before. This is a huge difference.

In a design system you may think of the Tailwind's configuration as the "tokens" that are then used to create components.

The component above with Tailwind would look something like this:

const MyComponentWithTailwindStyles = ({ text }) => (
  <div className="w-full p-5 rounded-full bg-black">
    <strong className="text-white font-bold">
      {text}
    </strong>
  </div>
);

Also check the Tailwind docs for a more comprehensive explanation: https://tailwindcss.com/docs/utility-first

What's your take on Tailwind?