सर्विस वर्कर से जुड़े अपडेट तुरंत मैनेज करना

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

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

आपके पेज पर डाला जाने वाला कोड

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

<!-- This script tag uses JavaScript modules, so the proper `type` attribute value is required -->
<script type="module">
  // This code sample uses features introduced in Workbox v6.
  import {Workbox} from 'https://storage.googleapis.com/workbox-cdn/releases/6.4.1/workbox-window.prod.mjs';

  if ('serviceWorker' in navigator) {
    const wb = new Workbox('/sw.js');
    let registration;

    const showSkipWaitingPrompt = async (event) => {
      // Assuming the user accepted the update, set up a listener
      // that will reload the page as soon as the previously waiting
      // service worker has taken control.
      wb.addEventListener('controlling', () => {
        // At this point, reloading will ensure that the current
        // tab is loaded under the control of the new service worker.
        // Depending on your web app, you may want to auto-save or
        // persist transient state before triggering the reload.
        window.location.reload();
      });

      // When `event.wasWaitingBeforeRegister` is true, a previously
      // updated service worker is still waiting.
      // You may want to customize the UI prompt accordingly.

      // This code assumes your app has a promptForUpdate() method,
      // which returns true if the user wants to update.
      // Implementing this is app-specific; some examples are:
      // https://open-ui.org/components/alert.research or
      // https://open-ui.org/components/toast.research
      const updateAccepted = await promptForUpdate();

      if (updateAccepted) {
        wb.messageSkipWaiting();
      }
    };

    // Add an event listener to detect when the registered
    // service worker has installed but is waiting to activate.
    wb.addEventListener('waiting', (event) => {
      showSkipWaitingPrompt(event);
    });

    wb.register();
  }
</script>

अगर वे स्वीकार करते हैं, तो messageSkipWaiting() इंतज़ार कर रहे सर्विस वर्कर को self.skipWaiting() शुरू करने के लिए कहता है. इसका मतलब है कि यह चालू हो जाएगा. चालू होने के बाद, नए सर्विस वर्कर किसी भी मौजूदा क्लाइंट को कंट्रोल करेंगे. यह workbox-window में controlling इवेंट ट्रिगर करेगा. ऐसा होने पर मौजूदा पेज, पहले से कैश मेमोरी में सेव की गई सभी एसेट के सबसे नए वर्शन का इस्तेमाल करके फिर से लोड हो जाता है. साथ ही, अपडेट किए गए सर्विस वर्कर में मिले, नए रूटिंग लॉजिक का भी इस्तेमाल किया जाता है.

आपके सर्विस वर्कर में डाला जाने वाला कोड

पेज पर पिछले सेक्शन से कोड मिलने के बाद, आपको अपने सर्विस वर्कर में कुछ कोड जोड़ना होगा. इससे यह पता किया जा सकता है कि इंतज़ार के चरण को कब छोड़ना है. अगर आप workbox-build से generateSW का इस्तेमाल कर रहे हैं और आपका skipWaiting विकल्प false (डिफ़ॉल्ट) पर सेट है, तो आप इसका इस्तेमाल कर सकते हैं, क्योंकि नीचे दिया गया कोड आपकी जनरेट की गई सर्विस वर्कर फ़ाइल में अपने-आप शामिल हो जाएगा.

अगर आप खुद का सर्विस वर्कर लिख रहे हैं—injectManifest मोड में Workbox के बिल्ड टूल में से किसी एक के साथ—तो आपको खुद नीचे दिया गया कोड जोड़ना होगा:

addEventListener('message', (event) => {
  if (event.data && event.data.type === 'SKIP_WAITING') {
    self.skipWaiting();
  }
});

यह workbox-window से सर्विस वर्कर को भेजे गए SKIP_WAITING के type मान वाले मैसेज को सुनेगा और ऐसा होने पर self.skipWaiting() को कॉल करेगा. इस मैसेज को भेजने के लिए, workbox-window के messageSkipWaiting() तरीके का इस्तेमाल किया गया है, जैसा कि पुराने कोड सैंपल में दिखाया गया था.

क्या आपको कोई प्रॉम्प्ट दिखाना है?

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

  • आप प्री-कैशिंग का बड़े पैमाने पर इस्तेमाल करते हैं. अगर स्टैटिक ऐसेट की बात करें, तो नेविगेशन के अनुरोधों के लिए नेटवर्क-फ़र्स्ट या सिर्फ़ नेटवर्क के लिए रणनीति का इस्तेमाल करने पर, आपको बाद में समस्याएं आ सकती हैं. हालांकि, स्टैटिक ऐसेट को लेज़ी-लोड के तौर पर इस्तेमाल किया जाता है. इसकी वजह से ऐसा हो सकता है कि वर्शन वाली एसेट बदल जाएं और किसी सर्विस वर्कर ने उन्हें पहले से कैश मेमोरी में न रखा हो. यहां फिर से लोड करने का बटन देने से, अनचाहे व्यवहार से बचा जा सकता है.
  • अगर पहले से कैश मेमोरी में सेव किया गया एचटीएमएल कोड दिखाया जा रहा है. इस स्थिति में, आपको सर्विस वर्कर से जुड़े अपडेट के लिए, फिर से लोड करने का बटन उपलब्ध कराने पर जोरदार विचार करना चाहिए. ऐसा इसलिए, क्योंकि उस एचटीएमएल में किए गए अपडेट की पहचान तब तक नहीं की जा सकेगी, जब तक अपडेट किए गए सर्विस वर्कर को कंट्रोल नहीं किया जाता.
  • अगर आपने ज़्यादातर रनटाइम कैशिंग का इस्तेमाल नहीं किया है. रनटाइम के दौरान संसाधनों को कैश मेमोरी में सेव करते समय, आपको लोगों को यह बताने की ज़रूरत नहीं है कि उन्हें फिर से लोड करना चाहिए. वर्शन वाली एसेट में बदलाव होने पर, उन्हें रनटाइम के दौरान कैश मेमोरी में सेव कर दिया जाएगा. ऐसा यह मानते हुए किया जाएगा कि नेविगेशन के अनुरोध, नेटवर्क या सिर्फ़ नेटवर्क के इस्तेमाल की रणनीति का इस्तेमाल करते हैं.
  • stale-time-reverify रणनीति का इस्तेमाल करते समय, उपयोगकर्ताओं को सर्विस वर्कर से जुड़े अपडेट की सूचना देने के लिए, workbox-broadcast-update मॉड्यूल का इस्तेमाल किया जा सकता है.

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