لماذا تختار Tailwind وفي الوقت نفسه تحتاج إلى نمط واضح
الكثيرون يحبون Tailwind — السرعة، عدم الحاجة لكتابة CSS كثير، القدرة على بناء أي شيء في HTML نفسه. لكن هذه نفس الأسباب التي تجعله كارثياً بدون نمط واضح. مهندس يكتب text-lg، آخر يكتب text-base، ثالث يكتب text-16px — ولا أحد يعرف أيها صحيح.
من تجربتي في قيادة مشاريع في الكويت والخليج، هذا هو الفارق الوحيد بين فريق ينتج واجهات نظيفة والتزام كل عضو به الأسلوب، وفريق يعاني من إعادة البناء كل بضعة أشهر. النمط.
الخبر الجيد: تنظيم Tailwind في فريق كبير ليس معقداً. إنه يحتاج إلى ثلاثة أشياء فقط: إعداد واحد، قواعد واضحة، وأدوات صغيرة. سأريكم بالضبط ما نستخدمه.
ملاحظة خبير: لا تنتظر حتى تكبر الفريق
رأيت هذا الخطأ بالذات يُغرق مشاريع كانت ممولة تمويلاً جيداً: الفريق الأول أو الثاني يبدآن بدون نمط، والعادات السيئة تصبح عميقة جداً بحلول الوقت الذي تسأل فيه عن التنظيم. ابدأ من اليوم الأول، حتى لو كنت وحدك فقط. الاستثمار سيأتي معك.
الإعداد المركزي: مكان واحد للحقيقة
كل مشروع Tailwind يجب أن يبدأ بـ tailwind.config.js (أو tailwind.config.ts إذا كنت تستخدم TypeScript — أنا أفضل TypeScript لأن الأخطاء تظهر مبكراً). هذا الملف ليس مكان إضافة ألوان عشوائية. هذا هو دستور الفريق.
افتح الإعداد وأضف:
theme.extend.colors — أضف فقط الألوان التي يستخدمها الفريق فعلاً. لا تضف 50 لون "قد نحتاجها يوماً ما". في مشروع كويتي لشركة SaaS كنت تعمل معها، حددنا 5 ألوان أساسية فقط: الأسود والأبيض واللون الأساسي والنجاح والخطأ. أي شيء آخر يُشتق منهم.
theme.extend.spacing — لا تستخدم الفراغات العشوائية. التزم بسلم: 4px, 8px, 12px, 16px, 20px, 24px, 32px, 40px, 48px. تحديد السلم مقدماً يوفر وقتاً وينهي النقاش عن "هل هذا يجب أن يكون ml-6 أو ml-7؟"
theme.extend.fontSize — نفس الفكرة. حدد أحجام النصوص: xs, sm, base, lg, xl, 2xl, 3xl. لا تضف حجم جديد كل مرة تريد فيها نصاً مختلفاً قليلاً.
هذا الإعداد يجب أن يكون في مستودع git ومشترك عبر الفريق. لا ملفات إعداد محلية، لا استثناءات. مركزي تماماً.
فصل الفئات حسب الغرض: utilities ضد components
هنا حيث يخطئ معظم الفرق. يخلطون بين استخدام Tailwind utility classes في كل مكان، وعندما يريدون عنصراً متكرراً، ينسخون الفئات في 5 أماكن مختلفة.
حين يأتيني عميل يسأل عن X، أول سؤال أطرحه عليه هو: "هل هذا يُستخدم في مكان واحد فقط، أم في أماكن متعددة؟" إذا كان مكاناً واحداً فقط، استخدم utility classes مباشرة في HTML. إذا كان أماكن متعددة، اكتبه كـ component.
في Laravel/Vue، المكون يبدو هكذا:
<!-- components/Button.vue -->
<template>
<button :class="['px-4 py-2 rounded-lg font-semibold transition-all', variantStyles[variant]]">
<slot />
</button>
</template>
<script>
export default {
props: { variant: { type: String, default: 'primary' } },
data() {
return {
variantStyles: {
primary: 'bg-blue-600 text-white hover:bg-blue-700',
secondary: 'bg-gray-200 text-gray-800 hover:bg-gray-300'
}
}
}
}
</script>
الآن الزر موحد. أي تغيير في النمط يحدث مرة واحدة. أي مهندس جديد يريد زراً، ينقر import ويستخدمه. لا نقاش، لا معادلة "أي classes أستخدم؟"
هذا الفصل يُقسّم الملفات الخاصة بك إلى ثلاث طبقات:
الطبقة الأولى: src/styles/tokens.css — الألوان والأحجام والفراغات فقط (من tailwind.config).
الطبقة الثانية: src/components/ — الأزرار والـ cards والـ forms وكل ما يُستخدم أكثر من مرة. HTML + Tailwind classes معاً.
الطبقة الثالثة: src/pages/ — الصفحات التي تجمع components معاً. عادة لا توجد فيها Tailwind classes مباشرة، فقط استدعاءات components.
هذا الفصل وحده يوفر وقتاً هائلاً عند التدقيق (code review). المدقق ينظر إلى component واحد، بدلاً من البحث عن نفس الفئات في 10 ملفات مختلفة.
Design Tokens: حل المشكلة الحقيقية
Tailwind يعطيك utility classes، لكن المشكلة الحقيقية عند الفرق الكبيرة أعمق: من أين يأتي القرار بشأن لون زرّ؟ هل هو blue-600؟ أم blue-700؟ من قال أنه blue وليس teal؟
هذا هو بالضبط ما تحل به design tokens. Token هو متغير مركزي يقول "اللون الأساسي للزر الرئيسي في كل مكان هو [هذا]، وإذا غيّرنا قرار التصميم، نغيره هنا فقط."
في مشروع Flutter/iOS كان لدينا، استخدمنا نفس الفكرة. Token واحد يسمى colorPrimaryButton، وهو يُشير إلى قيمة. عندما أراد العميل تغيير اللون من الأزرق إلى الأخضر، كان التغيير في ملف واحد فقط، لا في 100 مكان.
في Tailwind مع React/Next.js، تفعل هذا مع CSS variables:
/* tailwind.css */
:root {
--color-primary: #2563eb;
--color-primary-hover: #1d4ed8;
--color-secondary: #e5e7eb;
--spacing-base: 0.25rem;
}
/* tailwind.config.js */
theme: {
extend: {
colors: {
primary: 'var(--color-primary)',
'primary-hover': 'var(--color-primary-hover)'
}
}
}
الآن، عندما تكتب الزرّ، تكتب <button class="bg-primary hover:bg-primary-hover"> — لا ألوان مشفرة مباشرة. إذا غيّرت المتغيّر في ملف واحد، تتحدث كل الأزرار.
المكافأة الإضافية: عندما يريد العميل نمط ليلي (dark mode)، تُضيف متغيرات جديدة فقط:
@media (prefers-color-scheme: dark) {
:root {
--color-primary: #1e40af;
--color-primary-hover: #1e3a8a;
}
}
الكود بالكامل يستجيب بدون تغيير أي شيء آخر.
ملاحظة خبير: لا تقع في مصيدة الـ CSS-in-JS
بصراحة، معظم الشركات في الكويت التي رأيتها تحاول أدوات مثل styled-components أو Emotion لحل هذه المشكلة، وتنتهي بمشروع أعقد وأبطأ بدون فائدة حقيقية. CSS variables + Tailwind توفر نفس الفائدة بدون التعقيد. التزم بالبساطة.
أنماط الإعداد: العادات التي تبني نموذج عمل قابل للتوسع
إعداد واحد وفئات واضحة ليسا كافيين. تحتاج إلى أنماط عمل يتبعها كل عضو فريق، كل مرة.
النمط الأول: استخدم الفئات الموجودة قبل إضافة فئات جديدة. إذا احتاج أحدهم إلى فراغ 18px، يسأل قبل إضافة ml-18. غالباً، ml-16 + فئة أخرى صغيرة يحل المشكلة. الهدف: قائمة صغيرة ومركبة من الفئات، لا قائمة طويلة.
النمط الثاني: اكتب components للتكرار، فقط utility classes للاستثناءات. إذا رأيت نفس مجموعة الفئات في أكثر من مكان، انقلها إلى component. هذا ينقذك من 90% من الصداع المستقبلي.
النمط الثالث: وثّق قرارات التصميم. في ملف README أو Storybook، اكتب لماذا اخترتم هذا اللون للأزرار الرئيسية، أو هذا الحجم للنصوص. عندما يأتي مهندس جديد، يعرف ليس فقط "الفئات التي تستخدمها" بل "لماذا اخترتم هذا." في فريق في الرياض كنت أعمل معه، 15 دقيقة من التوثيق الواضحة وفّرت ساعات من النقاش لاحقاً.
الأدوات التي تجعل كل شيء موحداً
التنظيم اليدوي ينجح، لكن الأدوات تنقذك من الأخطاء البشرية. هناك أدوات صغيرة تستخدمها فرق كبيرة:
Prettier: ينسق الكود تلقائياً. بدون هذه، ستضيع وقتاً في التدقيق حول "هل هذا يجب أن يكون سطر واحد أم سطرين؟" مع Prettier، لا مجال للنقاش — الكود ينسق نفسه.
ESLint مع Tailwind plugin: يحذرك إذا استخدمت فئة Tailwind خاطئة أو غير موجودة. إذا كتب أحدهم text-16px بدلاً من استخدام الفئات المعرّفة، ESLint سيرفعه قبل أن يدخل المستودع.
Storybook: إذا كنت تعمل مع فريق من المهندسين، Storybook يعطيك مكان واحد لرؤية جميع components بجميع الحالات. أحد أعضاء الفريق يقول "هل هناك زر صغير بدون حدود؟" — انقر في Storybook وانظر إلى جميع البدائل.
هذه الأدوات ليست "إضافة فاخرة". عندما يكون لديك 8 أشخاص يعملون على نفس المشروع، هذه الأدوات توفر وقتاً وتمنع الأخطاء.
الأخطاء التي رأيتها تحطم المشاريع
بعد سنوات من العمل مع فرق، رأيت نفس الأخطاء تتكرر:
الخطأ الأول: عدم وجود إعداد مركزي من اليوم الأول. عندما تبدأ بدون نمط، الفريق يخترع نمطه الخاص به. بحلول الوقت الذي تقرر فيه "نحتاج إلى تنظيم", عادات سيئة صارت عميقة جداً.
الخطأ الثاني: عدم فصل components عن utility classes. الفريق يستخدم الفئات مباشرة في HTML في كل مكان، وعندما يريد تغيير الأسلوب، يبحث عن نفس الفئات في 50 مكان.
الخطأ الثالث: إضافة أدوات بعد المشروع كبير بالفعل. بدلاً من البدء مع ESLint و Prettier من اليوم الأول، ينتظرون حتى المشروع فوضى، ثم ينقضون عليه. هذا أصعب بكثير.
كيف تبدأ اليوم، حتى لو كان لديك فريق صغير
هذا ليس مشروعاً يحتاج إلى شهرين. اليوم، في جلسة عمل واحدة:
1. افتح tailwind.config.js وأضف الألوان والفراغات والأحجام التي تحتاجها فعلاً.
2. اكتب 3 components بسيطة (زرّ، بطاقة، حقل إدخال) باستخدام الفئات من الإعداد.
3. أضف ESLint و Prettier إلى مشروعك.
4. اكتب ملف README بسيط يقول "إذا كنت تريد فئة جديدة، أضفها في tailwind.config وليس في الكود."
هذا كل شيء. من هنا، الفريق ينما حول هذا الأساس. المشاريع الصحيحة التي رأيتها بدأت بهذا.
الخلاصة: الاستثمار اليوم = راحة الفريق غداً
Tailwind قوية، لكنها تحتاج إلى نمط. الفرق الكبيرة تحتاج إلى ثلاثة أشياء فقط: إعداد مركزي واضح، فصل بين components والفئات، وأدوات تضمن الالتزام. بدء صغير من اليوم يوفر ساعات من الصداع لاحقاً، والأهم، يجعل فريقك الجديد ينتج من اليوم الأول.
إذا كانت لديك فريق يعاني من فوضى Tailwind الآن، قد يكون الوقت قد حان للبدء من جديد مع نمط واضح. هذا استثمار صغير مقابل الوقت الذي ستوفره.
عندما تريد فريقاً يعرف كيفية عمل هذا بشكل صحيح، أو تريد تدقيق مشروعك الحالي، تواصل عبر واتساب. قدنا مئات المشاريع في الكويت والخليج، وهذا أحد الأشياء التي نفعلها بشكل صحيح.