## When Should You Extract Components? [Tailwind](/courses/tailwindcss)'s utility-first approach is designed to keep styling directly inside your markup. For example: ```html ``` For a button used once or twice, this is completely fine. But imagine repeating the exact same button classes across 20 different places. At that point, your fingers might file a complaint. 😭 That's when extracting reusable styles or components starts making sense. --- ## Repetition Isn't Always Bad Beginners sometimes see repeated [Tailwind](/courses/tailwindcss) classes and immediately think: > "I need to create a custom [CSS](/courses/css) class." Not necessarily. Repeating a few utility classes is completely normal in Tailwind. For example: ```html

``` appearing several times doesn't automatically mean you should create: ```css .flex-row-thing { /* ... */ } ``` The goal isn't to eliminate every repeated class. You should extract something when it represents a **real reusable component or pattern**. Good examples include: * buttons * badges * alerts * form controls * navigation items * cards used repeatedly * repeated component variants --- ## Prefer Framework Components for Reusable UI If you're working with [React](/courses/reactjs), [Next.js](/courses/nextjs), Vue, or another component-based framework, the best solution is often to extract the **entire UI component**, not just its [CSS](/courses/css). For example, instead of repeating: ```jsx ``` you could create: ```jsx function PrimaryButton({ children }) { return ( ); } ``` Then use it: ```jsx Save Continue ``` Now the styling stays utility-first, but you don't repeat the same markup everywhere. This is usually a great approach in component-based applications. --- ## Using `@apply` Tailwind also provides the `@apply` directive. `@apply` lets you combine existing Tailwind utilities inside your own CSS class. For example: ```css .btn-primary { @apply px-4 py-2 bg-blue-600 text-white font-semibold rounded-lg; } ``` Now you can write: ```html ``` instead of repeating every utility. --- ## Modern Tailwind CSS Setup In Tailwind CSS v4, your main stylesheet commonly starts with: ```css @import "tailwindcss"; ``` You can then add your custom class: ```css @import "tailwindcss"; .btn-primary { @apply px-4 py-2 bg-blue-600 text-white font-semibold rounded-lg shadow-md; } ``` And use it normally: ```html ``` Much cleaner when the exact same style genuinely needs to be reused. --- ## Adding Hover and Focus Styles You can keep interaction styles alongside your custom component styles. For example: ```css @import "tailwindcss"; .btn-primary { @apply px-4 py-2 bg-blue-600 text-white font-semibold rounded-lg shadow-md; } .btn-primary:hover { @apply bg-blue-700; } .btn-primary:focus { @apply outline-none ring-2 ring-blue-400; } ``` Then your markup stays simple: ```html ``` --- ## Should You Use `@apply` Everywhere? Nope. Please don't turn this: ```html

``` into: ```css .my-special-container { @apply flex items-center justify-between p-4; } ``` and then do that for every element on the page. At that point, we've basically rebuilt traditional CSS while Tailwind watches from the corner wondering what went wrong. 😭 `@apply` is most useful when you have a small, clearly reusable styling pattern or when you're writing custom CSS that still needs to use your Tailwind design tokens and utilities. --- ## Utility Classes vs `@apply` Suppose you have: ```html ``` If this button appears only once: > Keep the utilities. If it appears everywhere with the exact same design: > Consider extracting it. If you're using [React](/courses/reactjs) or [Next.js](/courses/nextjs): > Consider creating a reusable ` ``` Here: ```text btn-primary → reusable button styling flex → enables Flexbox items-center → vertically aligns the content gap-2 → adds space between the icon and text ``` This is one of Tailwind's strengths. Extract the shared foundation while keeping one-off variations directly in the markup. --- ## Production Optimization You might wonder: > "Tailwind has thousands of utilities. Doesn't that create a gigantic CSS file?" Thankfully, no. Tailwind scans your source files for the utility classes you're actually using and generates the CSS needed for those classes. So if your project only uses utilities like: ```text flex p-4 bg-blue-500 text-white rounded-lg ``` Tailwind doesn't need to ship every possible utility combination to the browser. This keeps your generated stylesheet focused on the styles your application actually uses. --- ## How Tailwind Detects Classes Tailwind scans your project files and looks for recognizable class names. For example: ```html

``` Tailwind sees: ```text bg-blue-500 text-white p-4 ``` and generates the corresponding CSS. This happens during your build process, so Tailwind doesn't need a big styling runtime running in the browser. --- ## Be Careful with Dynamic Class Names This is an important production gotcha. Avoid constructing class names like this: ```jsx function Button({ color }) { return ( ); } ``` You might expect: ```text color = "blue" ``` to become: ```text bg-blue-500 ``` But Tailwind scans your source as text. The complete class: ```text bg-blue-500 ``` doesn't actually appear in the source code. That means Tailwind may not detect it. --- ## Use Complete Class Names Instead A safer approach is to map values to complete utility classes. ```jsx function Button({ color }) { const colors = { blue: "bg-blue-500 hover:bg-blue-600", red: "bg-red-500 hover:bg-red-600", green: "bg-green-500 hover:bg-green-600", }; return ( ); } ``` Now Tailwind can clearly see: ```text bg-blue-500 hover:bg-blue-600 bg-red-500 hover:bg-red-600 bg-green-500 hover:bg-green-600 ``` during source scanning. Everything can be generated correctly. --- ## A Practical Component Example Here's a reusable React button with multiple variants: ```jsx function Button({ variant = "primary", children }) { const variants = { primary: "bg-blue-600 hover:bg-blue-700 text-white", secondary: "bg-slate-200 hover:bg-slate-300 text-slate-900", danger: "bg-red-600 hover:bg-red-700 text-white", }; return ( ); } ``` Now you can write: ```jsx ``` This gives you: * reusable Tailwind utilities * reusable component logic * clear variants * no giant custom stylesheet * complete class names Tailwind can detect That's a much more scalable pattern for modern React and Next.js applications. --- ## A Simple Rule to Remember Use normal utilities when: ```text The styling belongs to one specific element. ``` Extract a framework component when: ```text The entire UI element is reused. ``` Consider `@apply` when: ```text You genuinely need a reusable CSS class. ``` And avoid extracting styles just because your `class` attribute looks long. Long Tailwind class lists aren't automatically bad. Sometimes they're simply the design doing its job. --- ## Key Takeaway Tailwind encourages you to keep utilities directly in your markup, but that doesn't mean you should copy huge reusable patterns everywhere. For reusable UI, especially in React or Next.js, creating components is often the cleanest solution. When a reusable CSS abstraction makes sense, `@apply` lets you compose Tailwind utilities inside your own classes: ```css .btn-primary { @apply px-4 py-2 bg-blue-600 text-white rounded-lg; } ``` For production, Tailwind scans your source files and generates CSS based on the utilities it detects, helping keep the final stylesheet focused on what your application actually uses. And remember the golden rule: > Extract because something is genuinely reusable — not because a Tailwind class list looks scary. 😎 Throughout **asif.to**, we'll follow the same approach you'd use in real production projects: utilities for everyday styling, reusable components where they make sense, and abstractions only when they actually make the code easier to maintain.