سه روش مهم فچ در نکست و مزیت ها

برای یادداشت‌برداری، تفاوت و جایگاه این سه روش را به صورت خلاصه و دسته‌بندی‌شده در ادامه آورده‌ام:

1. روش Suspense با کامپوننت واسط (Async Server Component)

این روش استاندارد و پیش‌فرض Next.js (App Router) است.

• جایگاه (محل اجرا): کاملاً سمت سرور.

• نحوه فچ: سرور درخواست را می‌فرستد، await می‌کند و بعد از دریافت دیتا، HTML نهایی را می‌سازد. در این حین Suspense پوسته لودینگ را به کاربر نشان می‌دهد.

• سرعت اجرا: بالاترین سرعت در بارگذاری اولیه (Initial Load). چون مرورگر کلاینت هیچ درخواست شبکه‌ای برای دیتا نمی‌فرستد و مستقیماً HTML آماده را دریافت می‌کند.

• مزیت اصلی: بهترین انتخاب برای SEO. امنیت بالا (کدهای فچ و API Key ها در سرور می‌مانند). عدم درگیری منابع مرورگر کاربر.

2. روش پاس دادن Promise و استفاده از use

این روش برای استریم کردن دیتا از سرور به یک Client Component بدون متوقف کردن سرور است.

• جایگاه (محل اجرا): فچ در سرور شروع می‌شود (بدون await)، اما نتیجه در کلاینت (توسط هوک use) خوانده و مصرف می‌شود.

• نحوه فچ: سرور یک Promise می‌سازد و آن را به عنوان Prop به کلاینت می‌فرستد. کلاینت کامپوننت با خواندن آن توسط use متوقف (Suspend) می‌شود تا دیتا استریم شود.

• سرعت اجرا: زمان رسیدن به اولین بایت (TTFB) بسیار سریع است چون سرور منتظر دیتا نمی‌ماند. کاربر بلافاصله بقیه صفحه را می‌بیند.

• مزیت اصلی: حذف کامپوننت‌های واسط (Wrapper). بسیار عالی برای زمانی که نمی‌خواهید برای یک فچ کوچک، یک فایل Server Component جداگانه بسازید یا زمانی که کامپوننت والد خودش از نوع Client است.

3. روش استفاده از کتابخانه‌های کلاینت (مثل React Query یا SWR)

این روش برای مدیریت دیتای پویا و تعاملی در مرورگر است.

• جایگاه (محل اجرا): کاملاً سمت کلاینت (مرورگر کاربر).

• نحوه فچ: مرورگر ابتدا کدهای جاوااسکریپت و HTML اولیه را دانلود می‌کند، سپس کامپوننت Mount می‌شود و تازه از داخل مرورگر یک ریکوئست شبکه (مثلاً به API بک‌اند) ارسال می‌شود.

• سرعت اجرا: بارگذاری اولیه (First Paint) کندتر است، چون کاربر باید منتظر رفت و برگشت درخواست از مرورگر بماند (آبشار کلاینت). اما در تعاملات بعدی و جابجایی بین صفحات، به دلیل وجود سیستم Caching بسیار سریع است.

• مزیت اصلی: قدرتمندترین روش برای مدیریت چرخه حیات دیتا. دارای قابلیت‌های بی‌نظیر مثل: کش کردن دیتا در مرورگر، Revalidation خودکار (مثلاً هنگام فوکوس روی تب مرورگر)، مدیریت آپدیت‌ها (Mutations) و همگام‌سازی پس‌زمینه. ایده‌آل برای داشبوردهای کاربری و دیتای خصوصی/پویا.

خلاصه برای تصمیم‌گیری (TL;DR):

• دیتای اصلی و سئو محور صفحه: روش 111 (Server Component + Suspense)

• نیاز به استریم مستقیم یک بخش به کلاینت بدون کامپوننت واسط: روش 222 (Promise + use)

• دیتای تعاملی، داشبورد کاربری و نیاز به کش/آپدیت مداوم: روش 333 (React Query)

دقت کنید مزیت های روش دوم نسبت به روش اول اغراق نشه:
نمی‌توان گفت روش اول هیچ مزیتی ندارد. اگرچه در ظاهر روش دوم همان کار را با کُد کمتر (بدون کامپوننت واسط) انجام می‌دهد، اما تفاوت‌های معماری مهمی دارند که باعث می‌شود روش اول (Async Server Component) همچنان روش استاندارد و ارجح در Next.js باشد.

مزایای روش اول نسبت به روش دوم:

111. پردازش در سرور و کاهش حجم باندل (Bundle Size):

در روش اول، کامپوننت واسط یک Server Component است. شما می‌توانید داده‌ها را پس از await کردن، فیلتر کنید، تغییر شکل دهید و فقط بخش مورد نیاز را به Client Component پاس بدهید. تمام کتابخانه‌هایی که برای این پردازش استفاده می‌کنید در سرور می‌مانند و به مرورگر کاربر ارسال نمی‌شوند.

222. سادگی و خوانایی کد:

استفاده از await یک استاندارد جاوااسکریپتی جاافتاده، خوانا و قابل پیش‌بینی است. دیباگ کردن دیتای آماده در سرور بسیار راحت‌تر از پیگیری یک Promise در حال استریم بین سرور و کلاینت است.

333. محدودیت‌های انتقال داده (Serialization):

پاس دادن دیتای خام و حل‌شده (مثل یک آبجکت JSON) از سرور به کلاینت (روش اول) بسیار امن‌تر و پایدارتر است. پاس دادن Promise از مرز سرور به کلاینت (روش دوم) پیچیدگی‌های خاص خودش را دارد و Next.js باید آن را سریالایز کند.

نتیجه:

الگوی پیش‌فرض و توصیه شده معماری App Router همان روش اول است. روش دوم (Promise + use) بیشتر به عنوان یک “ابزار فرار” (Escape Hatch) برای مواقعی طراحی شده که ساختار درختی کامپوننت‌های شما اجازه ساخت کامپوننت واسط سروری را نمی‌دهد (مثلاً وقتی کامپوننت والد خودش کلاینت است).