‏چیزی که spec کامپوننت جا می‌ذاره

Nathan Curtis تو نوشتهٔ تازه‌ش سراغ یه سؤال ساده می‌ره: قرارداد یا contract یه کامپوننت (یعنی همون فایل markdown یا json که نیت طراحی رو برای مهندس و ایجنت توصیف می‌کنه) واقعاً چقدر از اون نیت رو حمل می‌کنه؟ به گفتهٔ اون خیلی از تیم‌ها رنگ و شکل و جدول propها رو بیرون می‌دن و فکر می‌کنن کار تمومه، در حالی که پیچیده‌ترین بخش‌های نیت طراحی سر راه گم می‌شن.

مثال‌هایی که برای lossy بودن این تبدیل می‌آره خیلی مشخصن: بیرون دادن کد hex به جای توکن رنگی که واقعاً bind شده، جا انداختن maxWidth که فقط روی آخرین گزینه از چند گزینه اعمال شده، یا ندیدن تغییر backgroundColor وقتی selected:true و state:hover همزمان اتفاق می‌افتن. نویسنده می‌گه بدترین نوع این خطاها همون‌هایی‌ان که با نگاه چشمی به فایل Figma اصلاً دیده نمی‌شن.

بحث دومش عمقه. ابزارهایی که فقط محورهای variant رو تک‌تک مقایسه می‌کنن variantDepth:1 دارن و اونایی که ترکیب دوتایی propها رو می‌سنجن variantDepth:2. کرتیس می‌گه اکثر ابزارها از دو سطح جلوتر نمی‌رن، ولی خودش Specs رو همیشه با variantDepth:9999 اجرا می‌کنه تا هیچ variant و لایه و bindingی از قلم نیفته. حرف اصلیش اینه که یه قرارداد کم‌عمق round trip بی‌نقص می‌ده، ولی این بی‌نقصی گمراه‌کننده‌ست چون از اول چیز زیادی حمل نکرده.

برای تست، اون یه دستور render ساخته که spec رو با اسکریپت به کامپوننت Figma برمی‌گردونه، و بعد یه حلقهٔ شش‌مرحله‌ای می‌سازه: از کامپوننت موجود یه spec پایه generate کن، از اون یه کامپوننت تستی render کن، از کامپوننت تستی دوباره spec بگیر، دو تا spec رو diff کن، گزارش بساز و کامپوننت تستی رو پاک کن. گزارش، فیچرهای پیاده‌نشده رو از باگ و رگرسیون جدا می‌کنه و ازش issueهای اولویت‌دار در می‌آد.

نتیجه‌ای که خودش انتظارش رو نداشت اینه که diff هیچ‌وقت به صفر نمی‌رسه و قرار هم نیست برسه. به گفتهٔ اون diff روی چند تا دستهٔ قابل نام‌گذاری همگرا می‌شه: فرض‌هایی که حالا صریح شدن، باگ‌هایی که باید درست بشن، و چیزهایی که قرارداد نمی‌تونه یا هنوز نمی‌خواد حمل کنه. یعنی ارزش این تمرین بیشتر از رفع باگه؛ بهت اجازه می‌ده دقیقاً اسم شکاف‌ها رو ببری و به بقیه بگی.

نکات کلیدی:

• variantDepth:1 فقط محورهای variant رو می‌سنجه و variantDepth:2 ترکیب دوتایی propها؛ نویسنده با ۹۹۹۹ اجرا می‌کنه
• حلقهٔ تست شش قدم داره: generate، render، generate دوباره، diff، report و delete
• تبدیل نام Figma به camelCase یا snake_case خودش lossyه؛ راه‌حلش یه safe key grammar و کلید figmaKey بود
• ترتیب دلخواه propها تو پنل Figma از طریق plugin API قابل انتقال نیست
• پشتیبانی از دادهٔ motion فیگما فعلاً تو برنامه نیست، چون مدلش پیچیده و پرهزینه‌ست