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

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

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

workbox-precaching

पहले से कैश मेमोरी में सेव की गई एंट्री के लिए, नाम रखने का तरीका अपडेट कर दिया गया है. अब जिन एंट्री के यूआरएल में बदलाव करने की ज़रूरत है उनके लिए, वर्शन की जानकारी को कैश मेमोरी कुंजी के हिस्से के तौर पर सेव किया जाएगा. यह जानकारी, ओरिजनल यूआरएल में जोड़े गए खास __WB_REVISION__ यूआरएल क्वेरी पैरामीटर में सेव की जाएगी.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

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-background-sync

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

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

v4 में, addRequests() तरीका हटा दिया गया है. साथ ही, ऐरे जैसे ये तरीके जोड़े गए हैं:

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

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

v4 में, इन कॉलबैक को किसी एक 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 पैकेज जैसा ही है. हालांकि, अब इस पैकेज का इस्तेमाल नहीं किया जा सकता.

workbox-broadcast-update

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

workbox-core

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

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

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

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

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

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

इस पुल रिक्वेस्ट में, Workbox v3 से v4 पर असल दुनिया में डेटा माइग्रेट करने का उदाहरण दिया गया है.

सहायता पाना

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