वर्कबॉक्स-कैशेबल-रिस्पॉन्स

रनटाइम के दौरान एसेट को कैश मेमोरी में सेव करते समय, यह तय करने के लिए कोई तय नियम नहीं है कि कोई दिया गया रिस्पॉन्स "मान्य" है या नहीं. साथ ही, यह भी तय नहीं किया जा सकता कि उसे सेव किया जा सकता है या नहीं और उसका दोबारा इस्तेमाल किया जा सकता है या नहीं.

workbox-cacheable-response मॉड्यूल से पता लगाने का स्टैंडर्ड तरीका मिलता है क्या प्रतिक्रिया इस आधार पर कैश मेमोरी में सेव की जानी चाहिए कि संख्या वाला स्टेटस कोड, इसलिए, हेडर विशिष्ट मान या दोनों के संयोजन के साथ.

स्टेटस कोड के आधार पर कैश मेमोरी में सेव करना

Workbox की रणनीति को कॉन्फ़िगर करके, स्टेटस कोड के किसी सेट को कैश मेमोरी में सेव करने की ज़रूरी शर्तें पूरी करने वाला माना जा सकता है. इसके लिए, रणनीति के plugins पैरामीटर में CacheableResponsePlugin इंस्टेंस जोड़ें:

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 ऑब्जेक्ट सेट करके, कैश मेमोरी में जोड़े जाने की ज़रूरी शर्त के तौर पर, किसी खास हेडर वैल्यू की मौजूदगी की जांच करने के लिए, Workbox की रणनीति कॉन्फ़िगर की जा सकती है:

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',
        },
      }),
    ],
  })
);

/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 को कॉन्फ़िगर करने के लिए, ये डिफ़ॉल्ट शर्तें हैं इसका इस्तेमाल यह तय करने के लिए किया जाता है कि नेटवर्क से मिलने वाले जवाब को कैश मेमोरी में सेव किया जाएगा:

  • staleWhileReValidation और networkFirst: 0 की स्थिति वाले जवाब (उदाहरण के लिए, ओपेक रिस्पॉन्स) या 200 को कैश मेमोरी में सेव किया जा सकता है.
  • कैश मेमोरी में सेव होने वाली पहली जानकारी: ऐसे जवाब जिन्हें 200 स्थिति में सेव किया जाता है, उन्हें कैश मेमोरी में सेव किया जा सकने वाला माना जाता है.

डिफ़ॉल्ट रूप से, कैश मेमोरी में सेव किए जा सकने की सुविधा का पता लगाने के लिए, रिस्पॉन्स हेडर का इस्तेमाल नहीं किया जाता.

डिफ़ॉल्ट वैल्यू अलग-अलग क्यों होती हैं?

डिफ़ॉल्ट सेटिंग इस बात पर निर्भर करती है कि 0 (यानी अस्पष्ट जवाब) की स्थिति वाले जवाब कैश मेमोरी में सेव किए जाएंगे या नहीं. साफ़ तौर पर न दिखने वाले रिस्पॉन्स के "ब्लैक बॉक्स" होने की वजह से, सर्विस वर्कर्स यह नहीं जान पाते कि रिस्पॉन्स मान्य है या नहीं. इसके अलावा, यह भी नहीं पता चलता कि रिस्पॉन्स में, क्रॉस-ऑरिजिन सर्वर से मिली गड़बड़ी की जानकारी है या नहीं.

ऐसी रणनीतियों के लिए जिनमें कैश मेमोरी में सेव किए गए जवाबों को अपडेट करने के कुछ तरीके शामिल हों, जैसे, staleWhileReValidation और 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 जिन्हें कैश मेमोरी में सेव किया जा सकता है.

प्रॉपर्टी

  • कंस्ट्रक्टर

    अमान्य

    CacheableResponse का नया इंस्टेंस बनाने के लिए, आपको कम से कम एक config प्रॉपर्टी देनी होगी.

    अगर statuses और headers, दोनों की जानकारी दी गई है, तो Response को कैश मेमोरी में सेव किया जा सकता है. इसके लिए, दोनों शर्तें पूरी होनी चाहिए.

    constructor फ़ंक्शन इस तरह दिखता है: 

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

  • isResponseCacheable

    अमान्य

    इस ऑब्जेक्ट के कॉन्फ़िगरेशन के आधार पर, यह जांच करता है कि किसी रिस्पॉन्स को कैश मेमोरी में सेव किया जा सकता है या नहीं.

    isResponseCacheable फ़ंक्शन इस तरह दिखता है: 

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

    • जवाब

      जवाब

      वह रिस्पॉन्स जिसकी कैश मेमोरी की क्षमता हो रही है चुना गया.

    • returns

      बूलियन

      true अगर Response को कैश मेमोरी में सेव किया जा सकता है, तो false अन्यथा.

CacheableResponseOptions

प्रॉपर्टी

  • हेडर

    ऑब्जेक्ट ज़रूरी नहीं है

  • स्थितियां

    number[] ज़रूरी नहीं

CacheableResponsePlugin

cacheWillUpdate लाइफ़साइकल कॉलबैक लागू करने वाली क्लास. इससे, Workbox की पहले से मौजूद रणनीतियों के ज़रिए किए गए अनुरोधों में, कैश मेमोरी में सेव किए जा सकने की जांच को आसानी से जोड़ा जा सकता है.

प्रॉपर्टी

  • कंस्ट्रक्टर

    अमान्य

    नया कैशेबल रिस्पॉन्स प्लगिन बनाने के लिए, आपको यहां उपलब्ध कराना होगा config प्रॉपर्टी में से कम से कम एक.

    अगर statuses और headers, दोनों की जानकारी दी गई है, तो Response को कैश मेमोरी में सेव किया जा सकता है. इसके लिए, दोनों शर्तें पूरी होनी चाहिए.

    constructor फ़ंक्शन इस तरह दिखता है: 

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