توسعه فرانت‌اند

Tailwind UI Components: کامپوننت‌های آماده

تفاوت Tailwind CSS و Tailwind Plus، مجوز، RTL و رفتار تعاملی با کارت مستقل و پنج فایل کامل React، Vite و Tailwind CSS 4.

1404/12/03 3 دقیقه مطالعه 1,121 بازدید

کامپوننت آماده می‌تواند زمان ساخت بخش‌های رایج رابط را کم کند، اما انتخاب آن فقط کپی‌کردن چند کلاس نیست. باید بدانید چه چیزی دریافت می‌کنید: قالب ظاهری، رفتار تعاملی، وابستگی چارچوب و مجوز استفاده. Tailwind UI نامی است که در آموزش‌های قدیمی می‌بینید؛ محصول رسمی با نام Tailwind Plus معرفی شده است. آن را با خود Tailwind CSS که ابزار Utility برای نوشتن سبک است یکسان نگیرید.

وضعیت دسترسی در اکتبر ۲۰۲۶ مهم است: طبق اعلام رسمی پیوستن Tailwind Labs به Shopify، ثبت‌نام مشتریان تازه محصولات تجاری بسته می‌شود و مشتریان موجود دسترسی خود را حفظ می‌کنند. بنابراین Tailwind Plus را گزینه خرید آزاد برای هر کاربر تازه معرفی نمی‌کنیم. این تغییر با امکان استفاده از Tailwind CSS یکی نیست. نمونه این مقاله مستقل نوشته شده و کپی یک کامپوننت پولی نیست.

Tailwind CSS، بلوک آماده و کتابخانه رفتار

Tailwind CSS کلاس‌های Utility و سازوکار تولید سبک را فراهم می‌کند. بلوک آماده، ترکیبی از ساختار و سبک برای یک نیاز رایج است؛ مثل کارت، فرم یا صفحه قیمت. بعضی تعامل‌ها به JavaScript و قرارداد دسترس‌پذیری نیاز دارند. وجود کلاس‌های زیبا روی یک div، آن را به Dialog یا منوی کامل تبدیل نمی‌کند. باید معلوم باشد بسته انتخاب‌شده چه رفتارهایی را پوشش می‌دهد و چه چیزهایی به عهده شما می‌ماند.

برای نمونه، کارت معرفی معمولی شاید فقط HTML و CSS بخواهد، اما منوی بازشونده به کیبورد، Focus و وضعیت نیاز دارد. راهنمای دسترس‌پذیری React این رابطه را توضیح می‌دهد. اگر از کتابخانه تعاملی استفاده می‌کنید، وابستگی و نسخه باید در پروژه مشخص باشد. قطعه JSX دارای Import معرفی‌نشده یک نمونه کامل نیست. قالب آماده نباید نیاز واقعی تعامل را پشت ظاهر پنهان کند.

نام جدید و منبع جاری

برای شناخت نام محصول، اعلام رسمی تغییر Tailwind UI به Tailwind Plus را بخوانید و برای دسترسی مشتری موجود از مسیر رسمی ورود استفاده کنید. آموزش قدیمی می‌تواند هنوز ایده مفیدی داشته باشد، اما نسخه CSS و وابستگی آن باید بررسی شوند. تغییر نام به معنی یکسان‌بودن همه قراردادها در طول زمان نیست. پیش از کپی، تاریخ و محیط نمونه را بخوانید.

شرایط مجوز را از همان سند جاری بگیرید. استفاده در یک پروژه مشتری، اشتراک کد با تیم و بازفروش یک مجموعه آماده موضوع‌های متفاوتی‌اند. این مقاله حکم حقوقی درباره همه حالت‌ها نمی‌دهد. اگر استفاده شما در مرز مجوز است، از صاحب محصول یا مشاور مرتبط توضیح بگیرید. دسترسی یک فرد به حساب نیز خودکار به معنی اجازه توزیع عمومی سورس دریافتی نیست. نمونه مستقل و دارای مجوز روشن، ریسک ابهام را کمتر می‌کند.

نیاز محصول را قبل از انتخاب بلوک بنویسید

برای هر بخش، محتوا، اقدام اصلی و حالت‌ها را مشخص کنید. یک کارت محصول ممکن است قیمت، محدودیت، موجودی و وضعیت غیرفعال بخواهد. اگر قالب انتخاب‌شده فقط تصویر و عنوان دارد، برای نیاز شما هنوز کامل نیست. ترتیب اطلاعات را از هدف کاربر بسازید، نه از جای خالی طرح آماده. حذف متن ضروری برای شبیه‌ماندن به Demo می‌تواند تصمیم کاربر را دشوار کند.

در سایت فارسی، طول متن، جهت، عدد و آیکن را با محتوای واقعی ببینید. چیدمان راست‌به‌چپ فقط تغییر text-align نیست؛ فاصله و جهت حرکت و ترتیب برخی عناصر اهمیت دارند. Logical Properties یا Utility مناسب می‌توانند کمک کنند. نام برند یا قطعه کد انگلیسی نیز ممکن است جهت مستقل بخواهد. قالب لاتین با متن کوتاه تضمین نمی‌کند همان ساختار برای توضیح بلند فارسی مناسب باشد.

نمونه مستقل با Tailwind CSS 4 و Vite

پنج فایل زیر را در پوشه تازه بگذارید: package.json، vite.config.js، index.html، style.css و main.jsx. Node نسخه ۲۲.۱۲ به بالا و npm لازم است. پس از npm install، فرمان npm run dev را اجرا و نشانی Vite را باز کنید. نمونه یک کارت معرفی آموزشی با React است؛ هیچ خرید، ورود، API یا صفحه مقصد ساختگی ندارد. دکمه فقط توضیح بیشتری را در همان کارت باز می‌کند.

فایل package.json

{"type":"module","scripts":{"dev":"vite"},"dependencies":{"react":"^19.0.0","react-dom":"^19.0.0"},"devDependencies":{"vite":"^8.0.0","tailwindcss":"^4.0.0","@tailwindcss/vite":"^4.0.0"}}

فایل vite.config.js

import { defineConfig } from 'vite';
import tailwindcss from '@tailwindcss/vite';
export default defineConfig({ plugins: [tailwindcss()] });

فایل index.html

<!doctype html>
<html lang="fa" dir="rtl">
<head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>نمونه React</title></head>
<body><div id="root"></div><script type="module" src="/main.jsx"></script></body>
</html>

فایل style.css

@import "tailwindcss";

فایل main.jsx

import React, { useId, useState } from 'react';
import { createRoot } from 'react-dom/client';
import './style.css';
function App() {
  const [open, setOpen] = useState(false);
  const detailsId = useId();
  return <main className="min-h-screen bg-slate-100 p-6 font-sans text-slate-950">
    <article className="mx-auto max-w-md rounded-2xl border border-slate-300 bg-white p-6 shadow-sm">
      <p className="mb-2 text-sm font-bold text-blue-800">نمونه مستقل آموزشی</p>
      <h1 className="text-2xl font-bold">یک کارت با محتوای روشن</h1>
      <p className="mt-3 leading-8">این نمونه برای معرفی یک موضوع و نمایش توضیح محلی است.</p>
      <button type="button" aria-expanded={open} aria-controls={detailsId}
        className="mt-5 rounded-lg bg-blue-800 px-4 py-3 font-bold text-white focus-visible:outline-4 focus-visible:outline-offset-4 focus-visible:outline-blue-800"
        onClick={() => setOpen(value => !value)}>{open ? 'بستن توضیح' : 'نمایش توضیح'}</button>
      <section id={detailsId} hidden={!open} className="mt-4 border-t border-slate-300 pt-4 leading-8">
        <h2 className="font-bold">مرز نمونه</h2><p>این کارت عملیات خرید یا ارتباط با سرور ندارد.</p>
      </section>
    </article>
  </main>;
}
createRoot(document.getElementById('root')).render(<App />);

نصب از مسیر راهنمای رسمی Tailwind با Vite پیروی می‌کند: افزونه @tailwindcss/vite معرفی شده و CSS با import مربوط وارد می‌شود. این نمونه تنظیم Tailwind 4 دارد؛ فرمان‌های قدیمی تولید فایل Config را بدون نیاز به آن اضافه نکنید. همه کلاس‌ها در فایل معرفی‌شده هستند و Container و آیتم واقعی وجود دارند. متن کارت ساختگی و برای آموزش است.

کامپوننت را به قرارداد پروژه تبدیل کنید

پس از انتخاب ظاهر، ورودی‌های واقعی کامپوننت را تعریف کنید: عنوان، توضیح، اقدام و وضعیت. همه چیز را بدون نیاز به ده‌ها Prop عمومی تبدیل نکنید. اگر فقط دو مصرف‌کننده دارید، ابتدا تفاوت واقعی آن‌ها را بفهمید. یک API بیش از حد عمومی با شرط‌های متعدد می‌تواند از دو ساختار روشن سخت‌تر نگهداری شود. تکرار کوچک همیشه دلیل ساختن یک سیستم بزرگ نیست.

در مثال، کارت برای نمایش یک موضوع و بازکردن توضیح محلی نوشته شده است. نام دکمه با وضعیت هماهنگ و aria-expanded تعریف شده است. چون Modal نیست، Focus Trap یا پوشاندن پس‌زمینه ندارد. اگر آن را به Dialog تبدیل می‌کنید، فقط افزودن position fixed کافی نیست. رفتار لازم و Markup مناسب را هم اضافه کنید. آموزش باید همین مرز را روشن بگوید تا نمونه ناقص به محصول منتقل نشود.

Design Token و یکدستی

رنگ، فاصله و Typography را با سیستم طراحی پروژه هماهنگ کنید. کپی چند بلوک با قراردادهای متفاوت می‌تواند صفحه‌ای ظاهراً زیبا اما نامنسجم بسازد. تعریف Token برای انتخاب‌های مشترک کمک می‌کند تغییرها قابل کنترل باشند. راهنمای Design Token رابطه طراحی و توسعه را توضیح می‌دهد. Utilityها ابزار بیان‌اند؛ تصمیم درباره هویت بصری و سلسله‌مراتب همچنان باید روشن باشد.

از بازنویسی گسترده کلاس‌ها فقط برای متفاوت‌بودن خودداری کنید. مشخص کنید چه چیزی واقعاً با برند یا محتوا ناسازگار است. تغییر اندازه دکمه ممکن است روی لمس و متن اثر بگذارد؛ تغییر رنگ ممکن است کنتراست را کم کند. هر اصلاح ظاهری باید با کارکرد همراه دیده شود. قالب آماده نقطه شروع است، نه نتیجه نهایی محصول شما. نگهداری بهتر از آمیختن چند Demo بدون قرارداد مشترک می‌آید.

کلاس پویا و تولید CSS

در تولید Utility، ابزار باید نام کلاس‌ها را در منبع شناسایی کند. ساخت رشته‌های کلاس به شکل قطعه‌های نامشخص می‌تواند باعث نبود خروجی مورد انتظار شود. برای حالت‌های محدود، نگاشت کلاس‌های کامل و قابل شناسایی روشن‌تر است. مسیر فایل و روش تشخیص منبع را از مستندات نسخه بخوانید. خطای نبود سبک همیشه از React نیست؛ ممکن است زنجیره تولید CSS فایل یا نام مورد نظر را ندیده باشد.

نمونه کلاس‌ها را به شکل رشته کامل نوشته است و وابستگی تصویر یا فونت بیرونی ندارد. اگر در پروژه واقعی فونت فارسی یا تصویر می‌افزایید، فایل، مجوز و رفتار بارگذاری را مشخص کنید. لینک تصویر ساختگی یک نمونه کامل نمی‌سازد. راهنمای بهینه‌سازی تصویر وب برای حجم و قالب کمک می‌کند. اضافه‌کردن Asset نباید پیش‌نیاز پنهانی برای فهم مثال باشد.

حالت‌ها و محدودیت‌های محتوا

عنوان بلند، متن کوتاه، نبود تصویر، خطا و حالت غیرفعال را در طراحی واقعی در نظر بگیرید. همه حالت‌ها در یک Demo واحد لازم نیست، اما ادعای پوشش کامل هم نباید بدون آن‌ها مطرح شود. اگر دکمه به خرید واقعی وصل می‌شود، قیمت و شرایط باید از مرجع معتبر بیایند. کامپوننت UI محل تصمیم امنیتی درباره مبلغ یا مجوز نیست. داده سمت کلاینت قابل تغییر است.

برای صفحه قیمت، راهنمای طراحی صفحه قیمت‌گذاری کمک می‌کند محتوا و تصمیم را در کنار ظاهر ببینید. کارت نمونه این مقاله عمداً مبلغ و خرید ندارد تا قرارداد پرداخت معرفی‌نشده نسازد. اگر هدف فقط معرفی است، شاید یک لینک واقعی کافی باشد؛ اگر اقدام محلی است، button مناسب است. نوع عنصر را از رفتار انتخاب کنید، نه صرفاً از شکل موجود در قالب.

انتخاب مسئولانه کامپوننت آماده

در پایان، نیاز، مجوز، نسخه، وابستگی و هزینه تطبیق را کنار هم بگذارید. یک مجموعه آماده می‌تواند شروع را ساده کند، اما مسئولیت محتوا، RTL، دسترس‌پذیری و اتصال داده باقی می‌ماند. این مقاله ادعای بررسی اجرایی سایت شما ندارد و نمونه را به عنوان کد مستقل آموزشی ارائه می‌کند. انتخاب مناسب باید ساخت محصول قابل استفاده و قابل نگهداری را آسان‌تر کند، نه فقط سرعت کپی نخستین صفحه را بالا ببرد.

واکنش به این مقاله

اشتراک‌گذاری این مقاله:
دیدگاه‌ها 0
۰ / ۲۰۰۰

هنوز دیدگاهی ثبت نشده

اولین نفری باشید که نظر می‌دهد!