Figma Variables والمكتبات، متزامنة مع الكود

طوال ثمانية أشهر بعد إطلاق الـ tokens، كان لدى Northwind حقيقتان. ملف JSON في المستودع يقول إن أزرق الإجراء هو #1f5ae0، ومكتبة Figma تقول #2160e8، لأن مصمّمًا عدّله قليلًا من أجل تصميم لحملة ثم نشره. كان المهندسون يبنون من لوحة الفحص، فأطلق الموقع التسويقي أزرق وأطلق التطبيق أزرق آخر. الـ tokens لا تحلّ مشكلة الاتّساق إلا إذا قرأت ملفات التصميم والكود من القرارات نفسها.

ربط الطبقات بـ Figma variables

متغيّرات Figma (Figma variables) تحمل قيمًا قابلة لإعادة الاستخدام مثل الألوان والأرقام، مجمّعة في collections. ويمكن أن يكون للـ collection عدّة modes، يعطي كلٌّ منها كل متغيّر في المجموعة قيمة مختلفة. ويمكن أيضًا لمتغيّر أن يكون اسمًا مستعارًا لمتغيّر آخر. وهذا يكفي لعكس معمارية الـ tokens تقريبًا واحدًا لواحد:

أسماء المتغيّرات تستخدم الشرطات المائلة لتشكيل المجموعات، فيظهر color/action/bg كمسار مجموعة في المنتقي، ويقابل الـ token المسمّى color.action.bg. وتختار الإطارات (frames) في Figma الـ modes كما تفعل الـ attribute selectors في CSS: يمكن للإطار أن يحدّد mode صراحة، وكل ما بداخله مضبوط على Auto يرث ذلك الـ mode، فيعمل إطار واجهة رئيسية داكن على صفحة فاتحة تمامًا مثل data-theme="dark" على قسم.

وللعلامات، تسمح لك المجموعات الممتدّة (extended collections) في Figma، المتاحة على خطة Enterprise، بإنشاء collection لـ Tidewater ترث من المجموعة الدلالية لـ Northwind وتخصّص متغيّرات العلامة وحدها. والتحديثات على المتغيّرات التي لم تخصّصها Tidewater تمرّ تلقائيًا. وعلى الخطط الأخرى، تحقّق لك collection منفصلة باسم Brand بـ mode لكل علامة معظم الطريق.

اجعل المتغيّر الصحيح هو الأسهل

إعدادان أهمّ من أي نظام تسمية. الأول: أخفِ الـ primitives من النشر. تستطيع المجموعة الدلالية أن تشير إليها، لكن المصمّمين في ملفات المنتجات لا يرون إلا المتغيّرات الدلالية، وهذه بالضبط القاعدة التي تتبعها المكوّنات في الكود. والثاني: أعطِ كل متغيّر منشور صيغة كود (code syntax): فيعرض Dev Mode حينها var(--nw-color-action-bg) بدل قيمة hex، فيكون ما اختاره المصمّم هو حرفيًا ما يكتبه المهندس. وتحديد النطاق (scoping) يساعد أيضًا: اقصر متغيّرات الألوان على الخصائص المقصودة لها، حتى لا يظهر لون نص في منتقي التعبئة.

حلقة المزامنة

ما زال المصمّمون يصمّمون في Figma؛ لكنهم فقط لا ينشرون قيم الـ tokens مباشرة. يبدأ التغيير في branch من ملف المكتبة (الـ branching متاح على خطتي Organization وEnterprise في Figma)، حيث يستطيع المصمّم تجربته في تصاميم حقيقية. وحين يجهز، تُصدَّر الـ modes المتغيّرة كـ JSON: إذ يستطيع Figma تصدير modes المجموعة واستيرادها بصيغة DTCG. ويصبح التصدير pull request على مستودع الـ tokens، حيث يشغّل الـ CI الفحوص من القسم 2، ويراجعه مصمّم ومهندس من النواة. وبعد الإصدار، يُستورد ملف JSON الخاص بالإصدار إلى ملف المكتبة الرئيسي ويُنشر تحديث المكتبة.

بعض الفرق تؤتمت الخطوة الأخيرة بـ plugin أو بـ REST API الخاص بـ Figma. أما Northwind فتفعلها يدويًا مرة في كل إصدار؛ تستغرق عشر دقائق، ونظرة بشرية إلى لوحة المتغيّرات التقطت مرتين استيرادًا خاطئًا.

الحلقة نفسها تعمل مع المكوّنات، إذ يربط Code Connect مكوّنات Figma بالكود الخاص بها في Dev Mode. في التمرين ترتّب خطوات تغيير token. وبعدها تعطي هذه الإصدارات أرقامًا تخبر الفرق بما سيفعله التحديث بها.