‏هنوز کامپوننت قابل‌استفادهٔ مجدد نساز

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

نویسنده یه تجربهٔ خودش رو تعریف می‌کنه. سه workflow داشته: تأیید یه آیتم، تغییر تنظیماتش، و جابه‌جا کردنش. ظاهرشون شبیه بود، با همون جدول و پاپ‌آپ و toast، پس یه کامپوننت ItemAction براشون ساخت. ولی این شباهت سطحی بود. تأیید یه ادعا دربارهٔ آینده‌ست، تغییر فوری انجام می‌شه، و جابه‌جایی به سیستم دیگه‌ای وابسته‌ست که ممکنه درخواست رو رد کنه. بعد از چند هفته propهای کامپوننت این شکلی شد:

type ItemActionProps = {
  item: Item;
  mode: "approve" | "change" | "move";
  variant?: "inline" | "dialog" | "bulk";
  requireReason?: boolean;
  onSpecialCase?: (item: Item) => boolean;
};

هر فلگ جدید یه دلیل منطقی داشت، ولی نتیجه این شد که هر تغییری تو فرایند تأیید، نیاز به موافقت هر سه صاحب workflow و تست همهٔ ترکیب‌های mode و variant داشت. نویسنده می‌گه انتزاع بر اساس شباهت‌های امروز ساخته می‌شه، ولی تفاوت‌ها بعداً پیدا می‌شن: یه سیاست جدید، یه یافتهٔ audit، یه integration که اون‌طور که انتظار داشتی رفتار نمی‌کنه. اون تفاوت‌ها جایی جز فلگ ندارن.

تست پیشنهادی نویسنده اینه: اگه این نیازمندی عوض شه، با کی باید مشورت کنم و آیا همهٔ کپی‌ها با هم عوض می‌شن؟ مثلاً formatExpiry رو می‌شه مشترک کرد، چون یه تصمیم محصولی دربارهٔ شکل تاریخ همهٔ صفحه‌ها رو عوض می‌کنه. ولی دو خط api.post که عین هم به نظر میان، یکی با سیاست تأیید عوض می‌شه و یکی با قوانین اعتبارسنجی. این تصادفه، نه تکرار. این ایده هم جدید نیست: «قانون سه» از Don Roberts تو کتاب Refactoring مارتین فاولر، مقالهٔ The Wrong Abstraction از Sandi Metz و AHA programming از Kent C. Dodds همین رو می‌گن.

البته نویسنده نمی‌گه هیچ‌وقت انتزاع نساز. چیزهایی مثل دکمه و input، design token ها، رفتارهای دسترس‌پذیری مثل focus trap و هر چیزی که یه استاندارد بیرونی شکلش رو تعیین می‌کنه (مثل فرمت تاریخ و پول) از روز اول ارزش اشتراک دارن. یه تست سریع هم پیشنهاد می‌ده: به لیست propها نگاه کن. اگه می‌گن چی رندر شه (children، size، tone) احتمالاً خوبه. اگه می‌گن تو چه موقعیتی هستی (mode، variant، isSpecial) احتمالاً چند چیز متفاوت رو قاطی کردی. راه درمانش هم اینه که کد مشترک رو به هر جای استفاده برگردونی، شاخه‌های بی‌استفاده رو پاک کنی و بعد فقط تیکه‌های واقعاً مشترک رو جدا کنی.

نکات کلیدی:

• تا وقتی یه الگو سه بار با یه دلیل یکسان برای تغییر تکرار نشده، کد رو کپی کن.
• دو کد فقط وقتی تکرار واقعی‌ان که یه تصمیم از یه نفر هر دو رو همزمان عوض کنه.
• propهایی مثل mode، variant و isSpecial نشونهٔ انتزاع اشتباهن.
• دکمه‌ها، design token ها، دسترس‌پذیری و فرمت‌های استاندارد از اول ارزش اشتراک دارن.
• برای درمان، کد مشترک رو inline کن، کد رو بر اساس workflow جدا کن و بعد تیکه‌های کوچیک مشترک رو بیرون بکش.