So in the last article, we have discussed the best practices for using Tailwind CSS4 in the real world - which is,
- A dedicated team maintaining the components
- The other teams just use them for creating pages
- Linter to enforce boundaries, not good will
In this way we "hide" the long utility class strings from rest of the codebase.
Special Landing Page
What happens when marketing launches a new campaign and needs a gradient CTA button that deviates from the core design system??
The obvious choice might be to do something like this:
const variants = {
primary: "...",
secondary: "...",
// The new marketing variant
"ai-campaign": "bg-gradient-to-r from-emerald-500 to-teal-500 animate-pulse text-lg px-8 py-4"
};
This looks clean today. But in a few years, it might grow to
<Button
variant="primary"
isMarketing
isAnimated
hasGlowEffect
showConfetti
campaignTheme="black-friday-2024"
seasonalBadge="sale"
size="xl"
/>
Now it's bloated again... this is called prop explosion.
What's the Best Way?
Option 1: Keep It Local with Tailwind Utilities
Sometimes a design is so specific that it's hard to imagine anyone using it again. So, just make the page live in a separate directory and use utility classes directory
//// Inside @/app/marketing/campaign/page.tsx ////
...
export default function CampaignPage() {
return (
<div>
<h1>The Next Generation of AI</h1>
{/* Custom, one-off visual classes are localized entirely to this page */}
<Button
className={cn("bg-indigo-600 text-white px-4 py-2", className)} >
Get Early Access
</Button>
</div>
);
}
Once the campaign ends, just delete the page. The component is left untouched.
Option 2: Add a Variant
If there are only a handful of visual styles and they genuinely represent something the business uses repeatedly, I'd probably just add another variant.
<Button variant="primary" />
<Button variant="secondary" />
<Button variant="cta" />
<Button variant="voucher" />
The props felt easy enough to understand, and it keeps the page code nice and clean. In a smaller codebase, maintaining a few extra variants would not be a big deal.
Option 3: Create a Specialized Component
There's also a middle ground. If I find myself copying the same styling around a campaign or a particular section of the application, I'd probably start wondering whether it's worth creating something like a .
function CampaignButton(props) {
return (
<Button
className={cn("bg-gradient-to-r from-emerald-500 to-teal-500 animate-pulse",
className
)}
{...props}
/>
);
}
function CampaignButton({ className, ...props }) {
return (
<Button
className={cn(
"bg-gradient-to-r ...",
className
)}
{...props}
/>
);
}
// Base component
<Button>
Testimonials
</Button>
// Campaign-specific component
<CampaignButton>
Get Early Access
</CampaignButton>
That way the shared Button stays focused on being a button, while the campaign gets its own reusable abstraction. It feels like a reasonable compromise when you're not quite ready to promote something into the design system, but you don't want duplicated styling everywhere either.
The goal is:
Keep shared components focused, understandable, and maintainable.
Do you agree with the tradeoffs? What are your tips for writing even tidier and more maintainable components? Please share your experience ~ :)
SOCIAL SHARE CARD GENERATOR