सर्विस वर्कर और कैश मेमोरी एपीआई का इस्तेमाल करने वाले डेवलपर को Chrome 71 में लॉन्च होने वाले दो छोटे बदलावों पर नज़र रखनी चाहिए. दोनों ही बदलावों से, Chrome में खास जानकारी और अन्य ब्राउज़र के हिसाब से काम करने में आसानी होती है.
एसिंक्रोनस इंपोर्ट स्क्रिप्ट() को अनुमति न देना
importScripts()
आपके मुख्य सर्विस वर्कर स्क्रिप्ट को इसके मौजूदा एक्ज़ीक्यूशन को रोकने, दिए गए यूआरएल से अतिरिक्त कोड डाउनलोड करने, और उसे मौजूदा ग्लोबल स्कोप में पूरा होने तक चलाने के लिए कहता है. ऐसा होने के बाद,
मुख्य सर्विस वर्कर स्क्रिप्ट का एक्ज़ीक्यूशन फिर से शुरू हो जाता है. importScripts() का इस्तेमाल तब किया जा सकता है, जब संगठन की वजहों से, मुख्य सर्विस वर्कर स्क्रिप्ट को छोटे-छोटे हिस्सों में बांटना हो या अपने सर्विस वर्कर में फ़ंक्शन जोड़ने के लिए तीसरे पक्ष का कोड इस्तेमाल करना हो.
ब्राउज़र "डाउनलोड करें और सिंक करने वाले कुछ कोड चलाएं" की परफ़ॉर्मेंस के सही अनुमान को कम करने की कोशिश करते हैं. इसके लिए, वे importScripts() से इकट्ठा की गई सभी चीज़ों को अपने-आप कैश मेमोरी में सेव करते हैं. इसका मतलब है कि शुरुआती डाउनलोड के बाद, इंपोर्ट किए गए कोड को पूरा करने में बहुत कम खर्च लगता है.
हालांकि, इसे काम करने के लिए ब्राउज़र को यह जानने की ज़रूरत है कि शुरुआती इंस्टॉलेशन के बाद, सर्विस वर्कर में कोई "सरप्राइज़" कोड इंपोर्ट नहीं किया जाएगा.
सर्विस वर्कर विशेषता के मुताबिक, importScripts() को सिर्फ़ टॉप-लेवल सर्विस वर्कर स्क्रिप्ट के सिंक्रोनस एक्ज़ीक्यूशन के दौरान या ज़रूरी होने पर, install हैंडलर में एसिंक्रोनस तरीके से काम करना चाहिए.
Chrome 71 से पहले, importScripts() को install हैंडलर के बाहर एसिंक्रोनस रूप से कॉल
करने की सुविधा काम करेगी. Chrome 71 में, ये कॉल दूसरे ब्राउज़र के व्यवहार
से मेल खाने वाले, रनटाइम अपवाद (अगर वही यूआरएल पहले install हैंडलर में इंपोर्ट नहीं किया गया था)
चलाते हैं.
इस तरह के कोड के बजाय:
// This only works in Chrome 70 and below.
self.addEventListener('fetch', event => {
importScripts('my-fetch-logic.js');
event.respondWith(self.customFetchLogic(event));
});
आपका सर्विस वर्कर कोड ऐसा दिखना चाहिए:
// Move the importScripts() to the top-level scope.
// (Alternatively, import the same URL in the install handler.)
importScripts('my-fetch-logic.js');
self.addEventListener('fetch', event => {
event.respondWith(self.customFetchLogic(event));
});
cache.addAll() को भेजे गए दोहराए गए यूआरएल को रोकना
अगर आपने सर्विस वर्कर के साथ कैश स्टोरेज एपीआई का इस्तेमाल किया है, तो Chrome 71 में एक और छोटा सा बदलाव किया गया है. ऐसा ज़रूरी निर्देशों के मुताबिक करने के लिए किया गया है. अगर cache.addAll() को एक ही यूआरएल पर कई बार कॉल किया जाता है, तो जानकारी में बताया गया है कि कॉल के ज़रिए किया गया प्रॉमिस अस्वीकार होना चाहिए.
Chrome 71 से पहले, इसका पता नहीं चला था और डुप्लीकेट यूआरएल को अनदेखा कर दिया जाता था.
यह लॉगिंग Chrome 72 की एक शुरुआत है, जहां सिर्फ़ लॉग की गई चेतावनी के बजाय, डुप्लीकेट यूआरएल
cache.addAll() को अस्वीकार कर देंगे. अगर आपने cache.addAll() को InstallEvent.waitUntil() को पास की गई प्रॉमिस चेन के हिस्से के तौर पर कॉल किया है,
तो आम तौर पर ऐसा किया जाता है. अस्वीकार किए जाने की वजह से हो सकता है कि आपके सर्विस वर्कर को इंस्टॉल न हो पाए.
आपको इन तरीकों से समस्या आ सकती है:
const urlsToCache = [
'/index.html',
'/main.css',
'/app.js',
'/index.html', // Oops! This is listed twice and should be removed.
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open('my-cache').then(cache => cache.addAll(urlsToCache))
);
});
यह पाबंदी सिर्फ़ cache.addAll() को भेजे जा रहे असली यूआरएल पर लागू होती है. साथ ही, '/' और '/index.html' जैसे अलग-अलग यूआरएल वाले दो मिलते-जुलते रिस्पॉन्स, कैश मेमोरी में सेव होने पर भी अस्वीकार नहीं किया जाएगा.
अपने सर्विस वर्कर लागू करने की प्रक्रिया की बड़े पैमाने पर जांच करना
इस समय सर्विस वर्कर को सभी बड़े "सदाबहार" ब्राउज़र पर पूरी तरह से लागू किया जाता है. अगर कई ब्राउज़र पर अपने प्रोग्रेसिव वेब ऐप्लिकेशन की नियमित तौर पर जांच की जाती है या आपके पास Chrome का इस्तेमाल न करने वाले बड़ी संख्या में उपयोगकर्ता हैं, तो हो सकता है कि आपने पहले ही गड़बड़ी का पता लगाकर अपना कोड अपडेट कर लिया हो. हालांकि, अगर आपने किसी अन्य ब्राउज़र में इस तरह के व्यवहार पर ध्यान नहीं दिया है, तो हम Chrome की सेटिंग को बदलने से पहले इस बदलाव के बारे में बताना चाहते थे.