Parallel Routing یکی از قابلیتهای App Router در Next.js (از نسخه 13 به بعد) هست که اجازه میده چند مسیر (Route) رو بهصورت همزمان و مستقل توی یک صفحه رندر کنیم.

یعنی چی؟
فرض کن توی یه صفحه اصلی، چند بخش مختلف داری (مثل Sidebar، Header، Main Content، Chatbox) که هر کدومشون مسیر (route) جدا دارن ولی میخوای بدون رفرش کل صفحه، هر بخش رو مستقل لود و کنترل کنی. Parallel Routing دقیقاً برای همین اومده! 🚀
🔑 مفهوم اسلات (Slot) یا اسلاتهای موازی
Parallel routing از slotها استفاده میکنه:
یک اسلات مثل یه placeholder توی layout هست که هر مسیر رو میتونی داخلش قرار بدی.
مثلاً:
اینجا سه اسلات داریم: @sidebar، @feed، @chat که هرکدوم مسیر و کامپوننت خودش رو داره و میتونه موازی با بقیه رندر بشه.
حالا به این شکل در لی اوت استفاده میکنیم:
داشبوردهای پیچیده: هر بخش داشبورد از یک مسیر جدا بیاد ولی یکجا نشون داده بشه.
اپلیکیشن ایمیل/چت: لیست گفتگوها، جزئیات گفتگو، نوار ابزار همزمان لود بشن.
UI چندبخشی: مثلا صفحه پروفایل که Sidebar، Activity، Friends همزمان باشن.
بهبود UX: وقتی نمیخوای با هر کلیک، کل صفحه لود بشه.
❌ معایب Parallel Routing
⚠️ پیچیدگی پیادهسازی: برای پروژههای ساده اضافیه.
⚠️ ذهنیت جدید لازم داره: باید مفهوم slot و layout رو خوب بفهمی.
⚠️ SEO سختتر میشه: چون URLها پیچیدهتر میشن.
⚠️ کدبیس بزرگتر: ممکنه ساختار فولدر زیاد بشه.
این ویژگی برای سناریوهای پیچیده و دینامیک مناسب است. مواقع اصلی استفاده:
داشبوردها: جایی که چندین پنل مستقل مثل آمار، لیست کاربران و تنظیمات همزمان نمایش داده میشوند (مثل داشبورد GitHub یا Twitter).
فیدها و شبکههای اجتماعی: نمایش همزمان پستها، نوتیفیکیشنها و پروفایل.
رندر شرطی: بر اساس نقش کاربر (مثل ادمین vs. کاربر عادی) محتوای متفاوت نمایش دهید.
مودالها و تبها: ترکیب با Intercepting Routes برای مودالهای deep-linked یا تبهای مستقل.
اپهای بزرگ با navigation مستقل: جایی که هر بخش navigation خودش را دارد بدون تأثیر روی کل صفحه.
اگر اپ شما ساده است (مثل یک بلاگ استاتیک)، از روتینگ معمولی استفاده کنید. اما اگر بخشهای دینامیک زیادی دارید، این ویژگی ضروری میشود.
مزایا (فواید) Parallel Routing
بهبود عملکرد: بارگذاری موازی کاهش زمان TTFB (Time to First Byte) و بهبود سرعت کلی اپ را به همراه دارد.
مدیریت بهتر حالتها: هر اسلات loading، error و suspense خودش را دارد، پس اگر یک بخش خطا بدهد، کل صفحه کرش نمیکند.
انعطافپذیری بالا: امکان رندر شرطی، تبهای مستقل و مودالها بدون نیاز به لایبرریهای خارجی.
بهینه برای SEO و SSR: با Server-Side Rendering کار میکند و صفحات را بهینه نگه میدارد.
کاهش کد تکراری: layoutها را reusable میکند و navigation را سادهتر مدیریت میکند.
در نتیجه، UX را بسیار بهتر میکند، به ویژه در اپهای بزرگ.
معایب Parallel Routing
پیچیدگی بیشتر: یادگیری آن سختتر است و ساختار فولدرها پیچیدهتر میشود (مثل استفاده از @folder). برای تازهکاران میتواند گیجکننده باشد.
باگهای احتمالی: برخی کاربران گزارش دادهاند که در نسخههای اولیه buggy است، مثلاً در navigation یا state management.
Overhead عملکردی در اپهای کوچک: اگر اپ ساده باشد، این ویژگی اضافهکاری است و ممکن است کد را پیچیدهتر کند بدون فایده واقعی.
مهاجرت سخت: اگر از Pages Router به App Router مهاجرت میکنید، پیادهسازی Parallel Routes نیاز به بازنویسی زیادی دارد.
مدیریت state: در navigation سخت (hard navigation)، اسلاتهای unmatched به fallback میروند که ممکن است UX را مختل کند اگر درست مدیریت نشود.
به طور کلی، اگر اپ پیچیده نباشد، ممکن است ارزش دردسرش را نداشته باشد.
چرا از کامپوننت استفاده نکنیم؟ به خاطر اینکه میخوای ویژگی های یک صفحه رو در بخش های یک پیج داشته باشیم مثلا این ها :
1️⃣ URL مستقل برای هر بخش (Route Independence)
وقتی از @slot/page.tsx استفاده میکنی، هر بخش یک مسیر (Route) مستقل در Next.js داره.
یعنی Next.js این بخش رو مثل یک صفحه کامل میبینه، میتونی برای هر بخش URL، Query Params یا Dynamic Route داشته باشی.
این برای اشتراکگذاری لینک مستقیم به یک تب یا بخش خاص فوقالعاده است.
🔹 مثال:
/dashboard?tab=chat → با Parallel Routing حتی بدون Refresh، Chat در Slot مربوطه لود میشه.
اگر فقط یک کامپوننت ساده داشته باشی، باید خودت همه stateها و params رو مدیریت کنی.
هر page.tsx در Parallel Routing میتونه داده خودش رو Fetch کنه، حتی به صورت Server-side.
یعنی Sidebar از یک API، Feed از یک API دیگه و Chat از یک API دیگه میاد، بدون اینکه یکدیگر رو بلاک کنن.
اگر اینا کامپوننت باشن، باید یک API Call سنگین در Parent Layout بزنی و همه دادهها رو بریزی پایین → کند و غیرماژولاره.
Parallel Routing به Next.js اجازه میده هر Slot رو جدا Stream کنه.
فرض کن Sidebar سریع لود میشه ولی Feed طول میکشه. با Parallel Routing:
Sidebar فوری نمایش داده میشه.
Feed بعداً اضافه میشه.
اگر همهچیز داخل یک کامپوننت باشه، کل صفحه تا گرفتن همه دادهها متوقف میشه.
هر Slot میتونه فایل error.tsx خودش رو داشته باشه.
اگر فقط یکی از Slotها خطا بده، بقیه صفحه سالم میمونه.
در مقابل، اگر فقط کامپوننت باشه، یک خطا ممکنه کل صفحه رو بترکونه.
میتونی برای هر Slot یک loading.tsx بذاری.
یعنی UI هر بخش در حال بارگذاری شخصیسازی میشه.
اگر همهچیز یک کامپوننت باشه، باید دستی کلی state بنویسی.
Next.js میتونه هر بخش (Slot) رو جدا Prefetch کنه و Cache کنه.
یعنی وقتی کاربر بین بخشها جابجا میشه، نیازی به رفرش کل صفحه نداره.
در حالت کامپوننت، خودت باید caching رو دستی پیاده کنی.
Parallel Routing بهت اجازه میده:
اگر یک بخش موجود نباشه، default.tsx نمایش داده بشه.
یا با not-found.tsx برای همون بخش 404 بده.
🔹 مثال:
کاربر /chat/123 باز کرده ولی Chat ID 123 وجود نداره → فقط Chat Slot خطا میده، بقیه صفحه سالمه.
میتونی اسلاتهای داینامیک بسازی و بر اساس Context، تصمیم بگیری چی نشون بدی.
مثلاً:
app/@tab/(settings)/page.tsx
app/@tab/(inbox)/page.tsx
9️⃣ بهبود ساختار کد و ماژولار بودن (Separation of Concerns)
هر بخش صفحه مثل یک Mini-Page عمل میکنه.
این یعنی تیمهای مختلف میتونن روی بخشهای مختلف کار کنن بدون اینکه یکدیگر رو بلاک کنن.
در پروژههای بزرگ (مثلاً داشبورد SaaS با ۱۰ها تب) این تفاوت فاحشه.
هر Slot page.tsx میتونه generateMetadata داشته باشه.
یعنی Title و Meta Tag هر بخش مستقل مدیریت میشه.
💡 به زبان ساده:
Parallel Routing یعنی هر بخش UI تبدیل میشه به یک Route واقعی که Next.js مدیریت میکنه → این یعنی هوشمندی، سرعت، و انعطاف بالاتر.
اگر فقط UI ثابت میخوای یا همهچیز خیلی سادهست، نیازی به Parallel Routing نداری.
رفرنس: