fetch

يقوم Next.js بتمديد واجهة برمجة تطبيقات fetch() الخاصة بالويب للسماح لكل طلب على الخادم بتعيين دلالات التخزين المؤقت الدائمة وإعادة التحقق الخاصة به.

في المتصفح، يشير خيار cache إلى كيفية تفاعل طلب fetch مع ذاكرة التخزين المؤقت HTTP للمتصفح. مع هذا الامتداد، يشير cache إلى كيفية تفاعل طلب fetch من جانب الخادم مع ذاكرة التخزين المؤقت للبيانات الدائمة للإطار.

يمكنك استدعاء fetch مع async و await مباشرة داخل مكونات الخادم.

export default async function Page() {
  let data = await fetch('https://api.vercel.app/blog')
  let posts = await data.json()
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

export default async function Page() {
  let data = await fetch('https://api.vercel.app/blog')
  let posts = await data.json()
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  )
}

fetch(url, options)

بما أن Next.js يمتد واجهة برمجة تطبيقات fetch() الخاصة بالويب، يمكنك استخدام أي من الخيارات الأصلية المتاحة.

options.cache

تكوين كيفية تفاعل الطلب مع ذاكرة التخزين المؤقت للبيانات في Next.js.

fetch(`https://...`, { cache: 'force-cache' | 'no-store' })

• auto no cache (الافتراضي): يقوم Next.js بجلب المورد من الخادم البعيد في كل طلب أثناء التطوير، ولكن سيتم الجلب مرة واحدة أثناء next build لأن المسار سيتم تقديمه مسبقًا بشكل ثابت. إذا تم اكتشاف واجهات برمجة تطبيقات ديناميكية على المسار، فسيقوم Next.js بجلب المورد في كل طلب.
• no-store: يقوم Next.js بجلب المورد من الخادم البعيد في كل طلب، حتى إذا لم يتم اكتشاف واجهات برمجة تطبيقات ديناميكية على المسار.
• force-cache: يبحث Next.js عن طلب مطابق في ذاكرة التخزين المؤقت للبيانات.
  • إذا كان هناك تطابق وكان حديثًا، فسيتم إرجاعه من ذاكرة التخزين المؤقت.
  • إذا لم يكن هناك تطابق أو تطابق قديم، فسيقوم Next.js بجلب المورد من الخادم البعيد وتحديث ذاكرة التخزين المؤقت بالمورد الذي تم تنزيله.

options.next.revalidate

fetch(`https://...`, { next: { revalidate: false | 0 | number } })

تعيين عمر ذاكرة التخزين المؤقت للمورد (بالثواني).

• false - تخزين المورد مؤقتًا إلى أجل غير مسمى. يعادل دلاليًا revalidate: Infinity. قد تقوم ذاكرة التخزين المؤقت HTTP بإزالة الموارد القديمة بمرور الوقت.
• 0 - منع تخزين المورد مؤقتًا.
• number - (بالثواني) تحديد أن عمر ذاكرة التخزين المؤقت للمورد يجب أن يكون على الأكثر n ثانية.

جيد أن تعرف:

• إذا قام طلب fetch() فردي بتعيين رقم revalidate أقل من الافتراضي revalidate للمسار، فسيتم تقليل فاصل إعادة التحقق للمسار بالكامل.
• إذا كان هناك طلبا fetch بنفس URL في نفس المسار لهما قيم revalidate مختلفة، فسيتم استخدام القيمة الأقل.
• لتسهيل الأمر، ليس من الضروري تعيين خيار cache إذا تم تعيين revalidate إلى رقم.
• الخيارات المتضاربة مثل { revalidate: 3600, cache: 'no-store' } ستؤدي إلى حدوث خطأ.

options.next.tags

fetch(`https://...`, { next: { tags: ['collection'] } })

تعيين علامات ذاكرة التخزين المؤقت للمورد. يمكن بعد ذلك إعادة التحقق من البيانات عند الطلب باستخدام revalidateTag. الحد الأقصى لطول العلامة المخصصة هو 256 حرفًا والحد الأقصى لعدد عناصر العلامة هو 128.

استكشاف الأخطاء وإصلاحها

عدم ظهور البيانات الجديدة في التطوير مع الإعداد الافتراضي auto no store و cache: 'no-store' في fetch

يقوم Next.js بتخزين استجابات fetch في مكونات الخادم عبر استبدال الوحدة الساخنة (HMR) في التطوير المحلي لتحقيق استجابات أسرع وتقليل تكاليف استدعاءات API المدفوعة.

بشكل افتراضي، يتم تطبيق ذاكرة التخزين المؤقت HMR على جميع طلبات fetch، بما في ذلك تلك التي تحتوي على الخيار الافتراضي auto no cache و cache: 'no-store'. هذا يعني أن الطلبات غير المخزنة مؤقتًا لن تعرض بيانات جديدة بين تحديثات HMR. ومع ذلك، سيتم مسح ذاكرة التخزين المؤقت عند التنقل أو إعادة تحميل الصفحة بالكامل.

راجع وثائق serverComponentsHmrCache لمزيد من المعلومات.

سجل الإصدارات