Common Mistakes & Best Practices
A practical guide to writing maintainable Tailwind CSS: avoiding overly long class lists, knowing when to extract components, and using the spacing scale consistently.
Introduction
By this point in the course you know most of Tailwind's utilities. The harder, less obvious skill is using them well over time — keeping markup readable, avoiding duplicated design decisions, and knowing when a wall of classes is a sign you should extract something. This lesson pulls together practical guidance from everything you have built so far.
- Techniques for taming excessively long class lists.
- A clear rule of thumb for extracting components versus keeping utilities inline.
- Why sticking to Tailwind's spacing scale matters more than it seems.
Taming Long Class Lists
A component with responsive prefixes, states, and dark mode variants can easily accumulate 15–20 classes on one element. That is normal for Tailwind, but readability still matters.
<!-- Hard to scan: everything on one long line --><div class="flex flex-col md:flex-row items-start md:items-center justify-between gap-4 p-6 bg-white dark:bg-gray-800 rounded-lg shadow-sm border border-gray-200 dark:border-gray-700 hover:shadow-md transition-shadow">// Easier to scan: grouped and formatted across lines<div className=" flex flex-col md:flex-row items-start md:items-center justify-between gap-4 p-6 rounded-lg border shadow-sm hover:shadow-md transition-shadow bg-white border-gray-200 dark:bg-gray-800 dark:border-gray-700 ">The prettier-plugin-tailwindcss plugin automatically sorts classes into a consistent order on save, which removes the need to manually maintain formatting conventions across a team.
When to Extract a Component
The decision between inline utilities, a component, and an @apply class comes up constantly. A simple rule of thumb: extract based on repetition and complexity, not on how long a single class list looks.
| Situation | Recommended Approach |
|---|---|
| Used once, anywhere in the app | Inline utility classes. |
| Same visual pattern reused in 2–3 places within one framework (React, Vue, etc.) | A component (<Button />, <Card />) — logic and markup live together. |
| Same visual pattern reused across non-component contexts (CMS output, plain HTML, a different framework) | @apply class inside @layer components. |
| A single tiny effect meant to combine with other utilities | A custom utility inside @layer utilities. |
Consistent Spacing Scale Usage
Tailwind's default spacing scale (0, 0.5, 1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24...) is deliberately non-linear and was chosen so that a handful of values cover most real designs. Sticking to it — rather than reaching for arbitrary values like p-[13px] — is what makes a Tailwind-built interface feel visually consistent without any conscious effort.
<!-- Inconsistent: arbitrary, one-off spacing values --><div class="p-[18px] mb-[22px] gap-[10px]">...</div>
<!-- Consistent: values drawn from the shared spacing scale --><div class="p-5 mb-6 gap-2.5">...</div>Two components built by different developers, both using only scale values, will naturally line up with each other. Two components using arbitrary pixel values almost never will.
Ordering Your Classes
A consistent class order — layout, then box model, then typography, then color, then state variants — makes it much faster to scan a class list and predict what an element looks like, even before automated tooling sorts it for you.
<button class="flex items-center gap-2 px-4 py-2 rounded-md text-sm font-semibold bg-blue-600 text-white hover:bg-blue-700"> <!-- layout → box model → typography → color → state --> Save</button>Avoiding Arbitrary Value Overuse
Arbitrary values (bg-[#1da1f2], top-[117px]) are a genuinely useful escape hatch for one-off, unpredictable needs like matching an exact brand color or pixel-perfect design handoff. The mistake is reaching for them as a first choice instead of a last resort, when a value from the theme would have worked just as well.
<!-- Reach for scale values first --><div class="text-blue-600 p-4 rounded-lg">...</div>
<!-- Save arbitrary values for genuine one-offs --><div class="bg-[url('/hero-bg.jpg')] top-[calc(100%-2px)]">...</div>Responsive and State Variant Habits
Two habits go a long way: design mobile-first, adding md:/lg: overrides only where the layout genuinely needs to change (not on every property out of caution), and group related states — hover:, focus:, and dark: — near the base utility they modify so the relationship is easy to see at a glance.
<a class="text-gray-700 hover:text-blue-600 dark:text-gray-300 dark:hover:text-blue-400"> Link</a>Common Mistakes
- Extracting a component after seeing a pattern only once — wait for real repetition before adding an abstraction.
- Mixing arbitrary spacing values with scale values in the same component, producing subtly inconsistent gaps and padding.
- Writing responsive overrides for every property "just in case" instead of only where the design actually changes.
- Letting one enormous, unformatted class string make a component unreadable instead of breaking it across lines or grouping logically.
Best Practices Checklist
- Use the prettier-plugin-tailwindcss plugin so class ordering is automatic and consistent across a team.
- Extract a component or @apply class only after a pattern repeats — not preemptively.
- Default to the spacing scale; reach for arbitrary values only for genuine one-offs.
- Design mobile-first, adding responsive prefixes only where the layout truly needs to differ.
- Group hover:, focus:, and dark: variants next to the base class they modify for readability.
Frequently Asked Questions
Not inherently — Tailwind is designed for it. The real problem is unreadable formatting or unnecessary duplication, not length by itself.
Prefer components within a single framework, since markup and behavior stay together. Reach for @apply when the same styling needs to apply outside of components, such as CMS-rendered HTML.
Strict enough that arbitrary spacing values are the exception, not the rule. A handful of genuine one-offs is fine; frequent arbitrary spacing usually signals the scale needs extending instead.
Key Takeaways
- Long class lists are normal in Tailwind — readability comes from formatting and consistent ordering, not from avoiding utilities.
- Extract components or @apply classes based on genuine repetition, not preemptively.
- Sticking to the spacing scale is what makes independently built components feel visually consistent.
- Arbitrary values are a useful escape hatch, not a default choice.
Summary
You now have a practical set of habits — formatting, extraction rules, spacing discipline, and variant organization — for writing Tailwind that stays maintainable as a project grows. In the final lesson, you will apply everything from this course to build a small, real-world responsive dashboard page.