React Router مدل حاکمیت باز رو معرفی کرد
خلاصهٔ کاملتر
به گفتهٔ تیم Remix، بعد از بیش از ۱۰ سال که React Router زیر نظر Michael Jackson و Ryan Florence توسعه پیدا کرده، حالا وقتشه که فرآیندی که چند ساله بهصورت غیررسمی داخل تیم استفاده میشده رسمی شه. نقلقول یکی از سازندهها اینه که این پروژه دیگه فقط بچهٔ اون دو نفر نیست، یه پروژهٔ بالغ متنبازه با میلیونها وابسته، و همه باید تو مسیرش حرفی برای گفتن داشته باشن.
انگیزهٔ اصلی اینه که سطح API بعد از ادغام Remix v2 توی React Router v7 خیلی بزرگ شده، و با اومدن React 19 و پشتیبانی نزدیکِ RSC، خود React داره بخشی از کارهایی که قبلاً React Router انجام میداد رو به عهده میگیره. نویسنده میگه میخوان پروژه رو لاغر نگه دارن، یعنی بدون از دست دادن قابلیتها، چندتا API رو توی یکی جمع کنن یا اونهایی که React جایگزین بهتری داره رو منسوخ کنن.
برای جهتدهی، چند هدف طراحی تعریف شده: «کمتر یعنی بیشتر»، تمرکز روی مسیریابی و داده، مسیر مهاجرت ساده (تغییرات شکننده پشت future flag و با هشدار کنسول قبل از انتشار)، اضافه کردن قابلیتها توی پایینترین حالت ممکن (declarative -> data -> framework)، و انتشار نسخهٔ اصلی بهصورت سالانه.
از نظر قابلیتها، چندتا چیز توی برنامهست: یه هوک useRouterState() برای یککاسه کردن وضعیت روتر، یه جایگزین type-safe برای useRouteLoaderData()، یه الگوی تطبیق مسیر سریعتر و انعطافپذیرتر، و البته RSC. همزمان قراره قابلیتهای unstable فعلی مثل middleware و splitRouteModules مستندسازی و پایدار شن.
نویسنده توضیح میده که بعضی API های پرکاربرد مثل خروجیهای meta و links احتمالاً توی v8 منسوخ و توی v9 حذف میشن، ولی قول میده هیچ API ای حذف نشه مگه اینکه React جایگزینی حداقل به همون خوبی داشته باشه. هدف اینه که تعداد راههای انجام یک کار کم شه تا استفاده از React Router هم برای آدمها و هم برای LLM ها سادهتر شه.
درمورد فرآیند حاکمیت، فعلاً اعضای کمیتهٔ راهبری فقط از تیم Remix هستن، ولی تأکید شده که بازخورد و مشارکت جامعه رو واقعاً میخوان. فرآیند جدید مثل یه قیف عمل میکنه: هرکسی میتونه توی GitHub Discussions یه RFC بنویسه (مرحلهٔ ۰)، و فقط قویترین پیشنهادها از مراحل بعدی رد میشن تا به نسخهٔ پایدار برسن.
نکات کلیدی:
- React Router بعد از ۱۰ سال یه مدل حاکمیت باز رسمی با کمیتهٔ راهبری گرفت
- هدف اصلی: لاغر کردن سطح API و سپردن بخشی از کارها به خود React
- فرآیند پذیرش قابلیتها ششمرحلهایه و الهامگرفته از فرآیند TC39
- قابلیتهای unstable فعلی مثل middleware و splitRouteModules قراره پایدار شن
- API های پرکاربردی مثل meta و links احتمالاً تو نسخههای بعدی منسوخ میشن




