workbox-cacheable-response

هنگام ذخیره دارایی‌ها در زمان اجرا، هیچ قانون یکسانی برای «معتبر بودن» و واجد شرایط بودن یک پاسخ داده شده برای ذخیره و استفاده مجدد وجود ندارد.

ماژول workbox-cacheable-response یک راه استاندارد برای تعیین اینکه آیا یک پاسخ باید بر اساس کد وضعیت عددی آن، وجود یک هدر با یک مقدار خاص یا ترکیبی از این دو در حافظه پنهان ذخیره شود، ارائه می‌کند.

ذخیره سازی بر اساس کدهای وضعیت

می‌توانید با افزودن یک نمونه CacheableResponsePlugin به پارامتر plugins استراتژی، یک استراتژی Workbox را طوری پیکربندی کنید که مجموعه‌ای از کدهای وضعیت را واجد شرایط ذخیره‌سازی در حافظه پنهان در نظر بگیرید:

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) =>
    url.origin === 'https://third-party.example.com' &&
    url.pathname.startsWith('/images/'),
  new CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

این پیکربندی به Workbox می‌گوید که هنگام پردازش پاسخ‌های درخواست‌ها علیه https://third-party.example.com/images/ ، هر درخواستی را با کد وضعیت 0 یا 200 در حافظه پنهان ذخیره کنید.

ذخیره سازی بر اساس هدرها

می‌توانید یک استراتژی Workbox را برای بررسی وجود مقادیر هدر خاص به‌عنوان معیاری برای اضافه شدن به حافظه پنهان با تنظیم شی headers هنگام ساخت افزونه پیکربندی کنید:

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

هنگام پردازش پاسخ‌ها برای URLهای درخواست حاوی /path/to/api/ ، نگاهی به هدر با نام X-Is-Cacheable (که توسط سرور به پاسخ اضافه می‌شود) بیندازید. اگر آن هدر وجود داشته باشد، و اگر روی مقدار "true" تنظیم شده باشد، پاسخ را می توان در حافظه پنهان کرد.

اگر چندین هدر مشخص شده باشد، تنها یکی از سرصفحه ها باید با مقادیر مرتبط مطابقت داشته باشد.

ذخیره سازی بر اساس سرصفحه ها و کدهای وضعیت

می توانید وضعیت و پیکربندی هدر را با هم ترکیب کنید. هر دو شرط باید رعایت شود تا بتوان پاسخ را در حافظه پنهان در نظر گرفت. به عبارت دیگر، پاسخ باید یکی از کدهای وضعیت پیکربندی شده را داشته باشد و حداقل یکی از هدرهای ارائه شده را داشته باشد.

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [200, 404],
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

پیش فرض ها چیست؟

اگر از یکی از استراتژی‌های داخلی Workbox بدون پیکربندی صریح cacheableResponse.CacheableResponsePlugin استفاده می‌کنید، معیارهای پیش‌فرض زیر برای تعیین اینکه آیا پاسخ دریافت‌شده از شبکه باید ذخیره شود یا نه استفاده می‌شود:

• staleWhileRevalidate و networkFirst: پاسخ‌هایی با وضعیت 0 (یعنی پاسخ‌های غیر شفاف ) یا 200 قابل ذخیره‌سازی در نظر گرفته می‌شوند.
• cacheFirst: پاسخ هایی با وضعیت 200 قابل کش در نظر گرفته می شوند.

به طور پیش فرض، سرصفحه های پاسخ برای تعیین حافظه پنهان استفاده نمی شوند.

چرا پیش فرض های مختلف وجود دارد؟

پیش‌فرض‌ها در مورد اینکه آیا پاسخ‌هایی با وضعیت 0 (یعنی پاسخ‌های غیر شفاف ) در نهایت به حافظه پنهان ختم می‌شوند، متفاوت است. با توجه به ماهیت "جعبه سیاه" پاسخ‌های غیرشفاف، برای کارگر سرویس نمی‌تواند بداند که آیا پاسخ معتبر است یا اینکه آیا پاسخ خطای بازگشتی از سرور متقاطع را منعکس می‌کند.

برای استراتژی‌هایی که شامل برخی ابزارهای به‌روزرسانی پاسخ ذخیره‌شده هستند، مانند staleWhileRevalidate و networkFirst، خطر ذخیره‌سازی پاسخ خطای گذرا با این واقعیت کاهش می‌یابد که دفعه بعد که کش به‌روزرسانی می‌شود، امیدواریم از یک پاسخ مناسب و موفق استفاده شود.

برای استراتژی‌هایی که شامل ذخیره‌سازی اولین پاسخ دریافتی و استفاده مجدد از آن پاسخ ذخیره‌شده به‌طور نامحدود است، عواقب یک خطای گذرا در حافظه پنهان و استفاده مجدد شدیدتر است. برای اینکه به‌طور پیش‌فرض در قسمت امن اشتباه کند، cacheFirst از ذخیره پاسخ خودداری می‌کند مگر اینکه کد وضعیت 200 داشته باشد.

استفاده پیشرفته

اگر می خواهید از همان منطق کش کردن خارج از یک استراتژی Workbox استفاده کنید، می توانید مستقیماً از کلاس CacheableResponse استفاده کنید.

import {CacheableResponse} from 'workbox-cacheable-response';

const cacheable = new CacheableResponse({
  statuses: [0, 200],
  headers: {
    'X-Is-Cacheable': 'true',
  },
});

const response = await fetch('/path/to/api');

if (cacheable.isResponseCacheable(response)) {
  const cache = await caches.open('api-cache');
  cache.put(response.url, response);
} else {
  // Do something when the response can't be cached.
}