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

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

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

workbox-core

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

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

workbox-precaching

• किसी एचटीटीपी रीडायरेक्ट से जुड़े यूआरएल के लिए, क्रॉस-ऑरिजिन एचटीएमएल दस्तावेज़ों का इस्तेमाल अब workbox-precaching के साथ नेविगेशन का अनुरोध करने के लिए नहीं किया जा सकता. आम तौर पर, यह स्थिति असामान्य होती है.
• किसी अनुरोध के लिए पहले से कैश मेमोरी में सेव किए गए रिस्पॉन्स को खोजते समय, fbclid यूआरएल क्वेरी पैरामीटर को अब workbox-precaching अनदेखा कर देता है.
• 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 या इसके बाद का वर्शन ज़रूरी है

v10 से पहले के Node.js वर्शन अब 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 प्रॉपर्टी के पक्ष में "बाहरी" इवेंट हटाना

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

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

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

MULTI_LINE_CODE_PLACEHOLDER_0

वर्कबॉक्स-रूटिंग

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

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

MULTI_LINE_CODE_PLACEHOLDER_1

Workbox-expiration में matchOptions

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

workbox-precaching

वर्कबॉक्स-रणनीतियों का इस्तेमाल किया जाता है

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

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

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

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

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

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

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

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

MULTI_LINE_CODE_PLACEHOLDER_2

रनटाइम कैश मेमोरी में 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 पर शिकायत करें.