تصميم أنظمة التصميم باستخدام Tailwind وHeroUI بدون فوضى طبقية
من الرموز المميزة والمتغيرات إلى حزمة المكونات المشتركة - كيفية تحويل Tailwind وHeroUI إلى نظام منتج، وليس إلى أدوات مساعدة متناثرة.
علي مرتضوي
مؤسس بارادايس كود
يبدأ نظام التصميم قبل المكونات
إذا بدأت باستخدام Button وتخطيت الرموز المميزة، فإنك تقوم بإنشاء مجموعة أدوات واجهة المستخدم، وليس نظامًا. أسس القفل أولاً: مقياس التباعد، والنوع، ونصف القطر، والظل، واللون الدلالي (أساسي/خطر/نجاح)، وحالات التفاعل. تعبر Tailwind عن هذه الرموز المميزة للموضوع حتى لا تتسرب الفئات الأولية عبر الميزات.
تعمل HeroUI على تسريع التفاعلات التي يمكن الوصول إليها، ولكن بدون طبقة رمزية للمنتج، تخترع كل صفحة لوحة الألوان الخاصة بها. النظام هو القيد المتعمد.
اجعل الرموز رمزية وليست زخرفية
بدلاً من "الأزرق-600" في الميزات، حدد "العلامة التجارية"، و"السطح"، و"كتم الصوت"، و"الخطر". يرتبط اللون الزخرفي بالعلامة التجارية؛ يرتبط اللون الدلالي بدور واجهة المستخدم. عندما تتغير العلامة التجارية، فإنك تقوم بتغيير الرموز المميزة، وليس مئات الفئات.
بالنسبة للموضوعات الفاتحة/الداكنة أو سمات العملاء، قم بتعيين نفس المعاني. إذا قام كل مكون بتشفير ظروف اللون الخاصة به، فسيتم فقدان السمات بالفعل.
المتغيرات والتكوين بدلا من الطبقات المنسوخة
يقطع النمط "cva"/المتغير للحجم والمظهر والحالة سلاسل "className" المتكررة الطويلة. يجب أن تظل واجهات برمجة تطبيقات المكونات قصيرة: `variant`، `size`، `isDisabled`. إذا كان يجب على المتصلين اجتياز عشرة فئات من Tailwind، فهذا يعني فشل التغليف.
السماح بفتحة هروب محدودة (اسم الفئة الذي يتم التحكم فيه) ولكن مواجهتها عند المراجعة بسؤال "لماذا لم يكن النظام كافيًا؟" يؤدي كل استثناء إلى إنشاء رمز مميز جديد أو دين مرئي.
تعامل مع HeroUI باعتباره جوهرًا، وليس غلافًا لتجاوزه
استخدم السلوكيات التي يمكن الوصول إليها - التركيز ولوحة المفاتيح ومربع الحوار - وقم بمحاذاة المظهر مع الرموز المميزة الخاصة بك. تؤدي إعادة كتابة المكونات بالكامل حسب الذوق إلى زيادة تكاليف الصيانة وتجعل ترقيات المكتبة مؤلمة.
عندما لا تغطي HeroUI نمط المنتج، قم ببناء نموذج بدائي وتسجيله في مخزون نظام التصميم. تتحرك الأنظمة الحية بكتالوج واضح، وليس بمكونات يتيمة في الميزات.
مستندات الاستهلاك للمهندسين والمصممين
يجب أن يعرض كتاب القصص القصيرة أو ما يعادله الحالات، وما يجب فعله/لا تفعله، والمسافات، وليس مجرد معرض جميل. لكل مكون: متى يستخدم، المتغير الافتراضي، وما هو الممنوع.
يحتاج المصممون والمهندسون إلى لغة تسمية واحدة. إذا كان الشكل يقول "أساسي / كبير" والكود يقول `variant="solid" size="lg"`، فاكتب جدول التعيين بشكل صريح.
تغيير الحكم دون بيروقراطية
تحتاج تغييرات الرمز المميز إلى علاقات عامة مخصصة ولقطات شاشة للمسارات الرئيسية. تحتاج المتغيرات الجديدة إلى حالة استخدام حقيقية، وليس "ربما لاحقًا".
قم بإجراء تدقيق مرئي قصير كل ثلاثة أشهر: قم بطي الفئات الأولية المتكررة مرة أخرى إلى الرموز المميزة/المكونات. يعد هذا التنظيف أرخص من إعادة كتابة واجهة المستخدم في العام المقبل.
الأسئلة الشائعة
هل Tailwind وحده يكفي بدون مكتبة واجهة المستخدم؟
بالنسبة لمنتج صغير، نعم، لكنك تدفع تكاليف الوصول واتساق التفاعل بنفسك. تعمل HeroUI على تقليل هذه التكلفة عند استهلاك الرمز المميز أولاً.
ما مقدار اسم الفصل المجاني الذي يجب أن نسمح به؟
قليلا، والسيطرة عليها. إذا تكرر النمط، أضف متغيرًا أو رمزًا مميزًا، ولا تنسخ الفئات.
متى يجب أن نبدأ نظام التصميم؟
بمجرد وجود أكثر من سطح واحد، أو تطبيقين مرتبطين. والتأخير يعني سداد الدين البصري مع الفائدة.
المعرفة والمقالات
تحتاج تطبيق هذه المفاهيم في منتجك؟
بارادايس كود معك من الاستشارة حتى التسليم الكامل.