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

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

Workbox में, पहले से ही कई प्लग इन मौजूद होते हैं. अगर आपके पास क्रिएटिविटी है, तो अपने ऐप्लिकेशन की ज़रूरतों के हिसाब से कस्टम प्लग इन भी लिखे जा सकते हैं.

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

Workbox आपको सर्विस वर्कर में इस्तेमाल करने के लिए, ये आधिकारिक प्लगिन ऑफ़र करता है:

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

Workbox प्लग इन का इस्तेमाल, Workbox की रणनीति के साथ किया जाता है. इसके लिए, रणनीति की 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, जो कनेक्शन की मौजूदा स्पीड के आधार पर, Cloudinary पर होस्ट की गई इमेज के अनुरोधों को डाइनैमिक तौर पर फिर से लिखता है.
• workbox-plugin-firebase-auth, आउटगोइंग अनुरोधों के लिए Authorization: Bearer को मैनेज करने में मदद करता है. इसके लिए, Firebase से पुष्टि करना ज़रूरी होता है.

आप npm के रिपॉज़िटरी में खोज करके समुदाय के ज़रिए दिए गए ज़्यादा वर्कबॉक्स प्लग इन ढूंढ सकते हैं.

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