بناء أنظمة تصميم قابلة للتوسع في Figma و React

نظام التصميم المجزأ يؤدي إلى تجربة مستخدم مجزأة. عندما ينقر مستخدم على زر "إرسال" في صفحة الدفع الخاصة بك ويبدو مختلفاً قليلاً عن زر "إرسال" في صفحة الاتصال الخاصة بك، تنكسر الثقة اللاوعية. مفتاح السرعة في تطوير الواجهة الأمامية — والاتساق في تجربة المستخدم — هو إنشاء مصدر واحد للحقيقة يمتد عبر كل من أدوات التصميم وقاعدة الكود.

قوة رموز التصميم (Design Tokens)

أكبر خطأ ترتكبه الفرق الهندسية عند تنفيذ نظام تصميم هو برمجة قيم محددة بشكل ثابت. بدلاً من كتابة قيم سداسية عشرية ثابتة مثل #1E7594 أو قيم حشو مثل 16px، نقوم بتعيين كل شيء إلى رموز دلالية (مثل color-brand-primary، spacing-md).

لماذا؟ لأنه عندما تحدث إعادة تسمية العلامة التجارية، ويتغير لون العلامة التجارية الأساسي من الأزرق إلى الأرجواني في Figma، لا ينبغي أن يتطلب ذلك من المطور تنفيذ بحث واستبدال عالمي للرموز السداسية العشرية يدوياً عبر مئات ملفات React. هذا النهج هش ومضمون أن يغفل عن الحالات الطرفية.

مسارات الرموز وأتمتة CI/CD

من خلال أدوات مثل Style Dictionary من Amazon أو واجهة برمجة تطبيقات Variables الأصلية في Figma، يمكننا تصدير هذه الرموز الدلالية كملفات JSON. نقوم بعد ذلك ببناء مسار آلي باستخدام GitHub Actions. عندما يقوم المصمم بتحديث رمز في Figma وينقر على "نشر"، يقوم Webhook بتشغيل مسار CI. يقوم المسار بتنزيل JSON الجديد، ويحول الرموز إلى خصائص CSS مخصصة (متغيرات)، ويولد تكوين Tailwind جديداً، ويجمع تعريفات TypeScript. أخيراً، يفتح تلقائياً طلب سحب (Pull Request) في مستودع الواجهة الأمامية الرئيسي.

هذا يعني أن تغييرات التصميم يتم نشرها في الكود بشكل مستقل تماماً. لم يعد التصميم صورة؛ إنه كود.

هندسة المكونات في React

يتطلب نظام التصميم القوي في الكود حدوداً صارمة لواجهة برمجة التطبيقات للمكونات. نحن نستفيد من TypeScript لفرض التحقق من الخصائص بقوة بحيث لا يمكن للمطورين مادياً استخدام المكون بشكل غير صحيح دون أن يلقي المترجم خطأً.

• المكونات متعددة الأشكال (Polymorphic): قد تحتاج إلى مكون Button يبدو كزر، ولكن يجب أن يكون دلالياً علامة <a> لـ SEO، أو <Link> في React Router للتوجيه من جانب العميل. باستخدام نمط خاصية as، نبني مكونات متعددة الأشكال تحافظ على نفس واجهة التصميم الدقيقة بغض النظر عن عقدة DOM الأساسية.
• المكونات المركبة: لا ينبغي تكوين عناصر واجهة المستخدم المعقدة مثل القوائم المنسدلة أو النوافذ المنبثقة عبر خصائص ضخمة ومتداخلة بعمق. بدلاً من ذلك، نستخدم نمط المكون المركب (<Modal.Root>، <Modal.Header>) لمنح المستهلك أقصى قدر من المرونة في التخطيط مع مشاركة الحالة الضمنية عبر React Context.
• إمكانية الوصول أولاً: يجب أن يمر كل مكون بمعايير WCAG الصارمة بمجرد إخراجه من الصندوق. لا ينبغي أن يضطر المطورون إلى تذكر إضافة aria-expanded أو معالجة محاصرة تركيز لوحة المفاتيح. نحن نستخدم مكتبات واجهة المستخدم بدون رأس مثل Radix UI لمعالجة آلات الحالة المعقدة لإمكانية الوصول، مع تطبيق رموز نظام التصميم الخاص بنا في الأعلى.

"تعامل مع نظام التصميم الخاص بك كمنتج داخلي. إنه يحتاج إلى توثيق، وإصدارات، وفريق مخصص، أو سيتعفن بسرعة إلى دين إرث."

التحول الثقافي: عملية التسليم

عادة ما يحدث الاحتكاك بين التصميم والهندسة أثناء "التسليم". تشتكي الهندسة من أن التصميم مستحيل البناء، ويشتكي التصميم من أن التنفيذ لا يشبه ملف Figma.

من خلال التعامل مع Figma كقاعدة بيانات حرفية لقرارات التصميم وفرض استخدام الرموز بصرامة في الكود، نقوم بتغيير الثقافة من "إليك صورة لما يجب بناؤه" إلى "إليك نظام الرموز الموحد الذي نستهلكه كلانا." هذا يخلق لغة مشتركة. عندما يبدو الزر خاطئاً في مرحلة الاختبار، فإن المحادثة لا تتعلق بدفع البكسلات؛ بل تتعلق بالتحقق من مسار تعيين الرموز.