वर्कबॉक्स की मदद से, पहले से कैश मेमोरी में सेव करने की सुविधा

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

generateSW की मदद से, पहले से कैश मेमोरी में सेव किया जा रहा है

generateSW, Workbox में ऐसेट को पहले से कैश मेमोरी में सेव करने का सबसे आसान तरीका है. generateSW के बारे में याद रखने वाली सबसे बड़ी बात यह है कि आप अपना सर्विस वर्कर नहीं लिख रहे हैं—आप Workbox से अपने लिए एक जनरेट करने के लिए कह रहे हैं. हालांकि, कॉन्फ़िगरेशन के अलग-अलग विकल्पों की मदद से, इसके व्यवहार में बदलाव किया जा सकता है.

generateSW डिफ़ॉल्ट रूप से अलग-अलग काम करता है. यह इस बात पर निर्भर करता है कि किस बिल्ड टूल का इस्तेमाल किया जा रहा है. workbox-webpack-plugin का इस्तेमाल करते समय, आपको कॉन्फ़िगरेशन के लिए कोई विकल्प तय करने की ज़रूरत नहीं है. डिफ़ॉल्ट रूप से, प्लगिन अपने डिपेंडेंसी ग्राफ़ में शामिल हर वेबपैक की पहले से कैश मेमोरी में सेव कर लेता है. साथ ही, output.path की तय की गई डायरेक्ट्री में service-worker.js नाम का सर्विस वर्कर लिखता है

वहीं दूसरी ओर, workbox-build या workbox-cli का इस्तेमाल करने पर, लोकल फ़ाइल सिस्टम से पढ़ी गई सिर्फ़ एचटीएमएल, सीएसएस, और JavaScript ऐसेट को डिफ़ॉल्ट रूप से पहले से कैश मेमोरी में सेव किया जाएगा. कॉन्फ़िगरेशन के हिसाब से, आपको पहले से कैश मेमोरी में सेव करने की सुविधा चालू करने के लिए, generateSW कॉन्फ़िगरेशन में swDest और globDirectory विकल्प को तय करना होगा. हो सकता है कि आपको सर्विस वर्कर के व्यवहार पर असर डालने वाले अतिरिक्त विकल्पों को कॉन्फ़िगर करना पड़े. इसलिए, दस्तावेज़ देखें.

चेतावनी: अगर आपके प्रोजेक्ट में कई ऐसेट को डिफ़ॉल्ट सेटिंग की मदद से, पहले से कैश मेमोरी में सेव किया गया है, तो generateSW कॉन्फ़िगरेशन में संसाधनों को शामिल न करने के लिए, ग्लोब के विकल्पों में से किसी एक का इस्तेमाल करें. workbox-webpack-plugin का इस्तेमाल करते समय, प्लगिन के GenerateSW दस्तावेज़ को देखकर जानें कि अनचाही ऐसेट को पहले से कैश मेमोरी में सेव होने से कैसे रोका जा सकता है. ऐसा इसलिए, क्योंकि इसका कॉन्फ़िगरेशन generateSW से अलग होता है.

injectManifest की मदद से, पहले से कैश मेमोरी में सेव किया जा रहा है

injectManifest का इस्तेमाल करना, generateSW जितना आसान नहीं है. हालांकि, आपको सुविधाएं इस्तेमाल करने में आसानी के लिए कोई छूट मिल रही है. जहां generateSW आपके लिए पूरा सर्विस वर्कर मैनेज करता है, injectManifest उस सर्विस वर्कर को लेता है जिसे आपने सोर्स के तौर पर लिखा है. साथ ही, वह प्रीकैश मेमोरी के लिए यूआरएल की सूची इंजेक्ट करता है, जबकि आपके बाकी सर्विस वर्कर में कोई बदलाव नहीं होता.

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

ध्यान दें: अगर आपको injectManifest स्ट्रिंग को बदलकर self.__WB_MANIFEST से अलग स्ट्रिंग को बदलना है, तो इसके कॉन्फ़िगरेशन में injectionPoint विकल्प के बारे में बताएं.

प्रीकैश मेनिफ़ेस्ट में एंट्री की सूची में, कॉन्फ़िगरेशन के अन्य विकल्पों का इस्तेमाल किया जा सकता है.

चेतावनी: generateSW के उलट, injectManifest आपके लिए वर्कबॉक्स रनटाइम को अपने-आप बंडल नहीं करेगा! अगर आपको injectManifest का इस्तेमाल करने वाले मामलों में इसे मैनेज करने का तरीका जानना है, तो नीचे दी गई तुलना के साथ-साथ देखें.

अगल-बगल में तुलना

generateSW और injectManifest तरीकों के इस्तेमाल की तुलना करने के लिए, नीचे दिए गए हर टैब पर क्लिक करें:

generateSW एक सर्विस वर्कर जनरेट करता है, इसलिए आपको सिर्फ़ कॉन्फ़िगरेशन तय करना होगा. यहां एक उदाहरण दिया गया है, जिसमें workbox-build का इस्तेमाल किया गया है:

// build-sw.js
import {generateSW} from 'workbox-build';

generateSW({
  swDest: './dist/sw.js',
  globDirectory: './dist',
  globPatterns: [
    '**/*.js',
    '**/*.css',
    '**/*.svg'
  ]
});

इसके बाद सर्विस वर्कर को नोड के साथ कमांड लाइन पर बनाया जा सकता है:

node build-sw.js

injectManifest को सोर्स सर्विस वर्कर की ज़रूरत होती है. इसलिए, इस उदाहरण में सोर्स सर्विस वर्कर फ़ाइल की ज़रूरत है. अगर सिर्फ़ प्रीकैशिंग की ज़रूरत है, तो वह इनपुट सर्विस वर्कर कुछ इस तरह से दिखेगा:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(self.__WB_MANIFEST);

self.__WB_MANIFEST स्ट्रिंग को नोट करें. यह एक प्लेसहोल्डर है, जिसे वर्कबॉक्स प्री-कैश मेमोरी मेनिफ़ेस्ट से बदल देता है. इस्तेमाल के इस उदाहरण के लिए, नीचे एक मान्य कॉन्फ़िगरेशन दिया गया है:

// build-sw.js
import {injectManifest} from 'workbox-build';

injectManifest({
  swSrc: './src/sw.js',
  swDest: './dist/sw.js',
  globDirectory: './dist',
  globPatterns: [
    '**/*.js',
    '**/*.css',
    '**/*.svg'
  ]
});

अगर आपकी कुछ मुश्किल ज़रूरतें हैं, जैसे कि बेहतर रूटिंग, पसंद के मुताबिक कैश मेमोरी में सेव करने की रणनीतियां या ऐसी दूसरी चीज़ें जो generateSW की ओर से उपलब्ध विकल्पों में शामिल नहीं हैं, तो injectManifest का इस्तेमाल करना बेहतर रहेगा.

चेतावनी: ऊपर दिए गए उदाहरण यह मानकर दिए गए हैं कि आप ऐसे नोड एनवायरमेंट में हैं जो बिल्ड स्टेप के बिना मूल रूप से ES मॉड्यूल के साथ काम करता है. नोड के वर्शन 16 से पहले के वर्शन में, आपको ES मॉड्यूल के लिए सहायता चालू करने के लिए एक फ़्लैग सेट करना पड़ सकता है या module.exports का इस्तेमाल करके CommonJS सिमैंटिक पर भरोसा करना पड़ सकता है.

नतीजा

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