Workbox v5 से v6 पर माइग्रेट करें

इस गाइड में, Workbox v6 में किए गए बदलावों के बारे में बताया गया है. साथ ही, यह भी बताया गया है कि Workbox v5 से अपग्रेड करते समय आपको किन बदलावों की ज़रूरत पड़ेगी.

नुकसान पहुंचा सकने वाले बदलाव

workbox-core

workbox-core में मौजूद skipWaiting() तरीका, अब install हैंडलर नहीं जोड़ेगा. यह सिर्फ़ self.skipWaiting() को कॉल करने के बराबर है.

अब से, skipWaiting() के बजाय self.skipWaiting() का इस्तेमाल करें. ऐसा इसलिए, क्योंकि Workbox v7 में skipWaiting() को हटा दिया जाएगा.

workbox-precaching

• एचटीटीपी रीडायरेक्ट से जुड़े यूआरएल के लिए, क्रॉस-ऑरिजिन एचटीएमएल दस्तावेज़ों का इस्तेमाल अब workbox-precaching के साथ नेविगेशन अनुरोध को पूरा करने के लिए नहीं किया जा सकता. आम तौर पर, ऐसा नहीं होता.
• किसी अनुरोध के लिए, पहले से कैश मेमोरी में सेव किए गए जवाब को खोजते समय, workbox-precaching अब fbclid यूआरएल क्वेरी पैरामीटर को अनदेखा कर देता है.
• PrecacheController कन्स्ट्रक्टर अब स्ट्रिंग के बजाय, खास प्रॉपर्टी वाले ऑब्जेक्ट को पैरामीटर के तौर पर लेता है. यह ऑब्जेक्ट इन प्रॉपर्टी के साथ काम करता है: cacheName (v5 में कन्स्ट्रक्टर में पास की गई स्ट्रिंग के जैसे ही काम करता है), plugins (v5 में addPlugins() तरीके की जगह लेता है), और fallbackToNetwork (v5 में createHandler() और `createHandlerBoundToURL() को पास किए गए मिलते-जुलते विकल्प की जगह लेता है).
• PrecacheController के install() और activate() तरीके अब सिर्फ़ एक पैरामीटर लेते हैं. इसे क्रमशः InstallEvent या ActivateEvent पर सेट किया जाना चाहिए.
• addRoute() को PrecacheController से हटा दिया गया है. इसके बजाय, नई PrecacheRoute क्लास का इस्तेमाल करके कोई ऐसा रूट बनाया जा सकता है जिसे रजिस्टर किया जा सके.
• precacheAndRoute() को PrecacheController से हटा दिया गया है. (यह अब भी workbox-precaching मॉड्यूल से एक्सपोर्ट किए गए स्टैटिक हेल्पर तरीके के तौर पर मौजूद है.) इसे हटा दिया गया है, क्योंकि इसके बजाय PrecacheRoute का इस्तेमाल किया जा सकता है.
• createMatchCalback() को PrecacheController से हटा दिया गया है. इसके बजाय, नए PrecacheRoute का इस्तेमाल किया जा सकता है.
• createHandler() को PrecacheController से हटा दिया गया है. अनुरोधों को मैनेज करने के लिए, PrecacheController ऑब्जेक्ट की strategy प्रॉपर्टी का इस्तेमाल किया जा सकता है.
• createHandler() स्टैटिक एक्सपोर्ट को workbox-precaching मॉड्यूल से पहले ही हटा दिया गया है. इसके बजाय, डेवलपर को PrecacheController इंस्टेंस बनाना चाहिए और उसकी strategy प्रॉपर्टी का इस्तेमाल करना चाहिए.
• precacheAndRoute() के साथ रजिस्टर किया गया रूट, अब एक "असल" रूट है. यह रूट, workbox-routing की Router क्लास का इस्तेमाल करता है. अगर registerRoute() और precacheAndRoute() के लिए कॉल को इंटरलीव किया जाता है, तो इससे आपके रूट का आकलन करने का क्रम अलग हो सकता है.

workbox-routing

setDefaultHandler() तरीका अब उस एचटीटीपी तरीके से जुड़ा दूसरा पैरामीटर लेता है जिस पर यह लागू होता है. यह पैरामीटर, डिफ़ॉल्ट रूप से 'GET' पर सेट होता है.

• अगर setDefaultHandler() का इस्तेमाल किया जा रहा है और आपके सभी अनुरोध GET हैं, तो आपको कुछ भी बदलने की ज़रूरत नहीं है.
• अगर आपके पास ऐसे अनुरोध हैं जो GET (POST, PUT वगैरह) नहीं हैं, तो setDefaultHandler() की वजह से, अब उन अनुरोधों का मिलान नहीं होगा.

बिल्ड कॉन्फ़िगरेशन

workbox-build और workbox-cli में getManifest और injectManifest मोड के लिए mode विकल्प का इस्तेमाल नहीं किया जा सकता था. इसलिए, इसे हटा दिया गया है. यह workbox-webpack-plugin पर लागू नहीं होता, जो अपने InjectManifest प्लग इन में mode के साथ काम करता है.

बिल्ड टूल के लिए Node.js v10 या इसके बाद का वर्शन ज़रूरी है

Node.js के 10 से पहले के वर्शन, अब workbox-webpack-plugin, workbox-build या workbox-cli के साथ काम नहीं करते. अगर आपके पास Node.js का v8 से पहले का वर्शन है, तो अपने रनटाइम को काम करने वाले वर्शन पर अपडेट करें.

नए सुधार

workbox-strategies

Workbox v6 में, तीसरे पक्ष के डेवलपर के लिए अपनी Workbox रणनीतियों को तय करने का एक नया तरीका जोड़ा गया है. इससे यह पक्का होता है कि तीसरे पक्ष के डेवलपर, अपनी ज़रूरतों के हिसाब से Workbox को बेहतर बना सकते हैं.

नई रणनीति की बुनियादी क्लास

v6 में, Workbox की सभी रणनीति क्लास को नई Strategy बेस क्लास को एक्सटेंड करना होगा. इस सुविधा के साथ काम करने के लिए, पहले से मौजूद सभी रणनीतियों को फिर से लिखा गया है.

Strategy बेस क्लास दो मुख्य चीज़ों के लिए ज़िम्मेदार है:

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

नई "हैंडलर" क्लास

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

नई "हैंडलर" क्लास, StrategyHandler, इन तरीकों को एक्सपोज़ करेगी, ताकि कस्टम रणनीतियां fetch() या cacheMatch() को कॉल कर सकें. साथ ही, रणनीति के इंस्टेंस में जोड़े गए किसी भी प्लग इन को अपने-आप चालू किया जा सके.

इस क्लास की मदद से, डेवलपर अपनी रणनीतियों के हिसाब से लाइफ़साइकल कॉलबैक जोड़ सकते हैं. ये कॉलबैक, प्लग इन के मौजूदा इंटरफ़ेस के साथ "काम" करेंगे.

प्लगिन के लाइफ़साइकल की नई स्थिति

Workbox v5 में, प्लग इन स्टेटलेस होते हैं. इसका मतलब है कि अगर /index.html के लिए किया गया अनुरोध, requestWillFetch और cachedResponseWillBeUsed, दोनों कॉलबैक को ट्रिगर करता है, तो उन दोनों कॉलबैक के पास एक-दूसरे से संपर्क करने का कोई तरीका नहीं होता. इसके अलावा, उन्हें यह भी नहीं पता होता कि उन्हें एक ही अनुरोध से ट्रिगर किया गया था.

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

प्लगिन के लाइफ़साइकल के नए कॉलबैक

प्लग इन के लाइफ़साइकल के नए कॉलबैक जोड़े गए हैं, ताकि डेवलपर प्लग इन के लाइफ़साइकल स्टेटस का ज़्यादा से ज़्यादा फ़ायदा ले सकें:

• handlerWillStart: किसी भी हैंडलर लॉजिक के चलने से पहले कॉल किया जाता है. इस कॉलबैक का इस्तेमाल, शुरुआती हैंडलर स्टेटस सेट करने के लिए किया जा सकता है. उदाहरण के लिए, शुरू होने का समय रिकॉर्ड करना.
• handlerWillRespond: रणनीतियां handle() का तरीका जवाब देने से पहले कॉल किया जाता है. इस कॉलबैक का इस्तेमाल, उस रिस्पॉन्स को रूट हैंडलर या अन्य कस्टम लॉजिक में भेजने से पहले, उसमें बदलाव करने के लिए किया जा सकता है.
• handlerDidRespond: रणनीति के handle() तरीके से कोई जवाब मिलने के बाद कॉल किया जाता है. इस कॉलबैक का इस्तेमाल, किसी भी फ़ाइनल रिस्पॉन्स की जानकारी रिकॉर्ड करने के लिए किया जा सकता है. उदाहरण के लिए, अन्य प्लग इन से किए गए बदलावों के बाद.
• handlerDidComplete: इस रणनीति के लागू होने के बाद, इवेंट में जोड़े गए सभी लाइफ़टाइम के लिए सदस्यता देने के वादे सेटल होने के बाद कॉल किया जाता है. इस कॉलबैक का इस्तेमाल, ऐसे किसी भी डेटा की रिपोर्ट करने के लिए किया जा सकता है जिसे कैलकुलेट करने के लिए, हैंडलर के पूरा होने तक इंतज़ार करना पड़ता है. जैसे, कैश मेमोरी में हिट का स्टेटस, कैश मेमोरी में डेटा लोड होने में लगने वाला समय, नेटवर्क में डेटा लोड होने में लगने वाला समय.
• handlerDidError: अगर हैंडलर किसी भी सोर्स से मान्य रिस्पॉन्स नहीं दे पाता है, तो इसे कॉल किया जाता है. इस कॉलबैक का इस्तेमाल, नेटवर्क की गड़बड़ी के विकल्प के तौर पर "फ़ॉलबैक" कॉन्टेंट देने के लिए किया जा सकता है.

अपनी कस्टम रणनीतियां लागू करने वाले डेवलपर को, इन कॉलबैक को खुद ट्रिगर करने की ज़रूरत नहीं है. यह काम, नई Strategy बेस क्लास करती है.

हैंडलर के लिए ज़्यादा सटीक TypeScript टाइप

अलग-अलग कॉलबैक तरीकों के लिए, TypeScript की परिभाषाओं को सामान्य किया गया है. इससे, TypeScript का इस्तेमाल करने वाले डेवलपर को बेहतर अनुभव मिलेगा. साथ ही, हैंडलर को लागू करने या कॉल करने के लिए, वे अपना कोड लिख पाएंगे.

workbox-window

messageSkipWaiting() का नया तरीका

workbox-window मॉड्यूल में एक नया तरीका, messageSkipWaiting() जोड़ा गया है. इससे, "इंतज़ार कर रहे" सेवा वर्कर को चालू करने की प्रोसेस को आसान बनाया जा सकता है. इससे कुछ सुधार मिलते हैं:

• यह postMessage() को डिफ़ॉल्ट स्टैंडर्ड मैसेज बॉडी, {type: 'SKIP_WAITING'} के साथ कॉल करता है. Workbox से जनरेट किया गया सेवा वर्कर, skipWaiting() को ट्रिगर करने के लिए इसकी जांच करता है.
• यह इस मैसेज को पोस्ट करने के लिए, सही "वेटिंग" सर्विस वर्कर चुनता है. भले ही, यह वही सर्विस वर्कर न हो जिसके साथ workbox-window को रजिस्टर किया गया था.

isExternal प्रॉपर्टी के पक्ष में "बाहरी" इवेंट हटाना

workbox-window में मौजूद सभी "बाहरी" इवेंट हटा दिए गए हैं. इनकी जगह, true पर सेट की गई isExternal प्रॉपर्टी वाले "सामान्य" इवेंट जोड़े गए हैं. इससे, डेवलपर को इस अंतर का पता चलता रहेगा. साथ ही, जिन डेवलपर को इसकी जानकारी नहीं चाहिए वे इस प्रॉपर्टी को अनदेखा कर सकते हैं.

"उपयोगकर्ताओं को पेज को फिर से लोड करने का विकल्प दें" से जुड़ी बेहतरीन रेसिपी

ऊपर बताए गए दोनों बदलावों की मदद से, "उपयोगकर्ताओं के लिए पेज रीलोड करने का विकल्प ऑफ़र करें" रेसिपी को आसान बनाया जा सकता है:

// v6:
<script type="module">
  import {Workbox} from 'https://storage.googleapis.com/workbox-cdn/releases/6.0.0-alpha.1/workbox-window.prod.mjs';

  if ('serviceWorker' in navigator) {
    const wb = new Workbox('/sw.js');

    const showSkipWaitingPrompt = () => {
      // This assumes a hypothetical createUIPrompt() method with
      // onAccept and onReject callbacks:
      const prompt = createUIPrompt({
        onAccept: () => {
          wb.addEventListener('controlling', () => {
            window.location.reload();
          });

          // This will postMessage() to the waiting service worker.
          wb.messageSkipWaiting();
        },

        onReject: () => {
          prompt.dismiss();
        },
      });
    };

    // Listening for externalwaiting is no longer needed.
    wb.addEventListener('waiting', showSkipWaitingPrompt);
    wb.register();
  }
</script>

workbox-routing

sameOrigin नाम का नया बूलियन पैरामीटर, workbox-routing में इस्तेमाल किए गए matchCallback फ़ंक्शन को पास किया जाता है. अगर अनुरोध, एक ही ऑरिजिन वाले यूआरएल के लिए है, तो इसे true पर सेट किया जाता है. अगर ऐसा नहीं है, तो इसे 'गलत' पर सेट किया जाता है.

इससे, कुछ सामान्य बूलिपलेट को आसानी से बनाया जा सकता है:

// In v5:
registerRoute(
  ({url}) =>
    url.origin === self.location.origin && url.pathname.endsWith('.png'),
  new StaleWhileRevalidate({cacheName: 'local-png'})
);

// In v6:
registerRoute(
  ({sameOrigin, url}) => sameOrigin && url.pathname.endsWith('.png'),
  new StaleWhileRevalidate({cacheName: 'local-png'})
);

workbox-expiration में matchOptions

अब workbox-expiration में matchOptions सेट किया जा सकता है. इसके बाद, इसे cache.delete() कॉल में CacheQueryOptions के तौर पर पास किया जाएगा. (ज़्यादातर डेवलपर को ऐसा करने की ज़रूरत नहीं होगी.)

workbox-precaching

workbox-strategies का इस्तेमाल करता है

workbox-precaching को फिर से लिखा गया है, ताकि workbox-strategies का इस्तेमाल बेस के तौर पर किया जा सके. इससे कोई बड़ा बदलाव नहीं होगा. साथ ही, दोनों मॉड्यूल के नेटवर्क और कैश मेमोरी को ऐक्सेस करने के तरीके में, लंबे समय तक बेहतर तरीके से काम करने की सुविधा मिलेगी.

प्रीकैश मेमोरी में डेटा सेव करने की सुविधा, अब एक-एक करके एंट्री को प्रोसेस करती है, न कि एक साथ कई एंट्री को

workbox-precaching को अपडेट किया गया है, ताकि प्रीकैश मेनिफ़ेस्ट में मौजूद सभी एंट्री का एक साथ अनुरोध और कैश मेमोरी में सेव करने के बजाय, एक बार में सिर्फ़ एक एंट्री का अनुरोध और कैश मेमोरी में सेव किया जा सके. ब्राउज़र यह तय करेगा कि ट्रैफ़िक को कम करने का तरीका क्या होगा.

इससे, कॉन्टेंट को पहले से कैश मेमोरी में सेव करने के दौरान net::ERR_INSUFFICIENT_RESOURCES गड़बड़ियों की संभावना कम हो जाएगी. साथ ही, वेब ऐप्लिकेशन के एक साथ किए गए अनुरोधों और कॉन्टेंट को पहले से कैश मेमोरी में सेव करने के बीच बैंडविड्थ की समस्या भी कम हो जाएगी.

PrecacheFallbackPlugin की मदद से, ऑफ़लाइन फ़ॉलबैक को आसानी से सेट किया जा सकता है

workbox-precaching में अब एक PrecacheFallbackPlugin शामिल है, जो v6 में जोड़े गए नए handlerDidError लाइफ़साइकल तरीके को लागू करता है.

इससे, किसी रणनीति के लिए पहले से कैश मेमोरी में सेव किए गए यूआरएल को "फ़ॉलबैक" के तौर पर आसानी से सेट किया जा सकता है. ऐसा तब किया जाता है, जब कोई रिस्पॉन्स उपलब्ध न हो. प्लग इन, पहले से कैश मेमोरी में सेव किए गए यूआरएल के लिए सही कैश मेमोरी कुंजी को सही तरीके से बनाएगा. इसमें, ज़रूरी बदलाव करने वाला पैरामीटर भी शामिल होगा.

यहां इसका इस्तेमाल करने का एक सैंपल दिया गया है. इसमें, पहले से कैश मेमोरी में सेव किए गए /offline.html के साथ जवाब देने का तरीका बताया गया है. ऐसा तब किया जाता है, जब NetworkOnly रणनीति किसी नेविगेशन अनुरोध के लिए जवाब जनरेट नहीं कर पाती. दूसरे शब्दों में, कस्टम ऑफ़लाइन एचटीएमएल पेज दिखाना:

import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);

registerRoute(
  ({request}) => request.mode === 'navigate',
  new NetworkOnly({
    plugins: [
      new PrecacheFallbackPlugin({
        fallbackURL: '/offline.html',
      }),
    ],
  })
);

रनटाइम कैश मेमोरी में precacheFallback

अगर आपने खुद से सेवा वर्कर लिखने के बजाय, generateSW का इस्तेमाल करके सेवा वर्कर बनाया है, तो runtimeCaching में नए precacheFallback कॉन्फ़िगरेशन विकल्प का इस्तेमाल करके भी यही काम किया जा सकता है:

{
  // ... other generateSW config options...
  runtimeCaching: [{
    urlPattern: ({request}) => request.mode === 'navigate',
    handler: 'NetworkOnly',
    options: {
      precacheFallback: {
        // This URL needs to be included in your precache manifest.
        fallbackURL: '/offline.html',
      },
    },
  }],
}

मदद लेना

हमें उम्मीद है कि ज़्यादातर माइग्रेशन आसानी से हो जाएंगे. अगर आपको ऐसी समस्याएं आती हैं जिनके बारे में इस गाइड में नहीं बताया गया है, तो कृपया GitHub पर शिकायत करें.