workbox-cacheable-response

כששומרים נכסים במטמון בזמן הריצה, אין כלל אחד שמתאים לכל המקרים לקביעת אם תגובה מסוימת 'תקפה' ועומדת בדרישות לשמירה ולשימוש חוזר.

המודול workbox-cacheable-response מספק דרך סטנדרטית לקבוע האם יש לשמור תגובה במטמון על סמך קוד סטטוס מספרי, את הנוכחות כותרת עם ערך ספציפי או שילוב של שניהם.

אחסון במטמון על סמך קודי סטטוס

אפשר להגדיר אסטרטגיית Workbox כך שתתייחס לקבוצה של קודי סטטוס ככזו שאפשר לשמור במטמון. לשם כך, מוסיפים מופע CacheableResponsePlugin לפרמטר plugins של האסטרטגיה:

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.

שמירה במטמון על סמך כותרות

אפשר להגדיר אסטרטגיה של תיבת עבודה כדי לגבי הנוכחות של ערכי כותרת ספציפיים כקריטריונים להוספה למטמון על ידי הגדרת האובייקט 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 באופן מפורש, המערכת משתמשת בקריטריונים הבאים של ברירת המחדל כדי לקבוע אם כדאי לשמור בתגובה שהתקבלה מהרשת במטמון:

  • souteAtreאטים ו-NetworkFirst: תשובות בסטטוס 0 (למשל, תשובות אטומות) או 200 נחשבים שניתן לשמור במטמון.
  • cacheFirst: תשובות עם סטטוס 200 נחשבות כמתאימות לשמירה במטמון.

כברירת מחדל, כותרות תגובה לא משמשות לקביעת יכולת השמירה במטמון.

למה יש הגדרות ברירת מחדל שונות?

ברירת המחדל משתנה בהתאם לשאלה אם תשובות עם סטטוס 0 (כלומר תשובות חסרות שקיפות) יישמרו במטמון. בגלל אופי ה'קופסה השחורה' של תשובות אטומות, ל-service worker אין אפשרות לדעת אם התשובה תקינה או אם היא משקפת תגובת שגיאה שחוזרת מהשרת שמחוץ למקור.

באסטרטגיות שכוללות אמצעים מסוימים לעדכון התגובה שנשמרה במטמון: כמו stellwhileReאטים ו-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.
}

סוגים

CacheableResponse

בכיתה הזו תוכלו להגדיר כללים שקובעים קודי סטטוס ו/או כותרות חייבים להיות קיימים Response להיחשב כניתן לשמירה במטמון.

מאפיינים

  • constructor

    ריק

    כדי ליצור מופע חדש של CacheableResponse, צריך לספק לפחות אחד מהמאפיינים config.

    אם מציינים גם statuses וגם headers, חייבים לציין את שני התנאים עומד בדרישות כדי ש-Response ייחשב כניתן לשמירה במטמון.

    הפונקציה constructor נראית כך: 

    (config?: CacheableResponseOptions) => {...}

  • isResponseCacheable

    ריק

    בדיקה של תגובה כדי לראות אם אפשר לשמור אותה במטמון או לא, על סמך ההגדרה של האובייקט הזה.

    הפונקציה isResponseCacheable נראית כך: 

    (response: Response) => {...}

    • תשובה

      תשובה

      התשובה שאפשר לשמור במטמון סומנה.

    • החזרות

      בוליאני

      true אם אפשר לשמור את Response במטמון, ו-false במקרים אחרים.

CacheableResponseOptions

מאפיינים

  • כותרות

    אובייקט אופציונלי

  • סטטוסים

    מספר[] אופציונלי

CacheableResponsePlugin

מחלקה שמממשת את הקריאה החוזרת (callback) של מחזור החיים cacheWillUpdate. ככה קל יותר להוסיף בדיקות של יכולת המטמון לבקשות שנשלחו דרך האפליקציה המובנית של Workbox אסטרטגיות למשימות.

מאפיינים

  • constructor

    ריק

    כדי ליצור מופע חדש של CacheableResponsePlugin, צריך לספק לפחות אחד מהמאפיינים config.

    אם מציינים גם statuses וגם headers, חייבים לציין את שני התנאים כדי ש-Response ייחשב כניתן לשמירה במטמון.

    הפונקציה constructor נראית כך: 

    (config: CacheableResponseOptions) => {...}