‏راهنمای اسکیل توکن‌های طراحی بدون خراب کردن سیستم

تو این مقاله اومده که یه سیستم توکن طراحی که رو ۵۰ تا توکن خوب کار می‌کنه، معمولا رو ۵۰۰ تا می‌شکنه. نویسنده می‌گه مشکل از تعداد نیست، از حاکمیته: هیچ‌کس از اول مشخص نکرده مالک تغییرات کیه، تغییر اسم چطور تو کل سیستم پخش می‌شه، یا وقتی دو تیم هم‌زمان به یه مقدار پایه نیاز متفاوت دارن چی باید بشه. اسم‌گذاری‌های اولیه مثل blue-500 یا btn-bg هم بعد از چندصد توکن دیگه مشخص نیست کدوم primitive‌ه، کدوم alias معنایی‌ه و کدوم override مخصوص یه کامپوننته.

نویسنده پیشنهاد می‌ده primitive‌ها فقط مقدار خام نگه دارن، توکن‌های معنایی به primitive رفرنس بدن، و کامپوننت‌ها فقط از توکن معنایی استفاده کنن، نه مستقیم از primitive:

{
  "color": {
    "text": {
      "primary": {
        "$value": "{color.primitive.gray.900}"
      }
    }
  }
}

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

پیشنهاد بعدی اینه که با تغییرات شکننده مثل تغییر یه API رفتار کنی: هر تغییر بشکن (تغییر اسم، حذف یه primitive قدیمی) باید یه نسخهٔ major جدید، یه changelog و یه دورهٔ deprecation داشته باشه که اسم قدیمی هنوز کار کنه ولی هشدار بده.

برای پخش تغییرات هم راه‌حل بازبینی دستی بیشتر نیست، بلکه یه پایپ‌لاین تو CIه که از یه منبع مشترک، خروجی CSS، iOS و اندروید رو خودکار می‌سازه و اگه یکیشون آپدیت نباشه، build رو fail می‌کنه. یه تست کنتراست هم قبل از انتشار پیشنهاد می‌ده که مطمئن بشه رنگ متن و پس‌زمینه از حداقل WCAG AA پایین‌تر نیومده.

نکات کلیدی:

• سیستم توکن که رو ۵۰ تا خوب کار می‌کنه، معمولا رو ۵۰۰ تا به‌خاطر نبود حاکمیت روشن می‌شکنه
• primitive (مقدار خام) باید از توکن معنایی (رفرنس به primitive) جدا باشه و کامپوننت‌ها فقط از معنایی استفاده کنن
• تغییرات شکننده مثل نسخه‌گذاری API: major version، changelog و یه دورهٔ deprecation
• ابزاری مثل Style Dictionary تو CI خروجی CSS، iOS (Swift) و اندروید (XML) رو از یه منبع مشترک خودکار بسازه
• قبل از انتشار تست کنتراست رنگ اجرا بشه تا حداقل WCAG AA رعایت بشه