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

Jake Archibald

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

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

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

इंटेंट

लाइफ़साइकल का मकसद यह है:

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

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

चेतावनी: उपयोगकर्ताओं को डेटा का नुकसान पसंद नहीं आता. इससे उन्हें बहुत दुख होता है.

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

संक्षेप में:

• 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, कंसोल में और ऐप्लिकेशन टैब के सर्विस वर्कर सेक्शन में गड़बड़ी दिखाते हैं:

इंस्टॉल करें

सर्विस वर्कर को मिलने वाला पहला इवेंट 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 के "ऐप्लिकेशन" टैब में, नए सर्विस वर्कर को इंतज़ार करते हुए देखा जा सकता है:

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

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

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

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

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

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

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

डेवलपमेंट को आसान बनाना

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

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

यह मेरा पसंदीदा है.

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

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

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

इंतज़ार न करें

अगर कोई वर्कर इंतज़ार कर रहा है, तो DevTools में "skip waiting" को चुनकर, उसे तुरंत "active" के तौर पर प्रमोट किया जा सकता है.

Shift-रीलोड

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

अपडेट मैनेज करना

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

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

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.
});

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

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