‏کامپوننت لایبرری داری، دیزاین سیستم نه

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

برای اینکه این شکاف رو نشون بده، سه تا ایجنت رو جدا از هم گذاشت جلوی یه دنیای کاملاً یکسان: همون کامپوننت لایبرری (shadcn/ui روی Base UI)، همون لایهٔ توکن و همون پوستهٔ اپ، بدون اینکه کار همدیگه یا هیچ صفحهٔ تنظیمات قبلی رو ببینن. تیکت‌ها هم سه محصول متفاوت بودن: مدیریت پروژه، ترافیک و صورتحساب. خروجی سه تا چیدمان متفاوت شد، در حالی که هر سه از API لایبرری درست استفاده کرده بودن و یه لینترِ توکن احتمالاً به همه‌شون سبز می‌داد.

به گفتهٔ نویسنده ایراد از خود کامپوننت‌ها نیست، از composition میاد، یعنی از اینکه قطعه‌ها کنار هم چطور یه صفحه می‌سازن. هیچ‌کس جواب قطعیِ «صفحهٔ تنظیمات اینجا یعنی چی» رو در اختیار سازنده‌ها نذاشته بود. جاش پاکت هم همین رو تو مقیاس بزرگ‌تر دیده: شش قابلیت اصلی X روی چهار معماری ویوی مختلف ساخته شدن. به گفتهٔ اون، بحث دیزاین سیستم تو دههٔ گذشته بیشتر دور کامپوننت‌ها چرخیده، ولی کار مهم‌تر همین سطح معماریه.

راه‌حلی که مقاله پیشنهاد می‌ده اینه که قضاوت‌های تکراری تبدیل به الگوی قابل‌استفادهٔ دوباره بشن، روی همون پله‌های Atomic Design: اتم‌ها (دکمه و اینپوت و سوییچ)، مولکول‌ها (رفتارهای کوچیکِ تکرارشونده مثل تأیید گرفتن موقع خاموش‌کردن بکاپ)، ارگانیسم‌ها (ردیف تنظیمات با اسم و توضیح و کنترلِ روبه‌روش) و تمپلیت (خود صفحه با ترتیب ثابت گروه‌ها و عملیات خطرناک در انتها). اسم‌گذاری این لایه‌ها یه واژگان مشترک می‌سازه: SettingRow، ValidatedInput و ConfirmableSwitch هرکدوم یه تصمیم رو با خودشون حمل می‌کنن.

دور دوم آزمایش، بدون اینکه تیکت‌ها دقیق‌تر بشن، همون واژگان به‌علاوهٔ قواعدش هم به ایجنت‌ها داده شد و این بار سه تا صفحه خیلی بیشتر شبیه یه محصول واحد درومدن. قواعد چیزی تو این مایه بودن:

/**
 * Rules for every Meridian settings page:
 * - Use SettingsFrame. Do not set a different page width or header layout.
 * - Put related settings in SettingSections. Do not use tabs or a card per setting.
 * - Put identity or account details first. Put "Danger zone" last.
 * - Save each row when its value changes. Do not add Save or Cancel buttons.
 */

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

نکات کلیدی:

• سه ایجنت با کامپوننت لایبرری یکسان (shadcn/ui روی Base UI) و تیکت‌های هم‌ارز، سه چیدمان متفاوت برای صفحهٔ تنظیمات ساختن.
• به گفتهٔ جاش پاکت، شش قابلیت اصلی X روی چهار معماری ویوی مختلف ساخته شدن.
• لینترِ توکن و استفادهٔ درست از API کامپوننت‌ها جلوی ناهماهنگی رو نمی‌گیرن، چون مشکل از composition میاد نه از خود قطعه‌ها.
• واژگان مشترکی مثل SettingsFrame، SettingRow، ValidatedInput و ConfirmableSwitch تصمیم رو به سازندهٔ بعدی منتقل می‌کنن.
• دور دوم آزمایش با همون تیکت‌ها ولی به‌علاوهٔ قواعد نوشته‌شده، خروجی‌های خیلی هماهنگ‌تری داد.