Workbox v3 से v4 पर माइग्रेट करना

इस गाइड में, Workbox v4 में लॉन्च किए गए नए बदलावों के बारे में बताया गया है. साथ ही, इसमें Workbox v3 से अपग्रेड करने के दौरान किए जाने वाले बदलावों के उदाहरण भी दिए गए हैं.

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

वर्कबॉक्स-प्रीकैशिंग

पहले से कैश मेमोरी में सेव की गई एंट्री को नाम देने के तरीके में बदलाव किया गया है. अब, जिन एंट्री के यूआरएल में बदलावों के बारे में जानकारी चाहिए (यानी कि वे एंट्री जिनमें प्री-कैश मेनिफ़ेस्ट में revision फ़ील्ड शामिल है) उन्हें वर्शन की जानकारी को कैश कुंजी के हिस्से के तौर पर, मूल यूआरएल से जुड़े एक खास __WB_REVISION__ यूआरएल क्वेरी पैरामीटर में सेव किया जाएगा. (पहले, इस जानकारी को IndexedDB का इस्तेमाल करके, कैश मेमोरी कुंजियों से अलग स्टोर किया जाता था.)

जो डेवलपर workbox.precaching.precacheAndRoute() के ज़रिए प्री-कैशिंग का फ़ायदा लेते हैं, जो सबसे आम इस्तेमाल का उदाहरण है, उन्हें अपने सर्विस वर्कर कॉन्फ़िगरेशन में कोई बदलाव करने की ज़रूरत नहीं है; Workbox v4 में अपग्रेड करने पर, आपके उपयोगकर्ताओं की कैश मेमोरी में सेव की गई ऐसेट, अपने-आप नए कैश कुंजी फ़ॉर्मैट में माइग्रेट हो जाएंगी. साथ ही, पहले से कैश मेमोरी में सेव किए गए रिसॉर्स, पहले की तरह ही उपलब्ध कराए जाएंगे.

सीधे कैश कुंजियों का इस्तेमाल करना

कुछ डेवलपर को प्री-कैश एंट्री को सीधे ऐक्सेस करना पड़ सकता है. ऐसा workbox.precaching.precacheAndRoute() के अलावा किसी और काम के लिए किया जा सकता है. उदाहरण के लिए, किसी ऐसी इमेज को प्री-कैश किया जा सकता है जिसका इस्तेमाल "फ़ॉलबैक" रिस्पॉन्स के तौर पर किया जाता है. ऐसा तब किया जाता है, जब किसी इमेज को नेटवर्क से फ़ेच नहीं किया जा सकता.

अगर इस तरह से पहले से कैश मेमोरी में सेव की गई एसेट का इस्तेमाल किया जाता है, तो Workbox v4 से, किसी ओरिजनल यूआरएल को उससे जुड़ी कैश कुंजी में बदलने के लिए एक और चरण पूरा करना होगा. इसका इस्तेमाल कैश मेमोरी में सेव की गई एंट्री को पढ़ने के लिए किया जा सकेगा. ऐसा करने के लिए, workbox.precaching.getCacheKeyForURL(originURL) पर कॉल करें.

उदाहरण के लिए, अगर आपको पता है कि 'fallback.png' प्री-कैश किया गया है, तो:

const imageFallbackCacheKey =
  workbox.precaching.getCacheKeyForURL('fallback.png');

workbox.routing.setCatchHandler(({event}) => {
  switch (event.request.destination) {
    case 'image':
      return caches.match(imageFallbackCacheKey);
      break;
    // ...other fallback logic goes here...
  }
});

पहले से सेव किया गया पुराना डेटा हटाना

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

इससे बचने के लिए, workbox.precaching.cleanupOutdatedCaches() को सीधे सर्विस वर्कर को कॉल किया जा सकता है. इसके अलावा, अगर GenerateSW मोड में बिल्ड टूल का इस्तेमाल किया जा रहा है, तो नया cleanupOutdatedCaches: true विकल्प सेट करें. कैश क्लीनअप का लॉजिक, पहले से कैश मेमोरी में सेव किए गए पुराने डेटा का पता लगाने के लिए कैश मेमोरी का नाम रखने के तरीकों पर काम करता है. साथ ही, डेवलपर के पास उन कन्वेंशन को बदलने का विकल्प होने की वजह से, हमने सुरक्षा को ध्यान में रखते हुए काम करने का फ़ैसला नहीं लिया और इसे डिफ़ॉल्ट रूप से चालू नहीं किया.

हम उन डेवलपर को हमें बताने की सलाह देते हैं जिन्हें इसका इस्तेमाल करने में कोई समस्या आती है. जैसे, डेटा मिटाने के बारे में गलत जानकारी देना.

पैरामीटर में कैपिटल लेटर का इस्तेमाल करना

कैपिटल लेटर के इस्तेमाल का स्टैंडर्ड तरीका तय करने के लिए, workbox.precaching.precacheAndRoute() और workbox.precaching.addRoute() को भेजे जा सकने वाले दो वैकल्पिक पैरामीटर के नाम बदले गए हैं. ignoreUrlParametersMatching अब ignoreURLParametersMatching है और cleanUrls अब cleanURLs है.

वर्कबॉक्स की रणनीतियां

workbox-strategies में हैंडलर के इंस्टेंस बनाने के दो तरीके हैं. ये करीब-करीब एक जैसे हैं. हम फ़ैक्ट्री तरीके का इस्तेमाल बंद कर रहे हैं, ताकि रणनीति बनाने वाले को साफ़ तौर पर कॉल किया जा सके.

// This factory method syntax has been deprecated:
const networkFirstStrategy = workbox.strategies.networkFirst({...});

// Instead, use the constructor directly:
// (Note that the class name is Uppercase.)
const networkFirstStrategy = new workbox.strategies.NetworkFirst({...});

हालांकि, v4 में फ़ैक्ट्री तरीके का सिंटैक्स काम करता रहेगा, लेकिन इसका इस्तेमाल करने पर एक चेतावनी लॉग की जाएगी. साथ ही, हम डेवलपर को सुझाव देते हैं कि वे आने वाले v5 वर्शन में सहायता हटाने से पहले ही माइग्रेट कर लें.

वर्कबॉक्स-बैकग्राउंड-सिंक

workbox.backgroundSync.Queue क्लास में बदलाव किया गया है, ताकि डेवलपर को अपने हिसाब से यह कंट्रोल दिया जा सके कि उनके अनुरोधों को सूची में जोड़ने और उन्हें फिर से चलाने का तरीका क्या है.

वर्शन 3 में, Queue क्लास के पास सूची में अनुरोधों को जोड़ने का एक ही तरीका था (addRequest() तरीका), लेकिन इसमें सूची में बदलाव करने या अनुरोधों को हटाने का कोई तरीका नहीं था.

वर्शन 4 में, addRequests() वाला तरीका हटा दिया गया है और अरे जैसे ये तरीके जोड़े गए हैं:

• pushRequest()
• popRequest()
• shiftRequest()
• unshiftRequest()

वर्शन 3 में, Queue क्लास ने कई कॉलबैक स्वीकार किए, जिनसे आपको यह पता चलता था कि अनुरोधों को कब फिर से चलाया गया (requestWillEnqueue, requestWillReplay, queueDidReplay), लेकिन ज़्यादातर डेवलपर ने यह भी देखा कि वे निगरानी के अलावा, सूची को फिर से चलाने के तरीके पर भी कंट्रोल चाहते थे. इसमें डाइनैमिक तौर पर बदलाव करना, उनका क्रम बदलना या अलग-अलग अनुरोधों को रद्द करना भी शामिल था.

वर्शन 4 में, इन कॉलबैक को सिंगल onSync कॉलबैक के हिसाब से हटा दिया गया है. जब भी ब्राउज़र, वीडियो को फिर से चलाने की कोशिश करता है, तब यह सुविधा चालू हो जाती है. डिफ़ॉल्ट रूप से, onSync कॉलबैक replayRequests() को शुरू करेगा. हालांकि, अगर आपको रीप्ले की प्रोसेस पर ज़्यादा कंट्रोल चाहिए, तो सूची को फिर से चलाने के लिए ऊपर दिए गए अरे जैसे तरीकों का इस्तेमाल किया जा सकता है.

यहां पसंद के मुताबिक रीप्ले लॉजिक का उदाहरण दिया गया है:

const queue = new workbox.backgroundSync.Queue('my-queue-name', {
  onSync: async ({queue}) => {
    let entry;
    while ((entry = await this.shiftRequest())) {
      try {
        await fetch(entry.request);
      } catch (error) {
        console.error('Replay failed for request', entry.request, error);
        await this.unshiftRequest(entry);
        return;
      }
    }
    console.log('Replay complete!');
  },
});

इसी तरह, workbox.backgroundSync.Plugin क्लास, Queue क्लास वाले आर्ग्युमेंट को स्वीकार करती है, क्योंकि यह अंदरूनी तौर पर Queue इंस्टेंस बनाता है. इसलिए, इसमें भी उसी तरह का बदलाव किया गया है.

वर्कबॉक्स खत्म करना

npm पैकेज का नाम बदलकर workbox-expiration कर दिया गया है. यह दूसरे मॉड्यूल के नाम के फ़ॉर्मैट से मेल खाता है. यह पैकेज पुराने workbox-cache-expiration पैकेज के समान है, लेकिन अब इसका इस्तेमाल नहीं किया जाता.

वर्कबॉक्स-ब्रॉडकास्ट-अपडेट

npm पैकेज का नाम बदलकर workbox-broadcast-update कर दिया गया है. यह दूसरे मॉड्यूल के नाम के फ़ॉर्मैट से मेल खाता है. यह पैकेज पुराने workbox-broadcast-cache-update पैकेज के समान है, लेकिन अब इसका इस्तेमाल नहीं किया जाता.

वर्कबॉक्स-कोर

Workbox v3 में, लॉग लेवल की वर्बोसिटी को workbox.core.setLogLevel() तरीके से कंट्रोल किया जा सकता है, जिसे workbox.core.LOG_LEVELS enum में किसी एक वैल्यू से पास किया जाता है. workbox.core.logLevel के ज़रिए, मौजूदा लॉग लेवल को भी पढ़ा जा सकता है.

Workbox v4 में, इन सभी को हटा दिया गया है, क्योंकि सभी आधुनिक डेवलपर टूल को अब बेहतर लॉग फ़िल्टर करने की क्षमताओं के साथ भेजा जाता है (Chrome Dev टूल के लिए कंसोल आउटपुट को फ़िल्टर करना देखें).

वर्कबॉक्स-sw

workbox नेमस्पेस (जो workbox-sw मॉड्यूल से जुड़ा है) पर पहले सीधे तौर पर सार्वजनिक हुआ था, उसके दो तरीकों को workbox.core में ट्रांसफ़र कर दिया गया है. workbox.skipWaiting(), workbox.core.skipWaiting() हो गया है. इसी तरह, workbox.clientsClaim() भी workbox.core.clientsClaim() हो गया है.

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

कुछ विकल्पों के नाम बदल गए हैं जिन्हें Workbox-cli, Workbox-build या Workbox-webpack-plugin में से किसी एक में भेजा जा सकता है. जब भी किसी विकल्प के नाम में "यूआरएल" का इस्तेमाल किया जाता है, तो उसे "यूआरएल" की जगह रोक दिया जाता है. इसका मतलब है कि नीचे दिए गए विकल्पों के नाम को प्राथमिकता दी जाती है:

• dontCacheBustURLsMatching
• ignoreURLParametersMatching
• modifyURLPrefix
• templatedURLs

उन विकल्प नामों का "यूआरएल" वैरिएशन, अब भी वर्शन 4 में काम करता है. हालांकि, इससे चेतावनी का मैसेज मिलेगा. हम डेवलपर को v5 रिलीज़ से पहले माइग्रेट करने के लिए बढ़ावा देते हैं.

नई सुविधाएं

वर्कबॉक्स-विंडो

नया workbox-window मॉड्यूल, सर्विस वर्कर के रजिस्ट्रेशन और अपडेट का पता लगाने की प्रक्रिया को आसान बनाता है. साथ ही, सर्विस वर्कर में चल रहे कोड और आपके वेब ऐप्लिकेशन के window कॉन्टेक्स्ट में चल रहे कोड के बीच कम्यूनिकेशन का एक स्टैंडर्ड तरीका उपलब्ध कराता है.

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

माइग्रेशन का उदाहरण

Workbox v3 से v4 में असल दुनिया में होने वाले माइग्रेशन का एक उदाहरण, इस पुल अनुरोध में देखा जा सकता है.

सहायता पाना

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