प्लग इन का इस्तेमाल करना

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

Workbox में ऐसे कई प्लगिन उपलब्ध हैं जो हमारे लिए उपलब्ध हैं और—अगर आप कलात्मक क्रम में हैं—तो आप अपने ऐप्लिकेशन की ज़रूरतों के मुताबिक कस्टम प्लग इन लिख सकते हैं.

उपलब्ध Workbox प्लग इन

Workbox में आपके सर्विस वर्कर में इस्तेमाल करने के लिए, नीचे दिए गए आधिकारिक प्लग इन दिए गए हैं:

• BackgroundSyncPlugin: अगर नेटवर्क से जुड़ा कोई अनुरोध पूरा नहीं होता है, तो यह प्लगिन आपको इसे बैकग्राउंड सिंक सूची में जोड़ने की अनुमति देता है. इससे अगला सिंक इवेंट ट्रिगर होने पर, फिर से अनुरोध किया जा सकता है.
• BroadcastUpdatePlugin: जब भी कैश मेमोरी अपडेट हो, तब ब्रॉडकास्ट चैनल पर या postMessage() से मैसेज भेजने की सुविधा मिलती है.
• CacheableResponsePlugin: सिर्फ़ कैश मेमोरी के उन अनुरोधों को कैश मेमोरी में सेव करें जो खास शर्तों को पूरा करते हों.
• ExpirationPlugin: यह नीति, कैश मेमोरी में मौजूद आइटम की संख्या और उनकी ज़्यादा से ज़्यादा उम्र को मैनेज करती है.
• RangeRequestsPlugin: Range एचटीटीपी अनुरोध के हेडर वाले अनुरोधों के जवाब दें.

वर्कबॉक्स प्लग इन—चाहे वे ऊपर दी गई सूची में मौजूद कोई प्लगिन हों या कोई कस्टम प्लगिन हों, उन्हें रणनीति की plugins प्रॉपर्टी में प्लगिन के इंस्टेंस को जोड़कर, वर्कबॉक्स रणनीति के साथ इस्तेमाल किया जाता है:

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {ExpirationPlugin} from 'workbox-expiration';

registerRoute(
  ({request}) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'images',
    plugins: [
      new ExpirationPlugin({
        maxEntries: 60,
        maxAgeSeconds: 30 * 24 * 60 * 60, // 30 Days
      }),
    ],
  })
);

कस्टम प्लग इन के लिए तरीके

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

• cacheWillUpdate: कैश मेमोरी को अपडेट करने के लिए, Response का इस्तेमाल करने से पहले कॉल किया जाता है. इस तरीके में, कैश में जोड़े जाने से पहले रिस्पॉन्स को बदला जा सकता है. इसके अलावा, कैश मेमोरी को पूरी तरह अपडेट करने से बचने के लिए, null वापस किया जा सकता है.
• cacheDidUpdate: यह तब कॉल किया जाता है, जब कैश मेमोरी में कोई नई एंट्री जोड़ी जाती है या मौजूदा एंट्री को अपडेट किया जाता है. इस तरीके का इस्तेमाल करने वाले प्लगिन से, कैश मेमोरी अपडेट होने के बाद कोई कार्रवाई करने में मदद मिल सकती है.
• cacheKeyWillBeUsed: इसे कैश कुंजी के तौर पर इस्तेमाल करने से पहले कॉल किया जाता है. यह कैश लुकअप (जब mode 'read' है) और कैश मेमोरी (जब mode 'write' हो) दोनों के लिए होता है. अगर आपको कैश ऐक्सेस करने के लिए यूआरएल का इस्तेमाल करने से पहले उन्हें बदलना या सामान्य बनाना है, तो यह कॉलबैक काम का है.
• cachedResponseWillBeUsed: इसे कैश मेमोरी से मिले रिस्पॉन्स के इस्तेमाल से ठीक पहले कॉल किया जाता है. इससे आपको उस जवाब की जांच करने में मदद मिलती है. इस समय, आप या तो अलग जवाब दे सकते हैं या null लौटा सकते हैं.
• requestWillFetch: जब भी कोई अनुरोध नेटवर्क पर जाने वाला हो, तब कॉल किया जाता है. यह तब काम आता है, जब आपको Request के नेटवर्क में आने से ठीक पहले उसे बदलने की ज़रूरत हो.
• fetchDidFail: इसे तब कॉल किया जाता है जब कोई नेटवर्क अनुरोध फ़ेल हो जाता है, ऐसा नेटवर्क कनेक्टिविटी के न होने की वजह से होता है. साथ ही, यह तब फ़ायर नहीं होगा जब ब्राउज़र में नेटवर्क कनेक्शन होगा, लेकिन उसे कोई गड़बड़ी मिलेगी (उदाहरण के लिए, 404 Not Found).
• fetchDidSucceed: नेटवर्क अनुरोध पूरा होने पर इसे कॉल किया जाता है, चाहे एचटीटीपी रिस्पॉन्स कोड कुछ भी हो.
• handlerWillStart: इसे किसी हैंडलर लॉजिक के चलने से पहले कॉल किया जाता है. यह तब काम आता है, जब आपको हैंडलर की शुरुआती स्थिति सेट करनी हो. उदाहरण के लिए, अगर आपको यह जानना है कि हैंडलर को कोई जवाब जनरेट करने में कितना समय लगा, तो इस कॉलबैक में, शुरू होने के समय को नोट किया जा सकता है.
• handlerWillRespond: रणनीति के handle() तरीके से पहले कॉल करने पर, जवाब मिलता है. अगर किसी जवाब को RouteHandler या दूसरे कस्टम लॉजिक पर लौटने से पहले उसमें बदलाव करना है, तो इससे मदद मिलती है.
• handlerDidRespond: रणनीति के handle() तरीके से जवाब देने के बाद, इसे कॉल किया जाता है. ऐसी स्थिति में किसी भी आखिरी जवाब की जानकारी को रिकॉर्ड करना मददगार हो सकता है (उदाहरण के लिए, दूसरे प्लग इन से किए गए बदलावों के बाद).
• handlerDidComplete: इसे तब कॉल किया जाता है, जब रणनीति शुरू करने के बाद, इवेंट में हमेशा के लिए किए गए वादों की अवधि बढ़ा दी जाती है. अगर आपको किसी ऐसे डेटा की रिपोर्ट करनी है जिसे कैश हिट की स्थिति, कैश के इंतज़ार का समय, नेटवर्क के इंतज़ार का समय, और दूसरी काम की जानकारी का हिसाब लगाने के लिए हैंडलर के पूरा होने तक इंतज़ार करना है, तो यह रिपोर्ट उपयोगी होती है.
• handlerDidError: यह तब कॉल किया जाता है, जब हैंडलर किसी सोर्स से सही जवाब नहीं दे पाता. यह समय, फ़ॉलबैक रिस्पॉन्स देने का सबसे सही समय होता है. बाद में पूरा जवाब न दिया जा सके.

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

अगर किसी प्लगिन ने ऊपर दिए गए सभी कॉलबैक का इस्तेमाल किया है, तो यह मिलने वाला कोड होगा:

const myPlugin = {
  cacheWillUpdate: async ({request, response, event, state}) => {
    // Return `response`, a different `Response` object, or `null`.
    return response;
  },
  cacheDidUpdate: async ({
    cacheName,
    request,
    oldResponse,
    newResponse,
    event,
    state,
  }) => {
    // No return expected
    // Note: `newResponse.bodyUsed` is `true` when this is called,
    // meaning the body has already been read. If you need access to
    // the body of the fresh response, use a technique like:
    // const freshResponse = await caches.match(request, {cacheName});
  },
  cacheKeyWillBeUsed: async ({request, mode, params, event, state}) => {
    // `request` is the `Request` object that would otherwise be used as the cache key.
    // `mode` is either 'read' or 'write'.
    // Return either a string, or a `Request` whose `url` property will be used as the cache key.
    // Returning the original `request` will make this a no-op.
    return request;
  },
  cachedResponseWillBeUsed: async ({
    cacheName,
    request,
    matchOptions,
    cachedResponse,
    event,
    state,
  }) => {
    // Return `cachedResponse`, a different `Response` object, or null.
    return cachedResponse;
  },
  requestWillFetch: async ({request, event, state}) => {
    // Return `request` or a different `Request` object.
    return request;
  },
  fetchDidFail: async ({originalRequest, request, error, event, state}) => {
    // No return expected.
    // Note: `originalRequest` is the browser's request, `request` is the
    // request after being passed through plugins with
    // `requestWillFetch` callbacks, and `error` is the exception that caused
    // the underlying `fetch()` to fail.
  },
  fetchDidSucceed: async ({request, response, event, state}) => {
    // Return `response` to use the network response as-is,
    // or alternatively create and return a new `Response` object.
    return response;
  },
  handlerWillStart: async ({request, event, state}) => {
    // No return expected.
    // Can set initial handler state here.
  },
  handlerWillRespond: async ({request, response, event, state}) => {
    // Return `response` or a different `Response` object.
    return response;
  },
  handlerDidRespond: async ({request, response, event, state}) => {
    // No return expected.
    // Can record final response details here.
  },
  handlerDidComplete: async ({request, response, error, event, state}) => {
    // No return expected.
    // Can report any data here.
  },
  handlerDidError: async ({request, event, error, state}) => {
    // Return a `Response` to use as a fallback, or `null`.
    return fallbackResponse;
  },
};

ऊपर दिए गए कॉलबैक में उपलब्ध event ऑब्जेक्ट, वह ओरिजनल इवेंट है जिसने फ़ेच या कैश मेमोरी की कार्रवाई को ट्रिगर किया था. कभी-कभी, कोई ओरिजनल इवेंट नहीं होता. इसलिए, रेफ़रंस देने से पहले, अपने कोड की जांच करें और देखें कि वह मौजूद है या नहीं.

सभी प्लगिन कॉलबैक को एक state ऑब्जेक्ट भी पास किया जाता है, जो किसी खास प्लगिन के लिए यूनीक होता है और उसके ज़रिए शुरू की गई रणनीति के लिए होता है. इसका मतलब है कि ऐसे प्लगिन लिखे जा सकते हैं जिनमें एक कॉलबैक, उसी प्लगिन के दूसरे कॉलबैक की कार्रवाई के आधार पर, कुछ शर्तों के साथ टास्क पूरा कर सकता है. उदाहरण के लिए, requestWillFetch() और fetchDidSucceed() या fetchDidFail() चलाने के बीच के अंतर का हिसाब लगाएं.

तीसरे पक्ष के प्लग इन

अगर कोई प्लगिन डेवलप किया जाता है और आपको लगता है कि उसका इस्तेमाल आपके प्रोजेक्ट से बाहर किया जा रहा है, तो हमारा सुझाव है कि आप उसे एक मॉड्यूल के तौर पर पब्लिश करें! समुदाय की ओर से उपलब्ध कराए गए Workbox प्लग इन की एक छोटी सूची नीचे दी गई है:

• cloudinary-workbox-plugin, जो मौजूदा कनेक्शन स्पीड के आधार पर क्लाउडिनरी से होस्ट की गई इमेज के लिए, डाइनैमिक तरीके से फिर से लिख जाता है.
• workbox-plugin-firebase-auth, उन आउटगोइंग अनुरोधों के लिए Authorization: Bearer को मैनेज करने में मदद करता है जिनके लिए Firebase से पुष्टि करने की ज़रूरत होती है.

आपको npm के डेटा स्टोर करने की जगह में खोज करके, समुदाय से मिले और Workbox के ज़्यादा प्लगिन ढूंढने का विकल्प मिल सकता है.

आखिर में, अगर आपने ऐसा Workbox प्लगिन बनाया है जिसे आपको शेयर करना है, तो पब्लिश करते समय workbox-plugin कीवर्ड जोड़ें. अगर हां, तो हमें Twitter @WorkboxJS पर बताएं!