अब तक, यह दस्तावेज़ प्रीकैश करने पर बड़ा काम करता है, अक्सर generateSW
और injectManifest
बिल्ड टूल का इस्तेमाल करता है. हालांकि, आपके सर्विस वर्कर में प्री-कैशिंग लॉजिक शामिल करने की कई अच्छी वजहें हैं, फिर भी आपको Workbox का इस्तेमाल करने के लिए, प्री-कैशिंग का इस्तेमाल करने की ज़रूरत नहीं है.
शायद आपके प्रोजेक्ट को सिर्फ़ रनटाइम को कैश मेमोरी में सेव करने की ज़रूरत हो या हो सकता है कि आपको वेब पुश जैसे सर्विस वर्कर एपीआई को बेहतर तरीके से इंटिग्रेट करने की ज़रूरत हो. ऐसे मामलों में, आपको Workbox के बिल्ड टूल का इस्तेमाल नहीं करना होगा और इस लेख में इन बातों के बारे में बताया गया है.
बंडलर का इस्तेमाल करते समय
बंडलर वेब डेवलपमेंट लैंडस्केप में प्रमुख होते हैं और इस बात की काफ़ी संभावना है कि आपका प्रोजेक्ट उनका इस्तेमाल कर रहा हो. अगर ऐसा है, तो यह जानना ज़रूरी है कि अगर आप कुछ भी प्री-कैश नहीं कर रहे हैं, तो आपको किसी बंडलर प्लगिन (जैसे workbox-webpack-plugin
) का इस्तेमाल करने की ज़रूरत नहीं है. आप अपने सर्विस वर्कर को अपने ऐप्लिकेशन में एक अलग एंट्री पॉइंट मानेंगे.
अपने प्रोजेक्ट की सोर्स डायरेक्ट्री के रूट में, आपको एक सर्विस वर्कर बनाना होगा. साथ ही, आपके ऐप्लिकेशन के लिए ज़रूरी सभी Workbox मॉड्यूल का इस्तेमाल करना होगा. यहां प्रीकैशिंग के बिना एक उदाहरण दिया गया है, जो इसके बजाय अलग-अलग Cache
इंस्टेंस में नेविगेशन और इमेज एसेट अनुरोधों के लिए कैश मेमोरी की रणनीतियां सेट अप करता है:
// sw.js
import {NetworkFirst, CacheFirst} from 'workbox-strategies';
import {registerRoute, NavigationRoute, Route} from 'workbox-routing';
const navigationRoute = new NavigationRoute(new NetworkFirst({
cacheName: 'navigations'
}));
const imageAssetRoute = new Route(({request}) => {
return request.destination === 'image';
}, new CacheFirst({
cacheName: 'image-assets'
}));
registerRoute(navigationRoute);
registerRoute(imageAssetRoute);
यहां से, यह अपनी पसंद के बंडलर में एंट्री पॉइंट के तौर पर इस सर्विस वर्कर को तय करने की बात है. नीचे कुछ लोकप्रिय बंडलर में ऐसा करने के कुछ उदाहरण दिए गए हैं.
वेबपैक
webpack अपने entry
कॉन्फ़िगरेशन में एंट्री पॉइंट स्वीकार करता है. इस तरीके का इस्तेमाल करते समय कुछ बातों का ध्यान रखना ज़रूरी है:
- यह पक्का करने के लिए कि आपके सर्विस वर्कर के पास सबसे ज़्यादा संभावित दायरा हो, आपको इसे अपनी आउटपुट डायरेक्ट्री के रूट में आउटपुट बनाना होगा.
- आपको सर्विस वर्कर का वर्शन बदलना नहीं है, क्योंकि इसके अपडेट नए हैश जनरेट करेंगे. इसकी वजह से हो सकता है कि आपकी वेबसाइट पर कई सर्विस वर्कर डिप्लॉय किए जाएं.
ऊपर दी गई शर्तों को पूरा करने के लिए, output.filename
को एक फ़ंक्शन भेजा जा सकता है. यह यह जांच करता है कि प्रोसेस किया जा रहा मौजूदा एंट्री पॉइंट, सर्विस वर्कर एंट्री पॉइंट है या नहीं. ऐसा न होने पर, वर्शन वाली फ़ाइलें अपने सामान्य डेस्टिनेशन पर लिखी जाती हैं.
// webpack.config.js
import process from 'process';
const isProd = process.env.NODE_ENV === 'production';
export default {
mode: isProd ? 'production' : 'development',
context: process.cwd(),
entry: {
// Service worker entry point:
sw: './src/sw.js',
// Application entry point:
app: './src/index.js'
},
output: {
filename: ({runtime}) => {
// Check if the current filename is for the service worker:
if (runtime === 'sw') {
// Output a service worker in the root of the dist directory
// Also, ensure the output file name doesn't have a hash in it
return '[name].js';
}
// Otherwise, output files as normal
return 'js/[name].[contenthash:8].js';
},
path: './dist',
publicPath: '/',
clean: true
}
};
रोलअप
रोलअप और वेबपैक जैसी ही स्थिति है. हालांकि, इसमें एक से ज़्यादा एंट्री पॉइंट, अरे में एक्सपोर्ट किए गए अलग-अलग कॉन्फ़िगरेशन ऑब्जेक्ट के तौर पर बताए जाते हैं:
// rollup.config.js
import { nodeResolve } from '@rollup/plugin-node-resolve';
import replace from '@rollup/plugin-replace';
// Plugins common to both entry points
const plugins = [
nodeResolve(),
];
export default [
// Application entry point
{
input: './src/index.js',
output: {
dir: './dist/js',
format: 'esm'
},
plugins
},
// Service worker entry point
{
input: './src/sw.js',
output: {
file: './dist/sw.js',
format: 'iife'
},
plugins: [
...plugins,
// This @rollup/plugin-replace instance replaces process.env.NODE_ENV
// statements in the Workbox libraries to match your current environment.
// This changes whether logging is enabled ('development') or disabled ('production').
replace({
'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production')
})
]
}
];
ई-बिल्ड
esbuild एक आसान कमांड लाइन इंटरफ़ेस उपलब्ध कराता है:
npx esbuild ./src/sw.js --bundle --minify --outfile=./dist/sw.js
esbuild, page.env.NODE_ENV को डिफ़ॉल्ट रूप से 'डेवलपमेंट' से बदल देगा या काट-छांट करने की सुविधा को 'प्रोडक्शन' से बदल देगा.
workbox-sw
का इस्तेमाल करके, बंडलर के बिना
ऐसा भी हो सकता है कि आपका प्रोजेक्ट बंडलर का इस्तेमाल न करता हो. workbox-sw
आपके लिए आपके सर्विस वर्कर में किसी सीडीएन से Workbox रनटाइम लोड कर सकता है. साथ ही, अगर आप इसे importScripts
के साथ इंपोर्ट करते हैं, तो यह बिल्ड चरण के बिना भी लोड हो सकता है:
// sw.js
// Imports Workbox from the CDN. Note that "6.2.0" of the URL
// is the version of the Workbox runtime.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');
const navigationRoute = new workbox.routing.NavigationRoute(new workbox.strategies.NetworkFirst({
cacheName: 'navigations'
}));
const imageAssetRoute = new workbox.routing.Route(({request}) => {
return request.destination === 'image';
}, new workbox.strategies.CacheFirst({
cacheName: 'image-assets'
}));
workbox.routing.registerRoute(navigationRoute);
workbox.routing.registerRoute(staticAssetRoute);
अगर किसी सीडीएन से Workbox रनटाइम को लोड करने की उम्मीद सही नहीं लगती, तो लोकल यूआरएल के साथ workbox-sw
का इस्तेमाल किया जा सकता है.
नतीजा
अब आपको पता चल गया है कि बिना प्री-कैशिंग के Workbox को इस्तेमाल करने का तरीका क्या है, इसलिए आपको किसी खास बंडलर या बिल्ड टूल का इस्तेमाल करने की ज़रूरत नहीं है. इससे आपको ऐसे सर्विस वर्कर को हैंडक्राफ़्ट करने की सुविधा मिलती है जिनमें आपकी दिलचस्पी है. ये Workbox के रनटाइम कैशिंग कोड के सिर्फ़ कुछ हिस्सों का इस्तेमाल करते हैं.