इस पेज का अनुवाद Cloud Translation API से किया गया है.

सर्विस वर्कर का लाइफ़साइकल

Jake Archibald

सर्विस वर्कर का जीवनचक्र इसका सबसे जटिल हिस्सा होता है. अगर आपको नहीं पता कि वह क्या करना है और उसके क्या फ़ायदे हैं, तो ऐसा लग सकता है कि वह आपसे लड़ रहा है. हालांकि, जब आपको पता चल जाता है कि यह कैसे काम करता है, तो उपयोगकर्ताओं को आसानी से अपडेट भेजे जा सकते हैं. इसके लिए, वेब और नेटिव पैटर्न का सबसे अच्छा इस्तेमाल किया जा सकता है.

इस बारे में काफ़ी जानकारी दी गई है, लेकिन हर सेक्शन के शुरू में दिए गए बुलेट पॉइंट में, आपके लिए ज़रूरी जानकारी दी गई है.

इंटेंट

लाइफ़साइकल का मकसद:

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

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

पहला सर्विस वर्कर

संक्षेप में:

install इवेंट, किसी सर्विस वर्कर को मिलने वाला पहला इवेंट होता है और यह सिर्फ़ एक बार होता है.
installEvent.waitUntil() को भेजा गया प्रॉमिस, आपके ऐप्लिकेशन को इंस्टॉल किए जाने की अवधि और सफलता या असफलता के बारे में बताता है.
सर्विस वर्कर को fetch और push जैसे इवेंट तब तक नहीं मिलेंगे, जब तक वह इंस्टॉल नहीं हो जाता और "चालू" नहीं हो जाता.
डिफ़ॉल्ट रूप से, किसी पेज के फ़ेच तब तक सर्विस वर्कर से नहीं जुड़े होंगे, जब तक पेज का अनुरोध खुद किसी सर्विस वर्कर के ज़रिए नहीं किया जाता. इसलिए, सर्विस वर्कर के असर को देखने के लिए आपको पेज रीफ़्रेश करना होगा.
clients.claim(), इस डिफ़ॉल्ट सेटिंग को बदल सकता है और ऐसे पेजों को कंट्रोल कर सकता है जिन्हें कंट्रोल नहीं किया जाता.

इस एचटीएमएल को लें:

<!DOCTYPE html>
An image will appear here in 3 seconds:
<script>
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered!', reg))
    .catch(err => console.log('Boo!', err));

  setTimeout(() => {
    const img = new Image();
    img.src = '/dog.svg';
    document.body.appendChild(img);
  }, 3000);
</script>

इसमें सर्विस वर्कर को रजिस्टर किया जाता है और तीन सेकंड के बाद कुत्ते की इमेज जोड़ी जाती है.

यह रहा इसका सर्विस वर्कर, sw.js:

self.addEventListener('install', event => {
  console.log('V1 installing…');

  // cache a cat SVG
  event.waitUntil(
    caches.open('static-v1').then(cache => cache.add('/cat.svg'))
  );
});

self.addEventListener('activate', event => {
  console.log('V1 now ready to handle fetches!');
});

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);

  // serve the cat SVG from the cache if the request is
  // same-origin and the path is '/dog.svg'
  if (url.origin == location.origin && url.pathname == '/dog.svg') {
    event.respondWith(caches.match('/cat.svg'));
  }
});

यह एक बिल्ली की इमेज को कैश मेमोरी में सेव करता है और /dog.svg के लिए अनुरोध करने पर इसे दिखाता है. हालांकि, अगर ऊपर दिए गए उदाहरण को चलाया जाता है, तो पहली बार पेज लोड होने पर आपको एक कुत्ता दिखेगा. रीफ़्रेश करें पर टैप करने पर आपको बिल्ली दिखेगी.

दायरा और कंट्रोल

सर्विस वर्कर रजिस्ट्रेशन का डिफ़ॉल्ट स्कोप ./ है, जो स्क्रिप्ट यूआरएल से मिलता-जुलता है. इसका मतलब है कि अगर किसी सर्विस वर्कर को //example.com/foo/bar.js पर रजिस्टर किया जाता है, तो उसका डिफ़ॉल्ट स्कोप //example.com/foo/ होता है.

हम पेजों, वर्कर, और शेयर किए गए वर्कर clients को कॉल करते हैं. आपका सर्विस वर्कर, सिर्फ़ उन क्लाइंट को कंट्रोल कर सकता है जो इसके दायरे में हैं. क्लाइंट के "कंट्रोल" होने के बाद, उसके फ़ेच, स्कोप में मौजूद सर्विस वर्कर से गुज़र जाते हैं. आप यह पता लगा सकते हैं कि किसी क्लाइंट को navigator.serviceWorker.controller के ज़रिए कंट्रोल किया जाता है या नहीं, जो शून्य होगा या सर्विस वर्कर इंस्टेंस पर.

डाउनलोड करना, पार्स करना, और लागू करना

जब आप .register() को कॉल करते हैं, तो आपका सबसे पहला सर्विस वर्कर डाउनलोड होता है. अगर आपकी स्क्रिप्ट डाउनलोड नहीं हो पाती, पार्स नहीं हो पाती या शुरुआती एक्ज़ीक्यूशन के दौरान कोई गड़बड़ी होती है, तो रजिस्टर प्रॉमिस अस्वीकार कर दिया जाता है और सर्विस वर्कर को खारिज कर दिया जाता है.

Chrome का DevTools, कंसोल और ऐप्लिकेशन टैब के सर्विस वर्कर सेक्शन में गड़बड़ी दिखाता है:

सर्विस वर्कर DevTools टैब में गड़बड़ी दिखाई गई

इंस्टॉल करें

सर्विस वर्कर को पहला इवेंट install मिलता है. जैसे ही वर्कर एक्ज़ीक्यूट होता है, यह ट्रिगर हो जाता है और इसे हर सर्विस वर्कर के लिए सिर्फ़ एक बार कॉल किया जाता है. अगर आपने सर्विस वर्कर स्क्रिप्ट को बदला है, तो ब्राउज़र इसे कोई दूसरा सर्विस वर्कर मानता है. इसे अपना install इवेंट मिलेगा. मैं अपडेट के बारे में बाद में विस्तार से बताऊँगी.

install इवेंट की मदद से, क्लाइंट को कंट्रोल करने से पहले, अपनी ज़रूरत की सभी चीज़ों को कैश मेमोरी में सेव किया जा सकता है. event.waitUntil() को पास किए जाने वाले प्रॉमिस, ब्राउज़र को यह जानने में मदद करती है कि आपका इंस्टॉल कब पूरा होता है और वह सफल रहा या नहीं.

अगर आपका प्रॉमिस अस्वीकार हो जाता है, तो यह माना जाता है कि इंस्टॉल नहीं हो सका. साथ ही, ब्राउज़र सर्विस वर्कर को अलग कर देता है. यह कभी भी क्लाइंट को कंट्रोल नहीं करेगा. इसका मतलब है कि हम अपने fetch इवेंट की कैश मेमोरी में, cat.svg के मौजूद होने पर भरोसा नहीं कर सकते. यह निर्भर करता है.

चालू करें

जब आपका सर्विस वर्कर, क्लाइंट को कंट्रोल करने और push और sync जैसे फ़ंक्शनल इवेंट को मैनेज करने के लिए तैयार हो जाता है, तब आपको एक activate इवेंट मिलेगा. हालांकि, इसका मतलब यह नहीं है कि .register() नाम वाले पेज को कंट्रोल किया जाएगा.

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

clients.claim

इसके चालू होने के बाद, सर्विस वर्कर में clients.claim() को कॉल करके अनियंत्रित क्लाइंट को कंट्रोल किया जा सकता है.

यहां ऊपर दिए गए डेमो का एक वैरिएशन दिया गया है. इसके activate इवेंट में, clients.claim() को कॉल किया गया है. आपको पहली बार बिल्ली दिखाई चाहिए. मैंने कहा "चाहिए", क्योंकि यह टाइमिंग संवेदनशील है. आपको बिल्ली सिर्फ़ तब दिखेगी, जब सर्विस वर्कर चालू हो जाएगा और इमेज लोड होने से पहले clients.claim() लागू हो जाएगी.

अगर आप नेटवर्क से लोड होने वाले पेजों की तुलना में, अलग-अलग तरीके से पेजों को लोड करने के लिए अपने सर्विस वर्कर का इस्तेमाल करते हैं, तो clients.claim() परेशान कर सकता है, क्योंकि आपका सर्विस वर्कर इसके बिना लोड होने वाले कुछ क्लाइंट को कंट्रोल करता है.

ध्यान दें: ध्यान दें: मुझे clients.claim() जैसे बहुत सारे लोग बॉयलरप्लेट के तौर पर दिखते हैं, लेकिन मैं खुद ऐसा शायद ही कभी करता हूं. इसका मतलब सिर्फ़ पहली बार लोड होने पर ही होता है. लगातार बेहतर होने की वजह से, यह पेज आम तौर पर सर्विस वर्कर के बिना अच्छी तरह से काम करता है.

सर्विस वर्कर को अपडेट किया जा रहा है

संक्षेप में:

इनमें से कुछ भी होने पर, अपडेट ट्रिगर होता है:
- दायरे से जुड़े पेज पर जाने का नेविगेशन.
- push और sync जैसे फ़ंक्शनल इवेंट. इनका इस्तेमाल तब तक नहीं किया जाएगा, जब तक पिछले 24 घंटों में अपडेट की जांच न की गई हो.
- .register() को सिर्फ़ तब कॉल किया जा रहा है, जब सर्विस वर्कर यूआरएल बदल गया हो. हालांकि, आपको कर्मी यूआरएल बदलने से बचना चाहिए.
Chrome 68 और उसके बाद के वर्शन सहित ज़्यादातर ब्राउज़र, रजिस्टर किए गए सर्विस वर्कर स्क्रिप्ट के अपडेट की जांच करते समय, डिफ़ॉल्ट रूप से कैश मेमोरी में सेव किए गए हेडर को अनदेखा करते हैं. वे अब भी importScripts() के ज़रिए सर्विस वर्कर के अंदर लोड किए गए संसाधनों को फ़ेच करते समय, कैश मेमोरी में डेटा सेव करने वाले हेडर का पालन करते हैं. अपने सर्विस वर्कर को रजिस्टर करते समय, updateViaCache विकल्प सेट करके इस डिफ़ॉल्ट व्यवहार को बदला जा सकता है.
अगर आपका सर्विस वर्कर, ब्राउज़र में पहले से मौजूद ब्राउज़र से बाइट-अलग है, तो इसे अपडेट किया गया माना जाता है. (हम इंपोर्ट किए गए स्क्रिप्ट/मॉड्यूल को भी शामिल करने के लिए इस सीमा को बढ़ा रहे हैं.)
अपडेट किए गए सर्विस वर्कर को मौजूदा सर्विस वर्कर के साथ लॉन्च किया जाता है और इसे अपना install इवेंट मिलता है.
अगर आपके नए वर्कर का स्टेटस कोड ठीक नहीं है (उदाहरण के लिए, 404), पार्स नहीं हो पाता है, उसे एक्ज़ीक्यूट करने के दौरान गड़बड़ी दिखती है या इंस्टॉल करने के दौरान उसे अस्वीकार कर देता है, तो नए वर्कर को फेंक दिया जाता है, लेकिन मौजूदा वर्कर ऐक्टिव रहता है.
इंस्टॉल होने के बाद, अपडेट किया गया वर्कर तब तक wait होगा, जब तक मौजूदा वर्कर किसी भी क्लाइंट को कंट्रोल नहीं करता. (ध्यान दें कि क्लाइंट रीफ़्रेश के दौरान ओवरलैप करते हैं.)
self.skipWaiting() इंतज़ार करने से रोकता है, यानी सर्विस वर्कर इंस्टॉल होते ही चालू हो जाता है.

मान लें कि हमने अपने सर्विस वर्कर की स्क्रिप्ट बदलकर, जवाब के तौर पर बिल्ली की जगह घोड़े की तस्वीर दिखाई:

const expectedCaches = ['static-v2'];

self.addEventListener('install', event => {
  console.log('V2 installing…');

  // cache a horse SVG into a new cache, static-v2
  event.waitUntil(
    caches.open('static-v2').then(cache => cache.add('/horse.svg'))
  );
});

self.addEventListener('activate', event => {
  // delete any caches that aren't in expectedCaches
  // which will get rid of static-v1
  event.waitUntil(
    caches.keys().then(keys => Promise.all(
      keys.map(key => {
        if (!expectedCaches.includes(key)) {
          return caches.delete(key);
        }
      })
    )).then(() => {
      console.log('V2 now ready to handle fetches!');
    })
  );
});

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);

  // serve the horse SVG from the cache if the request is
  // same-origin and the path is '/dog.svg'
  if (url.origin == location.origin && url.pathname == '/dog.svg') {
    event.respondWith(caches.match('/horse.svg'));
  }
});

ऊपर दिया गया डेमो देखें. आपको अब भी बिल्ली की इमेज दिखेगी. इसकी वजह यहां बताई गई है...

इंस्टॉल करें

ध्यान दें कि मैंने कैश मेमोरी का नाम static-v1 से बदलकर static-v2 कर दिया है. इसका मतलब है कि मैं मौजूदा कैश मेमोरी को सेट अप कर सकता हूं. इसके लिए, मौजूदा स्टोरेज की चीज़ों को ओवरराइट किए बिना ऐसा किया जा सकता है जिसका इस्तेमाल पुराना सर्विस वर्कर अब भी कर रहा है.

यह पैटर्न, वर्शन के हिसाब से कैश मेमोरी बनाता है. यह उन एसेट की तरह है जिन्हें किसी खास ऐप्लिकेशन के साथ एक्ज़ीक्यूट किया जा सकता है. आपके पास ऐसी कैश मेमोरी भी हो सकती है जो वर्शन के हिसाब से नहीं है, जैसे कि avatars.

इंतज़ार किया जा रहा है

इंस्टॉल होने के बाद, अपडेट किया गया सर्विस वर्कर तब तक चालू नहीं होता, जब तक मौजूदा सर्विस वर्कर क्लाइंट को कंट्रोल करना बंद नहीं कर देता. इस स्थिति को "प्रतीक्षा" कहा जाता है और इसी तरह से ब्राउज़र यह पक्का करता है कि एक समय में आपके सर्विस वर्कर का सिर्फ़ एक वर्शन चल रहा है.

अगर आपने अपडेट किया गया डेमो चलाया है, तो भी आपको एक बिल्ली का चित्र दिखाई देगा, क्योंकि V2 वर्कर अभी तक सक्रिय नहीं हुआ है. आप DevTools के "ऐप्लिकेशन" टैब में इंतज़ार कर रहे नए सर्विस वर्कर को देख सकते हैं:

DevTools में नए सर्विस वर्कर को इंतज़ार किया जा रहा है

भले ही डेमो के लिए आपने सिर्फ़ एक टैब खोला हो, लेकिन नए वर्शन की जगह लेने के लिए, पेज को रीफ़्रेश करना काफ़ी नहीं है. ऐसा ब्राउज़र नेविगेशन के काम करने के तरीके की वजह से होता है. नेविगेट करने पर, मौजूदा पेज तब तक नहीं दिखता, जब तक रिस्पॉन्स हेडर नहीं मिल जाते. साथ ही, जवाब के Content-Disposition हेडर होने पर भी मौजूदा पेज दिखता रहता है. इस ओवरलैप की वजह से, रीफ़्रेश करने के दौरान मौजूदा सर्विस वर्कर हमेशा क्लाइंट को कंट्रोल करता है.

अपडेट पाने के लिए, मौजूदा सर्विस वर्कर का इस्तेमाल करके सभी टैब को बंद करें या उनसे बाहर जाएं. इसके बाद, जब आप डेमो पर दोबारा जाएं, तो आपको घोड़ा दिखेगा.

यह पैटर्न, Chrome के अपडेट जैसा ही है. Chrome के अपडेट, बैकग्राउंड में डाउनलोड होंगे. हालांकि, ये अपडेट Chrome के रीस्टार्ट होने तक लागू नहीं होंगे. इस दौरान, बिना रुकावट के मौजूदा वर्शन का इस्तेमाल जारी रखा जा सकता है. हालांकि, डेवलपमेंट के दौरान इससे काफ़ी परेशानी होती है, लेकिन DevTools में इसे आसान बनाने के तरीके हैं. मैं इन तरीकों के बारे में इस लेख में बाद में बताऊंगी.

चालू करें

पुराना सर्विस वर्कर खत्म होने के बाद यह चालू हो जाता है और आपका नया सर्विस वर्कर, क्लाइंट को कंट्रोल कर सकता है. यह ऐसे कामों के लिए सबसे सही समय है जो पुराने कर्मचारी के इस्तेमाल में होने के दौरान आप नहीं कर सकते थे, जैसे कि डेटाबेस माइग्रेट करना और कैश मेमोरी मिटाना.

ऊपर दिए गए डेमो में, मैंने उन कैश मेमोरी की सूची बनाई है जिनके होने की मुझे उम्मीद है. साथ ही, activate इवेंट में, मैं अन्य कैश मेमोरी को हटा देता हूं, जिससे पुरानी static-v1 कैश मेमोरी हट जाती है.

अगर event.waitUntil() को प्रॉमिस पास किया जाता है, तो यह फ़ंक्शनल इवेंट (fetch, push, sync वगैरह) को तब तक बफ़र करेगा, जब तक प्रॉमिस रिज़ॉल्व नहीं हो जाता. इसलिए, जब आपका fetch इवेंट ट्रिगर होता है, तो इवेंट चालू हो जाता है.

चेतावनी: कैश स्टोरेज का एपीआई, "ऑरिजिन स्टोरेज" होता है. जैसे, localStorage और IndexedDB. अगर आपकी ओर से एक ही ऑरिजिन पर कई साइटें चलाई जा रही हैं (उदाहरण के लिए, yourname.github.io/myapp), तो ध्यान रखें कि अपनी दूसरी साइटों की कैश मेमोरी न मिटाएं. इससे बचने के लिए, कैश मेमोरी के नामों को मौजूदा साइट के नाम से पहले कोई प्रीफ़िक्स दें. उदाहरण के लिए, myapp-static-v1. कैश को तब तक न छुएं, जब तक वे myapp- से शुरू न हों.

इंतज़ार का चरण छोड़ें

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

इससे आपका सर्विस वर्कर, मौजूदा सक्रिय वर्कर को बाहर निकाल देता है और इंतज़ार के चरण में आते ही खुद को चालू कर देता है (या अगर यह पहले से ही इंतज़ार के चरण में है, तो तुरंत खुद को चालू कर लेता है). इससे नहीं कि आपके वर्कर, इंस्टॉल करना छोड़ें, बस इंतज़ार करना पड़ता है.

skipWaiting() पर कॉल करने से कोई फ़र्क़ नहीं पड़ता, बस इंतज़ार करना पड़ रहा हो या कॉल करने से पहले. इसे install इवेंट में कॉल करना आम बात है:

self.addEventListener('install', event => {
  self.skipWaiting();

  event.waitUntil(
    // caching etc
  );
});

लेकिन हो सकता है कि आप इसे सर्विस वर्कर को postMessage() के नतीजे के रूप में कॉल करना चाहें. जैसे, आपको उपयोगकर्ता इंटरैक्शन को skipWaiting() फ़ॉलो करना है.

यहां एक डेमो दिया गया है, जिसमें skipWaiting() का इस्तेमाल किया गया है. यहां आपको एक गाय की ऐसी तस्वीर दिखनी चाहिए जहां जाने की ज़रूरत न हो. clients.claim() की तरह यह एक रेस है. इसलिए, आपको गाय सिर्फ़ तब दिखेगी, जब नया सर्विस वर्कर, पेज के इमेज लोड होने से पहले फ़ेच, इंस्टॉल, और चालू हो जाए.

चेतावनी: skipWaiting() का मतलब है कि आपके नए सर्विस वर्कर के पास उन पेजों को कंट्रोल करने की सुविधा है जो पुराने वर्शन से लोड किए गए थे. इसका मतलब है कि आपके पेज के कुछ फ़ेच, आपके पुराने सर्विस वर्कर की ओर से मैनेज किए जाएंगे, लेकिन आपका नया सर्विस वर्कर बाद में फ़ेच किए जाने की प्रक्रिया को हैंडल करेगा. अगर इससे चीज़ें टूट सकती हैं, तो skipWaiting() का इस्तेमाल न करें.

मैन्‍युअल अपडेट

जैसा कि मैंने पहले बताया, नेविगेशन और फ़ंक्शनल इवेंट के बाद ब्राउज़र अपने-आप अपडेट की जांच करता है, लेकिन आप उन्हें मैन्युअल रूप से भी ट्रिगर कर सकते हैं:

navigator.serviceWorker.register('/sw.js').then(reg => {
  // sometime later…
  reg.update();
});

अगर आपको लगता है कि उपयोगकर्ता आपकी साइट को फिर से लोड किए बिना लंबे समय तक इस्तेमाल करता रहेगा, तो हो सकता है कि आप किसी अंतराल (जैसे कि हर घंटे) पर update() को कॉल करना चाहें.

अपने सर्विस वर्कर स्क्रिप्ट का यूआरएल बदलने से बचें

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

इससे आपको इस तरह की समस्या आ सकती है:

index.html, sw-v1.js को सर्विस वर्कर के तौर पर रजिस्टर करता है.
sw-v1.js कैश मेमोरी में सेव किया जाता है और index.html को काम करता है, ताकि यह ऑफ़लाइन मोड में काम करे.
index.html को अपडेट किया जाता है, ताकि यह आपके नए और शानदार sw-v2.js को रजिस्टर कर सके.

अगर ऊपर दिया गया तरीका इस्तेमाल किया जाता है, तो उपयोगकर्ता को कभी भी sw-v2.js नहीं मिलेगा, क्योंकि sw-v1.js अपनी कैश मेमोरी से index.html के पुराने वर्शन को उपलब्ध करा रहा है. आपने खुद को ऐसी स्थिति में रखा है जहां अपने सर्विस वर्कर को अपडेट करने के लिए, आपको अपने सर्विस वर्कर को अपडेट करना होगा. ह्यू.

हालांकि, ऊपर दिए गए डेमो में, मैंने सर्विस वर्कर का यूआरएल बदल दिया है. डेमो के लिए, अलग-अलग वर्शन के बीच स्विच किया जा सकता है. मैं प्रोडक्शन में ऐसा नहीं करूंगी.

गेम को आसानी से डेवलप करना

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

फिर से लोड करने पर अपडेट

यह मुझे सबसे ज़्यादा पसंद है.

DevTools 'फिर से लोड होने पर अपडेट' दिखा रहा है

इससे, लाइफ़साइकल बदल जाती है, ताकि डेवलपर उसे आसानी से इस्तेमाल कर सके. हर नेविगेशन:

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

इसका मतलब है कि आपको दो बार फिर से लोड किए बिना या टैब को बंद किए बिना, हर नेविगेशन पर अपडेट मिलेंगे. इसमें रीफ़्रेश भी शामिल है.

इंतज़ार करना छोड़ें

अगर आपके यहां कोई वर्कर इंतज़ार कर रहा है, तो उसे तुरंत "ऐक्टिव" कैटगरी में प्रमोट करने के लिए, DevTools में "इंतज़ार करना छोड़ें" बटन दबाएं.

Shift-फिर से लोड करें

अगर पेज को ज़बरदस्ती फिर से लोड (shift-reload) किया जाता है, तो यह सर्विस वर्कर को पूरी तरह से बायपास कर देता है. यह बेकाबू हो जाएगा. यह सुविधा स्पेसिफ़िकेशन में बताई गई है. इसलिए, यह ऐसे ब्राउज़र में काम करती है जो सर्विस वर्कर के साथ काम करते हैं.

रखरखाव से जुड़े अपडेट

सर्विस वर्कर को एक्सटेंसिबल वेब के हिस्से के तौर पर डिज़ाइन किया गया था. इसका मकसद यह है कि ब्राउज़र डेवलपर के तौर पर हम यह स्वीकार करें कि वेब डेवलपमेंट में हम वेब डेवलपर से बेहतर नहीं हैं. इसलिए, हमें हमारे जैसे पैटर्न का इस्तेमाल करके खास समस्या को हल करने वाले नैरो हाई-लेवल एपीआई नहीं देने चाहिए. इसके बजाय, यह आपको ब्राउज़र की सारी जानकारी का ऐक्सेस दे देता है, ताकि यह आपके उपयोगकर्ताओं के लिए सबसे बेहतर तरीके से काम किया जा सके.

इसलिए, ज़्यादा से ज़्यादा पैटर्न चालू करने के लिए, अपडेट की पूरी साइकल देखी जा सकती है:

navigator.serviceWorker.register('/sw.js').then(reg => {
  reg.installing; // the installing worker, or undefined
  reg.waiting; // the waiting worker, or undefined
  reg.active; // the active worker, or undefined

  reg.addEventListener('updatefound', () => {
    // A wild service worker has appeared in reg.installing!
    const newWorker = reg.installing;

    newWorker.state;
    // "installing" - the install event has fired, but not yet complete
    // "installed"  - install complete
    // "activating" - the activate event has fired, but not yet complete
    // "activated"  - fully active
    // "redundant"  - discarded. Either failed install, or it's been
    //                replaced by a newer version

    newWorker.addEventListener('statechange', () => {
      // newWorker.state has changed
    });
  });
});

navigator.serviceWorker.addEventListener('controllerchange', () => {
  // This fires when the service worker controlling this page
  // changes, eg a new worker has skipped waiting and become
  // the new active worker.
});

लाइफ़साइकल हमेशा चलता रहती है

जैसा कि आप देख सकते हैं, यह सर्विस वर्कर के लाइफ़साइकल को समझने पर अच्छा काम करता है. इस समझ के साथ, सर्विस वर्कर का व्यवहार ज़्यादा तार्किक और कम रहस्यमयी होना चाहिए. इस जानकारी से आपको अपने सर्विस वर्कर को डिप्लॉय और अपडेट करने पर, ज़्यादा भरोसा होगा.