अब तक, यह दस्तावेज़ प्रीकैशिंग के मामले में काफ़ी अच्छा रहा है. यह दस्तावेज़ अक्सर 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
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
esbuild एक आसान कमांड-लाइन इंटरफ़ेस उपलब्ध कराता है:
npx esbuild ./src/sw.js --bundle --minify --outfile=./dist/sw.js
esbuild, process.env.NODE_ENV को डिफ़ॉल्ट रूप से 'development' से बदल देगा. अगर छोटा करने की सुविधा चालू है, तो इसे 'production' से बदल देगा.
workbox-sw
का इस्तेमाल करके बंडलर के बिना
हो सकता है कि आपके प्रोजेक्ट में बंडलर का इस्तेमाल भी न किया गया हो. importScripts
के साथ इंपोर्ट करने पर, workbox-sw
आपके लिए, सेवा वर्कर में सीडीएन से Workbox रनटाइम लोड कर सकता है. इसके लिए, उसे बिल्ड करने की ज़रूरत नहीं होती:
// 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 के रनटाइम कैशिंग कोड के कुछ हिस्सों का इस्तेमाल करके, सर्विस वर्कर को हैंडक्राफ़्ट करने की सुविधा मिलती है.