वर्कबॉक्स-प्रीकैशिंग

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

ऐसा करने की मुख्य वजह यह है कि यह डेवलपर को कैश मेमोरी पर कंट्रोल देता है. इसका मतलब है कि वे यह तय कर सकते हैं कि किसी फ़ाइल को कब और कितनी देर तक कैश मेमोरी में सेव किया जाएगा. साथ ही, वे नेटवर्क में जाए बिना ही उसे ब्राउज़र पर उपलब्ध करा सकते हैं. इसका मतलब है कि इसका इस्तेमाल ऑफ़लाइन काम करने वाले वेब ऐप्लिकेशन बनाने के लिए किया जा सकता है.

वर्कबॉक्स, एपीआई को आसान बनाकर यह पक्का करता है कि एसेट को सही तरीके से डाउनलोड किया गया हो. इससे, प्री-कैशिंग में बहुत समय लगता है.

वर्कबॉक्स प्री-कैशिंग कैसे काम करती है

जब किसी वेब ऐप्लिकेशन को पहली बार लोड किया जाता है, तो workbox-precaching उन सभी एसेट को देखेगा जिन्हें आपको डाउनलोड करना है. साथ ही, एसेट हटाए जाने के बाद, एसेट को डाउनलोड और सेव करने के लिए, काम के सर्विस वर्कर इवेंट को हुक अप कर देगा. ऐसे यूआरएल जिनमें वर्शन की जानकारी पहले से ही शामिल होती है (जैसे कि कॉन्टेंट का हैश), उनका इस्तेमाल कैश मेमोरी के तौर पर किया जाता है. साथ ही, इनमें और बदलाव नहीं किए जाते. जिन यूआरएल में वर्शन की जानकारी शामिल नहीं होती है उनकी कैश कुंजी में एक अतिरिक्त यूआरएल क्वेरी पैरामीटर जुड़ा होता है. यह उनके कॉन्टेंट का हैश दिखाता है, जिसे Workbox से बिल्ड के दौरान जनरेट किया जाता है.

workbox-precaching ये सभी काम सर्विस वर्कर के install इवेंट के दौरान करता है.

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

जब तक इसके activate इवेंट ट्रिगर नहीं हो जाते, तब तक इस नए सर्विस वर्कर का इस्तेमाल अनुरोधों का जवाब देने के लिए नहीं किया जाएगा. activate इवेंट में workbox-precaching, कैश मेमोरी में सेव की गई ऐसी एसेट की जांच करेगा जो मौजूदा यूआरएल की सूची में अब मौजूद नहीं हैं. साथ ही, उन एसेट को कैश मेमोरी से हटा देगा.

आपके सर्विस वर्कर को इंस्टॉल और चालू करने पर, workbox-precaching इन चरणों को पूरा करेगा. इससे यह पक्का होगा कि उपयोगकर्ता के पास नई ऐसेट हैं और सिर्फ़ उन फ़ाइलों को डाउनलोड करेगा जिनमें बदलाव हुआ है.

पहले से कैश मेमोरी में सेव किए गए जवाब दिखाना

कॉल करने का विकल्प precacheAndRoute() या addRoute() एक रूट बनाएगा, जो कि पहले से कैश मेमोरी में सेव किए गए यूआरएल के अनुरोधों से मेल खाएगा.

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

precacheAndRoute() या addRoute() को कॉल करने का क्रम अहम होता है. आम तौर पर, registerRoute() के साथ किसी दूसरे रूट को रजिस्टर करने से पहले, आप इसे अपनी सर्विस वर्कर फ़ाइल में पहले कॉल करना चाहेंगे. अगर आपने पहले registerRoute() को कॉल किया था और वह रूट किसी इनकमिंग अनुरोध से मेल खाता था, तो जवाब देने के लिए उस अतिरिक्त रूट में तय की गई किसी भी रणनीति का इस्तेमाल किया जाएगा, न कि workbox-precaching की ओर से इस्तेमाल की जाने वाली कैश-फ़र्स्ट रणनीति का.

प्रीकैश सूची के बारे में जानकारी

workbox-precaching को, url और revision प्रॉपर्टी के साथ ऑब्जेक्ट का कलेक्शन चाहिए. इस कलेक्शन को कभी-कभी प्रीकैश मेनिफ़ेस्ट भी कहा जाता है:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute([
  {url: '/index.html', revision: '383676'},
  {url: '/styles/app.0c9a31.css', revision: null},
  {url: '/scripts/app.0d5770.js', revision: null},
  // ... other entries ...
]);

इस सूची में यूआरएल के एक सेट के बारे में बताया गया है, जिसमें हर यूआरएल की "बदलाव" वाली जानकारी का अपना एक हिस्सा है.

ऊपर दिए गए उदाहरण में दूसरे और तीसरे ऑब्जेक्ट के लिए, revision प्रॉपर्टी को null पर सेट किया गया है. ऐसा इसलिए होता है, क्योंकि बदलाव की जानकारी यूआरएल में ही होती है. आम तौर पर, यह स्टैटिक ऐसेट के लिए सबसे सही तरीका होता है.

पहला ऑब्जेक्ट (/index.html) साफ़ तौर पर एक रिविज़न प्रॉपर्टी सेट करता है जो फ़ाइल के कॉन्टेंट का अपने-आप जनरेट होने वाला हैश है. JavaScript और सीएसएस संसाधनों के उलट, आम तौर पर एचटीएमएल फ़ाइलों में अपने यूआरएल में बदलाव की जानकारी शामिल नहीं की जा सकती. ऐसा नहीं होने पर, पेज का कॉन्टेंट बदलने पर वेब पर इन फ़ाइलों के लिंक टूट सकते हैं.

precacheAndRoute() को बदली गई प्रॉपर्टी का ऐक्सेस देने पर, Workbox को पता चल सकता है कि फ़ाइल में कब बदलाव हुए हैं और वह उसे उसी हिसाब से अपडेट कर सकता है.

इस सूची को जनरेट करने में मदद करने के लिए, Workbox के टूल पहले से मौजूद हैं:

• workbox-build: यह एक नोड पैकेज है, जिसे किसी गप टास्क में या एनपीएम रन स्क्रिप्ट के तौर पर इस्तेमाल किया जा सकता है.
• workbox-webpack-plugin: वेबपैक उपयोगकर्ता इस प्लग इन का इस्तेमाल कर सकते हैं.
• workbox-cli: हमारे सीएलआई का इस्तेमाल, एसेट की सूची जनरेट करने और उन्हें आपके सर्विस वर्कर में जोड़ने के लिए भी किया जा सकता है.

पहले से कैश मेमोरी में सेव की गई फ़ाइलों के लिए आने वाले अनुरोध

एक काम जो workbox-precaching करेगा, वह है, आने वाले नेटवर्क अनुरोधों में बदलाव करना, ताकि वे पहले से कैश मेमोरी में सेव की गई फ़ाइलों को आज़मा सकें और उनका मिलान कर सकें. यह वेब पर सामान्य तरीक़ों का पालन करता है.

उदाहरण के लिए, / के लिए किए गए अनुरोध को आम तौर पर /index.html पर मौजूद फ़ाइल से पूरा किया जा सकता है.

नीचे उन बदलावों की सूची दी गई है जो workbox-precaching डिफ़ॉल्ट रूप से करता है. साथ ही, यह भी बताया गया है कि उस व्यवहार में कैसे बदलाव किया जा सकता है.

यूआरएल पैरामीटर को अनदेखा करें

खोज पैरामीटर वाले अनुरोधों में बदलाव करके, चुनिंदा वैल्यू हटाई जा सकती हैं या सभी वैल्यू हटाई जा सकती हैं.

डिफ़ॉल्ट रूप से, utm_ से शुरू होने वाले या fbclid से पूरी तरह मेल खाने वाले खोज पैरामीटर हटा दिए जाते हैं. इसका मतलब है कि /about.html?utm_campaign=abcd के लिए किया गया अनुरोध, /about.html के लिए पहले से कैश मेमोरी में सेव की गई एंट्री के साथ पूरा किया जाएगा.

ignoreURLParametersMatching का इस्तेमाल करके, खोज पैरामीटर के अलग-अलग सेट को अनदेखा किया जा सकता है:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    // Ignore all URL parameters.
    ignoreURLParametersMatching: [/.*/],
  }
);

निर्देशिका इंडेक्स

डिफ़ॉल्ट रूप से, / पर खत्म होने वाले अनुरोधों का मिलान उन एंट्री के साथ किया जाएगा जिनके आखिर में index.html जुड़ा होगा. इसका मतलब है कि / के लिए आने वाले अनुरोध को, पहले से कैश मेमोरी में सेव की गई एंट्री /index.html की मदद से अपने-आप मैनेज किया जा सकता है.

directoryIndex को सेट करके, इसे किसी और चीज़ के साथ बदला जा सकता है या पूरी तरह से बंद किया जा सकता है:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    directoryIndex: null,
  }
);

यूआरएल हटाएं

अगर कोई अनुरोध प्रीकैश मेमोरी से मेल नहीं खाता है, तो हम .html को "साफ़" यूआरएल (यानी "बहुत अच्छे" यूआरएल) की सुविधा देने के लिए आखिर में जोड़ देंगे. इसका मतलब है कि /about जैसे अनुरोध को, /about.html के लिए पहले से कैश मेमोरी में सेव की गई एंट्री की मदद से मैनेज किया जाएगा.

cleanUrls सेट करके यह व्यवहार बंद किया जा सकता है:

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute([{url: '/about.html', revision: 'b79cd4'}], {
  cleanUrls: false,
});

कस्टम मैन्युफ़ैक्चरिंग

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

import {precacheAndRoute} from 'workbox-precaching';

precacheAndRoute(
  [
    {url: '/index.html', revision: '383676'},
    {url: '/styles/app.0c9a31.css', revision: null},
    {url: '/scripts/app.0d5770.js', revision: null},
  ],
  {
    urlManipulation: ({url}) => {
      // Your logic goes here...
      return [alteredUrlOption1, alteredUrlOption2];
    },
  }
);

बेहतर इस्तेमाल

PrecacheController Directly का इस्तेमाल करना

डिफ़ॉल्ट रूप से, workbox-precaching आपके लिए install और activate लिसनर को सेट अप करेगा. जो डेवलपर सर्विस वर्कर के बारे में जानते हैं उन्हें ज़्यादा कंट्रोल की ज़रूरत होने पर, ऐसा करना ज़रूरी न हो.

डिफ़ॉल्ट एक्सपोर्ट का इस्तेमाल करने के बजाय, सीधे तौर पर PrecacheController का इस्तेमाल करके, प्रीकैश में आइटम जोड़े जा सकते हैं. साथ ही, यह तय किया जा सकता है कि इन ऐसेट को कब इंस्टॉल किया जाए, और क्लीनअप कब की जाए.

import {PrecacheController} from 'workbox-precaching';

const precacheController = new PrecacheController();
precacheController.addToCacheList([
  {url: '/styles/example-1.abcd.css', revision: null},
  {url: '/styles/example-2.1234.css', revision: null},
  {url: '/scripts/example-1.abcd.js', revision: null},
  {url: '/scripts/example-2.1234.js', revision: null},
]);

precacheController.addToCacheList([{
  url: '/index.html',
  revision: 'abcd',
}, {
  url: '/about.html',
  revision: '1234',
}]);

self.addEventListener('install', (event) => {
  // Passing in event is required in Workbox v6+
  event.waitUntil(precacheController.install(event));
});

self.addEventListener('activate', (event) => {
  // Passing in event is required in Workbox v6+
  event.waitUntil(precacheController.activate(event));
});

self.addEventListener('fetch', (event) => {
  const cacheKey = precacheController.getCacheKeyForURL(event.request.url);
  event.respondWith(caches.match(cacheKey).then(...));
});

पहले से कैश मेमोरी में सेव की गई ऐसेट को सीधे तौर पर पढ़ना

ऐसा भी हो सकता है कि आपको पहले से कैश मेमोरी में सेव की गई किसी ऐसेट को सीधे तौर पर पढ़ना पड़े, लेकिन रूटिंग के उस हिस्से से अलग, जिसे workbox-precaching अपने-आप परफ़ॉर्म कर सकता है. उदाहरण के लिए, हो सकता है कि आप आंशिक एचटीएमएल टेंप्लेट को प्री-कैश करना चाहें, जिन्हें पूरा रिस्पॉन्स बनाते समय वापस पाने और इस्तेमाल करने की ज़रूरत होती है.

आम तौर पर, पहले से कैश मेमोरी में सेव किए गए Response ऑब्जेक्ट पाने के लिए, कैश मेमोरी एपीआई का इस्तेमाल किया जाता है. हालांकि, इसमें एक समस्या है: cache.match() को कॉल करते समय इस्तेमाल की जाने वाली यूआरएल कैश कुंजी में ऐसा वर्शन हो सकता है जो workbox-precaching अपने-आप बनाता और बनाए रखता है.

सही कैश कुंजी पाने के लिए, getCacheKeyForURL() को कॉल किया जा सकता है. इसके लिए, ओरिजनल यूआरएल को पास करें और फिर नतीजे का इस्तेमाल, सही कैश मेमोरी पर cache.match() करने के लिए करें.

import {cacheNames} from 'workbox-core';
import {getCacheKeyForURL} from 'workbox-precaching';

const cache = await caches.open(cacheNames.precache);
const response = await cache.match(getCacheKeyForURL('/precached-file.html'));

इसके अलावा, अगर आपको सिर्फ़ पहले से कैश मेमोरी में सेव किए गए Response ऑब्जेक्ट की ज़रूरत है, तो matchPrecache() को कॉल करें. यह अपने-आप सही कैश कुंजी का इस्तेमाल करेगा और सही कैश मेमोरी में खोज करेगा:

import {matchPrecache} from 'workbox-precaching';

const response = await matchPrecache('/precached-file.html');

पहले से सेव किए गए पुराने डेटा मिटाएं

Workspace की ज़्यादातर रिलीज़, पहले से कैश मेमोरी में सेव किए गए डेटा को सेव करने के लिए एक ही फ़ॉर्मैट का इस्तेमाल करती हैं. वर्कबॉक्स के पुराने वर्शन से बनाए गए प्री-कैश का इस्तेमाल, आम तौर पर नई रिलीज़ में ठीक वैसे ही किया जा सकता है. प्रीकैश मेमोरी में डेटा सेव करने की प्रोसेस में कभी-कभार ही बदलाव होता है. इस वजह से मौजूदा उपयोगकर्ताओं को हर चीज़ फिर से डाउनलोड करनी पड़ती है और ऐसा होने की वजह से, पहले से कैश मेमोरी में सेव किया गया डेटा पुराना हो जाता है. (वर्कबॉक्स v3 और v4 की रिलीज़ के बीच में ऐसा बदलाव हुआ.)

इस पुराने डेटा की वजह से सामान्य कामकाज में कोई रुकावट नहीं होनी चाहिए, लेकिन इसका इस्तेमाल आपके कुल स्टोरेज कोटा में ही हो जाता है. साथ ही, आपके उपयोगकर्ताओं के लिए इसे साफ़ तौर पर मिटाना अच्छा होता है. ऐसा करने के लिए, cleanupOutdatedCaches() को अपने सर्विस वर्कर में जोड़ें या अगर आप अपने सर्विस वर्कर को जनरेट करने के लिए, Workbox के किसी बिल्ड टूल का इस्तेमाल कर रहे हैं, तो cleanupOutdatedCaches: true सेट करें.

सबरिसॉर्स इंटिग्रिटी का इस्तेमाल करना

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

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

यह तय करना कि किन प्रीकैश मेनिफ़ेस्ट एंट्री में integrity प्रॉपर्टी होनी चाहिए और सही वैल्यू पता करना, Workbox के बिल्ड टूल के दायरे से बाहर है. इसके बजाय, जो डेवलपर इस सुविधा के लिए ऑप्ट-इन करना चाहते हैं उन्हें प्रीकैश मेमोरी में बदलाव करना चाहिए. प्रीकैश मेमोरी को Workbox से जनरेट किया जाता है, ताकि उसमें सही जानकारी शामिल की जा सके. Workbox के बिल्ड टूल कॉन्फ़िगरेशन में मौजूद manifestTransform विकल्प से, आपको इन कामों में मदद मिल सकती है:

const ssri = require('ssri');

const integrityManifestTransform = (originalManifest, compilation) => {
  const warnings = [];
  const manifest = originalManifest.map(entry => {
    // If some criteria match:
    if (entry.url.startsWith('...')) {
      // This has to be a synchronous function call, for example:
      // compilation will be set when using workbox-webpack-plugin.
      // When using workbox-build directly, you can read the file's
      // contents from disk using, e.g., the fs module.
      const asset = compilation.getAsset(entry.url);
      entry.integrity = ssri.fromData(asset.source.source()).toString();

      // Push a message to warnings if needed.
    }
    return entry;
  });

  return {warnings, manifest};
};

// Then add manifestTransform: [integrityManifestTransform]
// to your Workbox build configuration.

workbox-precaching.urlManipulation(
  { url }: object,
)

workbox-precaching.addPlugins(
  plugins: WorkboxPlugin[],
)

workbox-precaching.addRoute(
  options?: PrecacheRouteOptions,
)

workbox-precaching.cleanupOutdatedCaches()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

workbox-precaching.getCacheKeyForURL(
  url: string,
)

workbox-precaching.matchPrecache(
  request: string | Request,
)

workbox-precaching.precache(
  entries: (string | PrecacheEntry)[],
)

workbox-precaching.precacheAndRoute(
  entries: (string | PrecacheEntry)[],
  options?: PrecacheRouteOptions,
)