مفهوم revalidatePath

برای زمانی است که می‌خواهی کش مربوط به یک مسیر (route) در Next.js نامعتبر شود، بدون اینکه لازم باشد بدانی داخل آن صفحه چه داده‌هایی با چه tagهایی کش شده‌اند.

منطقش این است که Next.js برای هر صفحه یا route، نتیجهٔ رندر و داده‌های وابسته به آن را در کش نگه می‌دارد. وقتی revalidatePath('/profile') را صدا بزنی، به Next.js می‌گویی:

«هر چیزی که برای رندر صفحهٔ /profile کش شده، دیگر معتبر نیست و باید دوباره ساخته شود.»

در نتیجه درخواست بعدی برای آن مسیر باعث می‌شود صفحه دوباره رندر شود و داده‌ها دوباره از منبع اصلی گرفته شوند.

نکتهٔ مهم این است که revalidatePath بر اساس route کار می‌کند، نه بر اساس داده. یعنی اگر صفحهٔ /profile چندین تابع کش‌شده، چند fetch یا چند component داشته باشد، همهٔ آن‌ها برای آن مسیر نامعتبر می‌شوند. به همین دلیل می‌گویند این روش کم‌دقت‌تر است و ممکن است کش بیشتری از حد لازم را invalid کند.

به همین دلیل در مستندات توصیه شده که اگر می‌توانی از tag-based invalidation استفاده کنی (cacheTag + revalidateTag یا updateTag). چون در آن حالت فقط دادهٔ خاصی که تغییر کرده invalidate می‌شود، نه کل صفحه.

از revalidatePath معمولاً در این موقعیت‌ها استفاده می‌شود:

اول، وقتی صفحه‌ای داری که tagگذاری نکرده‌ای و نمی‌دانی چه داده‌هایی داخلش کش شده‌اند. در این حالت ساده‌ترین راه این است که کل مسیر را revalidate کنی.

دوم، وقتی یک صفحهٔ مشخص باید بعد از یک mutation دوباره ساخته شود. مثلاً کاربر پروفایلش را ویرایش می‌کند و می‌خواهی دفعهٔ بعد که /profile باز شد حتماً نسخهٔ جدید رندر شود.

سوم، برای صفحات استاتیک یا prerender شده که بعد از تغییر داده باید دوباره ساخته شوند.

خلاصهٔ منطقی تفاوت‌ها:

• revalidatePath → invalid کردن کش در سطح صفحه / route

• revalidateTag → invalid کردن کش در سطح داده

• updateTag → invalid فوری داده برای اینکه کاربر فوراً تغییر خودش را ببیند

قاعدهٔ عملی که اکثر پروژه‌ها استفاده می‌کنند این است:

اگر داده‌ها را tag کرده‌ای، از tag-based invalidation استفاده کن.

اگر نمی‌دانی داده‌ها چه tagی دارند یا می‌خواهی کل یک صفحه دوباره ساخته شود، از revalidatePath استفاده کن.