Reusing Styles

    Managing duplication and creating reusable abstractions.

    Tailwind encourages a utility-first workflow, where designs are implemented using only low-level utility classes. This is a powerful way to avoid premature abstraction and the pain points that come with it.

    But of course as a project grows, you’ll inevitably find yourself repeating common utility combinations to recreate the same design in many different places.

    For example, in the template below you can see the utility classes for each avatar image are repeated five separate times:

    Don’t panic! In this guide, you’ll learn about different strategies for reusing styles in your project, as well as best practices for when to employ each one.

    A lot of the time, duplication like this isn’t even a real problem because it’s all together in one place, or doesn’t even actually exist because you’re iterating over an array of items and only writing the markup once.

    If the styles you need to reuse only need to be reused within a single file, multi-cursor editing and loops are the simplest way to manage any duplication.

    When duplication is localized to a group of elements in a single file, the easiest way to deal with it to use to quickly select and edit the class list for each element at once:

    Reusing Styles - 图2

    2.   <a href="/dashboard" class="font-medium px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900">Home</a>
    3.   <a href="/team" class="font-medium px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900">Team</a>
    4.   <a href="/projects" class="font-medium px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900">Projects</a>
    5.   <a href="/reports" class="font-medium px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900">Reports</a>
    6. </nav>

    You’d be surprised at how often this ends up being the best solution. If you can quickly edit all of the duplicated class lists simultaneously, there’s no benefit to introducing any additional abstraction.

    Before you assume you’re going to need to extract a component or create a custom class for something, make sure you’re actually using it more than once in your template.

    A lot of the time a design element that shows up more than once in the rendered page is only actually authored once because the actual markup is rendered in a loop.

    1. <div>
    2.   <div class="flex items-center space-x-2 text-base">
    3.     <h4 class="font-semibold text-slate-900">Contributors</h4>
    4.     <span class="rounded-full bg-slate-100 px-2 py-1 text-xs font-semibold text-slate-700">204</span>
    5.   </div>
    6.   <div class="mt-3 flex -space-x-2 overflow-hidden">
    7.     {#each contributors as user}
    8.       <img class="inline-block h-12 w-12 rounded-full ring-2 ring-white" src="{user.avatarUrl}" alt="{user.handle}"/>
    9.     {/each}
    10.   </div>
    11.   <div class="mt-3 text-sm font-medium">
    12.     <a href="#" class="text-blue-500">+ 198 others</a>
    13.   </div>
    14. </div>

    You could even rewrite the navigation example using a loop or map if you preferred as well:

    Reusing Styles - 图4

    When elements are rendered in a loop like this, the actual class list is only written once so there’s no actual duplication problem to solve.

    If you need to reuse some styles across multiple files, the best strategy is to create a component if you’re using a front-end framework like React, Svelte, or Vue, or a template partial if you’re using a templating language like Blade, ERB, Twig, or Nunjucks.

    VacationCard.vue

    1. <template>
    2.     <img class="rounded" :src="img" :alt="imgAlt">
    3.     <div class="mt-2">
    4.       <div>
    5.         <div class="text-xs text-slate-600 uppercase font-bold tracking-wider">{{ eyebrow }}</div>
    6.         <div class="font-bold text-slate-700 leading-snug">
    7.           <a :href="url" class="hover:underline">{{ title }}</a>
    9.         <div class="mt-2 text-sm text-slate-600">{{ pricing }}</div>
    10.       </div>
    11.     </div>
    12.   </div>
    13. </template>
    15. <script>
    16.   export default {
    17.     props: ['img', 'imgAlt', 'eyebrow', 'title', 'pricing', 'url']
    18.   }
    19. </script>

    Now you can use this component in as many places as you like, while still having a single source of truth for the styles so they can easily be updated together in one place.

    Unless a component is a single HTML element, the information needed to define it can’t be captured in CSS alone. For anything even remotely complex, the HTML structure is just as important as the CSS.

    Don’t rely on CSS classes to extract complex components

    Reusing Styles - 图6

    1. <!-- Even with custom CSS, you still need to duplicate this HTML structure -->
    2. <div class="chat-notification">
    3.   <div class="chat-notification-logo-wrapper">
    4.     <img class="chat-notification-logo" src="/img/logo.svg" alt="ChitChat Logo">
    5.   </div>
    6.   <div class="chat-notification-content">
    7.     <h4 class="chat-notification-title">ChitChat</h4>
    8.     <p class="chat-notification-message">You have a new message!</p>
    9.   </div>
    10. </div>
    11. <style>
    12.   .chat-notification { /* ... */ }
    13.   .chat-notification-logo-wrapper { /* ... */ }
    14.   .chat-notification-logo { /* ... */ }
    15.   .chat-notification-content { /* ... */ }
    16.   .chat-notification-title { /* ... */ }
    18. </style>

    Even if you create classes for the different elements in a component like this, you still have to duplicate the HTML every time you want to use this component. Sure you can update the font-size for every instance in a single place, but what if you need to turn the title into a link?

    Components and template partials solve this problem much better than CSS-only abstractions because a component can encapsulate the HTML and the styles. Changing the font-size for every instance is just as easy as it is with CSS, but now you can turn all of the titles into links in a single place too.

    Notification.jsx

    When you create components and template partials like this, there’s no reason to use anything other than utility classes because you already have a single source of truth for the styles.

    If you’re using a traditional templating language like ERB or Twig, creating a template partial for something as small as a button can feel like overkill compared to a simple CSS class like btn.

    While it’s highly recommended that you create proper template partials for more complex components, you can use Tailwind’s @apply directive to extract repeated utility patterns to custom CSS classes when a template partial feels heavy-handed.

    Here’s what a btn-primary class might look like using @apply to compose it from existing utilities:

    Reusing Styles - 图8

    HTML

    1. <!-- Before extracting a custom class -->
    2. <button class="py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75">
    3.   Save changes
    4. </button>
    6. <!-- After extracting a custom class -->
    7. <button class="btn-primary">
    8.   Save changes
    9. </button>

    CSS

    1. @tailwind base;
    2. @tailwind components;
    3. @tailwind utilities;
    5. @layer components {
    6.   .btn-primary {
    7.     @apply py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75;
    8.   }
    9. }

    Learn more about @apply and @layer in the Functions & Directives documentation.

    Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse.

    If you start using @apply for everything, you are basically just writing CSS again and throwing away all of the workflow and maintainability advantages Tailwind gives you, for example:

    • You have to think up class names all the time — nothing will slow you down or drain your energy like coming up with a class name for something that doesn’t deserve to be named.
    • You have to jump between multiple files to make changes — which is a way bigger workflow killer than you’d think before co-locating everything together.
    • Your CSS bundle will be bigger — oof.

    If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice.