इस गाइड में, वर्कबॉक्स v6 में किए गए बदलावों को तोड़ने के बारे में बताया गया है. इसमें, वर्कबॉक्स v5 से अपग्रेड करने के दौरान किए जाने वाले बदलावों के उदाहरण दिए गए हैं.
नुकसान पहुंचा सकने वाले बदलाव
वर्कबॉक्स-कोर
workbox-core में skipWaiting() तरीका अब install हैंडलर में नहीं जोड़ा जाएगा. यह सिर्फ़ self.skipWaiting() को कॉल करने के बराबर है.
अब से self.skipWaiting() का इस्तेमाल करें, क्योंकि हो सकता है कि वर्कबॉक्स v7 से skipWaiting() को हटा दिया जाए.
वर्कबॉक्स-प्रीकैशिंग
- एचटीटीपी रीडायरेक्ट से जुड़े यूआरएल के लिए, क्रॉस-ऑरिजिन वाले एचटीएमएल दस्तावेज़ का इस्तेमाल, अब
workbox-precachingके साथ नेविगेशन के अनुरोध को पूरा करने के लिए नहीं किया जा सकता. आम तौर पर, ऐसा आम तौर पर नहीं होता है. - किसी अनुरोध के लिए, पहले से कैश मेमोरी में सेव किए गए रिस्पॉन्स को देखते समय,
workbox-precachingअबfbclidयूआरएल क्वेरी पैरामीटर को नज़रअंदाज़ कर देता है. PrecacheControllerकंस्ट्रक्टर अब स्ट्रिंग के बजाय, खास प्रॉपर्टी वाले ऑब्जेक्ट को अपने पैरामीटर के तौर पर लेता है. यह ऑब्जेक्ट इन प्रॉपर्टी के साथ काम करता है:cacheName(वही काम जो v5 में कंस्ट्रक्टर को पास की गई स्ट्रिंग के समान काम करता है),plugins(v5 सेaddPlugins()तरीके को बदलता है), औरfallbackToNetwork(createHandler()और v5 में `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()के लिए कॉल डालते हैं, तो इससे आपके रास्तों की जांच का क्रम अलग हो सकता है.
वर्कबॉक्स रूटिंग
setDefaultHandler() का तरीका अब एक वैकल्पिक दूसरा पैरामीटर लेता है. यह पैरामीटर उस एचटीटीपी तरीके से जुड़ा होता है जिस पर यह लागू होता है और जो डिफ़ॉल्ट रूप से 'GET' पर लागू होता है.
- अगर
setDefaultHandler()का इस्तेमाल किया जाता है और आपके सभी अनुरोधGETहैं, तो कोई बदलाव करने की ज़रूरत नहीं है. - अगर आपके पास कोई ऐसा अनुरोध है जो
GET(POST,PUTवगैरह...) नहीं है, तोsetDefaultHandler()की वजह से अब उन अनुरोधों का मिलान नहीं होगा.
बिल्ड कॉन्फ़िगरेशन
workbox-build और workbox-cli में getManifest और injectManifest मोड के लिए mode विकल्प का इस्तेमाल नहीं किया जाना चाहिए था और इसे हटा दिया गया है. यह workbox-webpack-plugin पर लागू नहीं होता, जो mode के InjectManifest प्लगिन में काम करता है.
बिल्ड टूल के लिए Node.js v10 या इसके बाद के वर्शन की ज़रूरत होती है
workbox-webpack-plugin, workbox-build या workbox-cli के लिए, अब v10 से पहले के Node.js वर्शन काम नहीं करते. अगर आपके पास Node.js का v8 से पहले का वर्शन है, तो अपने रनटाइम को काम करने वाले वर्शन में अपडेट करें.
नए सुधार
वर्कबॉक्स बनाने की रणनीतियां
Workbox v6 में, तीसरे पक्ष के डेवलपर के लिए एक ऐसा नया तरीका उपलब्ध कराया गया है जिसकी मदद से, वे वर्कबॉक्स की रणनीतियां तय कर सकते हैं. इससे यह पक्का होता है कि तीसरे पक्ष के डेवलपर के पास Workbox को बढ़ाने की सुविधा है, ताकि वे अपनी ज़रूरतों को पूरा कर सकें.
नई रणनीति की बुनियादी क्लास
वर्शन 6 में, 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 बेस क्लास मैनेज करता है.
हैंडलर के लिए ज़्यादा सटीक टाइपस्क्रिप्ट टाइप
अलग-अलग कॉलबैक के तरीकों के लिए टाइपस्क्रिप्ट की परिभाषाएं सामान्य कर दी गई हैं. इससे उन डेवलपर को बेहतर अनुभव मिलेगा जो टाइपस्क्रिप्ट का इस्तेमाल करते हैं और लागू करने या कॉल हैंडलर लागू करने के लिए अपना कोड लिखते हैं.
वर्कबॉक्स-विंडो
नया messagePauseStatusing() तरीका
"इंतज़ार कर रहे" सर्विस वर्कर को चालू करने के लिए कहने की प्रोसेस को आसान बनाने के लिए, workbox-window मॉड्यूल में एक नया तरीका messageSkipWaiting() जोड़ा गया है. इससे कुछ सुधार किए जाते हैं:
- यह असल में स्टैंडर्ड मैसेज का मुख्य हिस्सा
{type: 'SKIP_WAITING'}के साथpostMessage()को कॉल करता है. वर्कबॉक्स से जनरेट किया गया सर्विस वर्कर,skipWaiting()को ट्रिगर करने के लिए इसकी जांच करता है. - यह इस मैसेज को पोस्ट करने के लिए सही "इंतज़ार करने वाले" सर्विस वर्कर को चुनता है, भले ही यह वही सर्विस वर्कर न हो जिसके साथ
workbox-windowको रजिस्टर किया गया था.
isबाहरी प्रॉपर्टी के लिए "बाहरी" इवेंट को हटाना
workbox-window में मौजूद सभी "external" इवेंट, "सामान्य" इवेंट की जगह हटा दिए गए हैं. isExternal प्रॉपर्टी को true पर सेट किया गया है. इससे उन डेवलपर को प्रॉपर्टी का पता चलता है जिन्हें खास फ़र्क़ पड़ता है. साथ ही, जिन डेवलपर को जानने की ज़रूरत नहीं है वे प्रॉपर्टी को अनदेखा कर सकते हैं.
"उपयोगकर्ताओं के लिए पेज को फिर से लोड करने की सुविधा दें" वाली रेसिपी
ऊपर दिए गए दोनों बदलावों की मदद से, "उपयोगकर्ताओं के लिए पेज फिर से लोड करें" रेसिपी को आसान बनाया जा सकता है:
MULTI_LINE_CODE_PLACEHOLDER_0
वर्कबॉक्स रूटिंग
workbox-routing में इस्तेमाल किए गए matchCallback फ़ंक्शन को, एक नया बूलियन पैरामीटर sameOrigin, पास किया गया है. अगर अनुरोध किसी एक ही ऑरिजिन वाले यूआरएल के लिए किया गया है, तो इसे true पर सेट किया जाता है. अगर ऐसा नहीं होता है, तो इसे 'गलत' पर सेट किया जाता है.
इससे कुछ सामान्य बॉयलरप्लेट आसान हो जाते हैं:
MULTI_LINE_CODE_PLACEHOLDER_1
वर्कबॉक्स-खत्म होने की तारीख में मिलान विकल्प
अब workbox-expiration में matchOptions सेट किया जा सकता है. इसके बाद, इसे CacheQueryOptions के तौर पर मौजूदा cache.delete() कॉल में भेजा जाएगा. (ज़्यादातर डेवलपर को ऐसा करने की ज़रूरत नहीं होगी.)
वर्कबॉक्स-प्रीकैशिंग
वर्कबॉक्स वाली रणनीतियों का इस्तेमाल किया जाता है
workbox-strategies को बेस के तौर पर इस्तेमाल करने के लिए, workbox-precaching को फिर से लिखा गया है. इसकी वजह से, नुकसान पहुंचाने वाला कोई बदलाव नहीं होगा. साथ ही, दो मॉड्यूल के नेटवर्क और कैश मेमोरी को ऐक्सेस करने के तरीके में लंबे समय तक सुधार होता रहेगा.
पहले से कैश मेमोरी में सेव करने की सुविधा से, अब एंट्री को एक-एक करके प्रोसेस किया जाता है, न कि बल्क में
workbox-precaching को अपडेट किया गया है, ताकि प्रीकैश मेमोरी में मौजूद सिर्फ़ एक एंट्री को अनुरोध करके कैश मेमोरी में सेव किया जा सके. इससे पहले, कैश मेमोरी में सेव किए गए सभी आइटम को एक साथ अनुरोध करके कैश मेमोरी में सेव करने की कोशिश नहीं की जाती है. नए डेटा को थ्रॉटल करने का तरीका जानने के लिए, इसे ब्राउज़र पर छोड़ दिया जाता है.
इससे, डेटा को पहले से कैश मेमोरी में सेव करते समय, net::ERR_INSUFFICIENT_RESOURCES की गड़बड़ियों की संभावना कम हो जानी चाहिए. साथ ही, इससे वेब ऐप्लिकेशन की मदद से, पहले से कैश मेमोरी में सेव किए गए और एक साथ किए जाने वाले अनुरोधों के बीच बैंडविड्थ को कम किया जा सकता है.
PrecacheFallbackPlugin, ऑफ़लाइन फ़ॉलबैक को आसान बनाते हैं
workbox-precaching में अब एक PrecacheFallbackPlugin शामिल है, जो वर्शन 6 में जोड़े गए, handlerDidError लाइफ़साइकल का नया तरीका लागू करता है.
जब रिस्पॉन्स उपलब्ध नहीं होता, तब किसी रणनीति के लिए, पहले से कैश मेमोरी में सेव किए गए यूआरएल को "फ़ॉलबैक" के तौर पर तय करना आसान हो जाता है. प्लग-इन, पहले से कैश मेमोरी में सेव किए गए यूआरएल के लिए, कैश मेमोरी में सही कुंजी बनाने का ध्यान रखेगा. इसमें ज़रूरत के हिसाब से बदलाव किए गए पैरामीटर भी शामिल होंगे.
जब NetworkOnly रणनीति किसी नेविगेशन अनुरोध के लिए रिस्पॉन्स जनरेट नहीं कर पाती, तब इसका इस्तेमाल, पहले से कैश मेमोरी में सेव किए गए /offline.html के साथ जवाब देने के लिए करने का सैंपल यहां दिया गया है—दूसरे शब्दों में, कस्टम ऑफ़लाइन एचटीएमएल पेज दिखा रहा है:
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 पर समस्या के बारे में जानकारी देकर हमें बताएं.