सर्विस वर्कर का लाइफ़साइकल अनुमानित इंस्टॉलेशन और अपडेट प्रोसेस को पक्का करता है, लेकिन इससे लोकल डेवलपमेंट साइकल में थोड़ा सुधार हो सकता है.
सामान्य लोकल डेवलपमेंट साइकल के दौरान, डेवलपर बदलावों को टेक्स्ट एडिटर में सेव करते हैं. इसके बाद, बदलावों की पुष्टि करने के लिए ब्राउज़र पर स्विच करते हैं और यह प्रोसेस दोहराई जाती है. जब सर्विस वर्कर अलग-अलग होता है, तब यह प्रक्रिया काफ़ी हद तक एक जैसी होती है. हालांकि, डेवलपर की उम्मीद और ब्राउज़र की परफ़ॉर्मेंस में फ़र्क़ हो सकता है.
लोकल डेवलपमेंट से जुड़े अपवाद
आम तौर पर, सर्विस वर्कर एपीआई सिर्फ़ उन पेजों पर उपलब्ध होते हैं जो एचटीटीपीएस पर खुलते हैं. हालांकि, इस नियम के कुछ अपवाद भी हैं, जहां वे एचटीटीपी पर उपलब्ध हो सकते हैं.
इनमें से एक ध्यान देने लायक अपवाद localhost से ज़्यादा उम्र के पेजों के लिए है. ये पेज लोकल डेवलपमेंट के लिए अच्छी तरह काम करते हैं.
हालांकि, डेवलपर के लिए किसी होस्ट फ़ाइल में localhost के अलावा लोकल होस्टनेम तय करना कोई असामान्य बात नहीं है.
लोकल डेवलपमेंट सिस्टम में यह तब ज़रूरी होता है, जब एक से ज़्यादा प्रोजेक्ट के लिए अलग-अलग होस्टनेम की ज़रूरत होती है.
इन मामलों में, खुद हस्ताक्षर किए गए सर्टिफ़िकेट का प्रावधान करने से काम हो जाएगा.
एक ज़्यादा आसान समाधान, ब्राउज़र को सर्विस वर्कर टेस्टिंग के लिए अपवाद बनाने का निर्देश देना है.
Chrome के लिए, chrome://flags/#unsafely-treat-insecure-origin-as-secure पर नेविगेट करें और असुरक्षित ऑरिजिन को सुरक्षित ऑरिजिन के तौर पर सेट करें.
Firefox, about:config में devtools.serviceWorkers.testing.enabled सेटिंग के ज़रिए असुरक्षित ऑरिजिन पर सर्विस वर्कर की जांच करने का तरीका ऑफ़र करता है.
सर्विस वर्कर के लिए डेवलपमेंट से जुड़ी सहायता
किसी सर्विस वर्कर के साथ मिलकर काम करने के बाद, उस इलाके में कुछ बदलाव हो सकते हैं, जिससे लोगों को अनचाहे व्यवहार लग सकते हैं.
उदाहरण के लिए, मान लें कि बिना वर्शन वाली स्टैटिक ऐसेट के लिए, सिर्फ़ कैश मेमोरी में सेव की गई रणनीति है या पहले से कैश मेमोरी में सेव किए गए "आप ऑफ़लाइन हैं" पेज के लिए, बदलाव करने के बाद फिर से लोड होने पर अपडेट हो सकता है.
ऐसा लगता है कि उन एसेट का पुराना वर्शन हमेशा Cache इंस्टेंस से दिखाया जाता है. इसलिए, ऐसा लगता है कि वे कभी अपडेट नहीं होते!
निराश होने की वजह से, सर्विस वर्कर सिर्फ़ वही कर रहा है जिसके लिए इसे बनाया गया था. हालांकि, टेस्टिंग को आसान बनाने के कुछ तरीके भी हैं.
सर्विस वर्कर को टेस्ट करने का सबसे असरदार तरीका है, निजी ब्राउज़िंग विंडो पर भरोसा करना. जैसे, Chrome की गुप्त विंडो या Firefox की निजी ब्राउज़िंग सुविधा.
हर बार निजी ब्राउज़िंग विंडो खोलने पर, आपको नए सिरे से शुरुआत करनी होती है.
कोई सक्रिय सर्विस वर्कर नहीं है और कोई खुले Cache इंस्टेंस नहीं हैं. इस तरह की जांच का रूटीन यह है:
- कोई निजी ब्राउज़िंग विंडो खोलें.
- सर्विस वर्कर रजिस्टर करने वाले पेज पर जाएं.
- पुष्टि करें कि सर्विस वर्कर आपकी उम्मीद के मुताबिक काम करता है या नहीं.
- गुप्त विंडो बंद करें.
- दोहराएं.
इस प्रोसेस में आप पूरी लगन के साथ सर्विस वर्कर के लाइफ़साइकल की नकल करते हैं.
Chrome DevTools ऐप्लिकेशन पैनल में उपलब्ध अन्य टेस्टिंग टूल से मदद मिल सकती है. हालांकि, सर्विस वर्कर के लाइफ़साइकल में कुछ तरीकों से बदलाव किए जा सकते हैं.
ऐप्लिकेशन पैनल में सर्विस वर्कर लेबल वाला एक सबपैनल होता है, जो मौजूदा पेज के लिए सक्रिय सर्विस वर्कर को दिखाता है. हर चालू सर्विस वर्कर को मैन्युअल तरीके से अपडेट किया जा सकता है या रजिस्ट्रेशन रद्द भी किया जा सकता है. सबसे ऊपर तीन टॉगल भी हैं, जो डेवलपमेंट में मदद करते हैं.
- ऑफ़लाइन, ऑफ़लाइन होने की स्थितियों को सिम्युलेट करता है. इससे यह जांच करने में मदद मिलती है कि कोई सक्रिय सर्विस वर्कर ऑफ़लाइन कॉन्टेंट दे रहा है या नहीं.
- फिर से लोड करने पर अपडेट: टॉगल किए जाने पर, जब भी पेज फिर से लोड होता है, तो यह मौजूदा सर्विस वर्कर को फिर से फ़ेच और बदल देता है.
- नेटवर्क के लिए बायपास, टॉगल करने पर, किसी सर्विस वर्कर के
fetchइवेंट में मौजूद किसी भी कोड को गच्चा देता है और हमेशा नेटवर्क से कॉन्टेंट फ़ेच करता है.
ये मददगार टॉगल हैं, खास तौर पर नेटवर्क के लिए बायपास, जब आप किसी सक्रिय सर्विस वर्कर के साथ कोई प्रोजेक्ट बनाते हैं, तो यह बढ़िया होता है, लेकिन हम यह भी पक्का करना चाहते हैं कि सर्विस वर्कर के बिना भी अनुभव उम्मीद के मुताबिक काम करे.
Firefox के डेवलपर टूल में भी इससे मिलता-जुलता ऐप्लिकेशन पैनल है. हालांकि, यह फ़ंक्शन सिर्फ़ यह दिखाता है कि कौनसे सर्विस वर्कर इंस्टॉल किए गए हैं. इसके अलावा, यह फ़ंक्शन किसी चालू सर्विस वर्कर को मौजूदा पेज के लिए मैन्युअल तरीके से रजिस्ट्रेशन से हटाने की सुविधा तक ही सीमित है. यह उतना ही मददगार है, लेकिन लोकल डेवलपमेंट साइकल में इसके लिए ज़्यादा मैन्युअल मेहनत करने की ज़रूरत होती है.
शिफ़्ट करें और फिर से लोड करें
रीफ़्रेश करने पर अपडेट होने या नेटवर्क के लिए बायपास फ़ंक्शन की ज़रूरत के बिना, किसी चालू सर्विस वर्कर के साथ स्थानीय तौर पर डेवलप करते समय, Shift को दबाकर रखना और रीफ़्रेश बटन दबाना भी फ़ायदेमंद होता है.
इसे ज़बरदस्ती रीफ़्रेश कहा जाता है, जो नेटवर्क के लिए एचटीटीपी कैश मेमोरी को बायपास करता है. जब कोई सर्विस वर्कर सक्रिय होता है, तो एक फ़ोर्स्ड रीफ़्रेश भी सर्विस वर्कर को पूरी तरह से बायपास कर देगा.
यह फ़ंक्शन उस समय बढ़िया काम करता है, जब इस बात को लेकर अनिश्चितता हो कि कैश मेमोरी की कोई खास रणनीति उम्मीद के मुताबिक काम कर रही है या नहीं. साथ ही, नेटवर्क से सब कुछ हासिल करना मददगार होता है, ताकि सर्विस वर्कर के साथ और उसके बिना व्यवहार की तुलना की जा सके. बेहतर होगा कि यह एक तय व्यवहार है. इसलिए, सर्विस वर्कर का इस्तेमाल करने वाले सभी ब्राउज़र इसे देख पाएंगे.
कैश मेमोरी में मौजूद कॉन्टेंट की जांच करना
अगर कैश मेमोरी की जांच नहीं की जा सकती, तो यह पता लगाना मुश्किल है कि कैश मेमोरी की रणनीति सही तरीके से काम कर रही है या नहीं.
ठीक है, कैश की जांच कोड में की जा सकती है, लेकिन यह ऐसी प्रोसेस है जिसमें डीबगर और/या console स्टेटमेंट शामिल होते हैं. ऐसा तब होता है, जब कोई विज़ुअल टूल इस काम के लिए बेहतर हो.
Chrome DevTools के ऐप्लिकेशन पैनल में, Cache इंस्टेंस के कॉन्टेंट की जांच करने के लिए एक सब-पैनल मौजूद है.
यह सब-पैनल, सर्विस वर्कर के डेवलपमेंट को आसान बनाता है. इसकी मदद से ये काम किए जाते हैं:
Cacheइंस्टेंस के नाम देखें.- कैश मेमोरी में सेव की गई एसेट के रिस्पॉन्स के मुख्य हिस्से और उनसे जुड़े रिस्पॉन्स हेडर की जांच करने की सुविधा.
- कैश मेमोरी से एक या उससे ज़्यादा आइटम हटाएं या सभी
Cacheइंस्टेंस मिटाएं.
इस ग्राफ़िकल यूज़र इंटरफ़ेस की मदद से, सर्विस वर्कर कैश मेमोरी की जांच करना आसान हो जाता है. इससे यह देखा जा सकता है कि आइटम को सर्विस वर्कर कैश मेमोरी से जोड़ा गया है, अपडेट किया गया है या पूरी तरह से हटाया गया है. Firefox मिलती-जुलती सुविधाओं वाला अपना कैश व्यूअर भी देता है. हालांकि, यह एक अलग स्टोरेज पैनल में होता है.
स्टोरेज कोटा को सिम्युलेट किया जा रहा है
बहुत सारी बड़ी स्टैटिक एसेट (जैसे हाई-रिज़ॉल्यूशन इमेज) वाली वेबसाइटों में, स्टोरेज कोटा पूरा हो सकता है. ऐसा होने पर, ब्राउज़र, कैश मेमोरी से वे आइटम हटा देगा जो पुराना लगता है. इसके अलावा, नई एसेट बनाने के लिए इस तरह के आइटम को इस लायक बना देता है कि वे इस लायक भी न रहें.
सर्विस वर्कर के विकास में स्टोरेज कोटा से जुड़ी समस्या शामिल होनी चाहिए. इसके अलावा, वर्कबॉक्स इस प्रोसेस को खुद मैनेज करने की तुलना में ज़्यादा आसान बना देता है. हालांकि, Workbox के साथ या उसके बिना, कैश मैनेजमेंट लॉजिक की जांच करने के लिए कस्टम स्टोरेज कोटा को सिम्युलेट करना एक अच्छा आइडिया हो सकता है.
Chrome के DevTools के ऐप्लिकेशन पैनल में एक स्टोरेज सबपैनल है, जो यह जानकारी देता है कि पेज ने मौजूदा स्टोरेज कोटा के कितने हिस्से का इस्तेमाल किया है. यह कस्टम कोटा को मेगाबाइट में तय करने की अनुमति भी देता है. इसके लागू होने पर, Chrome कस्टम स्टोरेज कोटा को लागू करेगा, ताकि इसकी जांच की जा सके.
खास बात यह है कि इस सबपैनल में साइट का डेटा मिटाएं बटन भी होता है. इसके अलावा, इसमें संबंधित चेकबॉक्स की पूरी सूची भी होती है, जिसमें बताया जाता है कि बटन पर क्लिक करने पर कौनसा डेटा मिटाया जा सकता है.
इन आइटम में सभी खुले Cache इंस्टेंस हैं और पेज को कंट्रोल करने वाले किसी भी सक्रिय सर्विस वर्कर का रजिस्ट्रेशन रद्द करने की सुविधा है.
आसान डेवलपमेंट, बेहतर उत्पादकता
जब डेवलपर पर कोई बोझ नहीं होता है, तो वे ज़्यादा आत्मविश्वास के साथ काम कर सकते हैं और ज़्यादा प्रॉडक्टिविटी कर सकते हैं. सर्विस वर्कर के साथ स्थानीय विकास में बारीकियां हो सकती हैं, लेकिन यह दर्दनाक नहीं होना चाहिए. इन सुझावों और तरकीबों की मदद से, किसी सक्रिय सर्विस वर्कर के साथ ऐप्लिकेशन डेवलप करने पर ज़्यादा पारदर्शी और अनुमान लगाए जा सकते हैं. इससे डेवलपर को बेहतर अनुभव मिलेगा.