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

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

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

workbox-core

workbox-core में skipWaiting() मेथड, अब install हैंडलर में नहीं जोड़ा जाएगा. यह सिर्फ़ self.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 के v10 से पहले के वर्शन, अब 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 में मौजूद सभी "बाहरी" इवेंट हटा दिए गए हैं. इनकी जगह, "सामान्य" इवेंट जोड़ दिए गए हैं. इनमें isExternal प्रॉपर्टी को true पर सेट किया गया है. इससे उन डेवलपर को अब भी फ़र्क़ का पता चल पाता है जिन्हें इसकी ज़रूरत होती है. साथ ही, जिन डेवलपर को इसकी ज़रूरत नहीं होती वे इस प्रॉपर्टी को अनदेखा कर सकते हैं.

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

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

// 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

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

इससे कुछ सामान्य बॉयलरप्लेट को आसान बनाया जा सकता है:

// 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 पर समस्या की जानकारी देकर हमें बताएं.