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

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

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

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

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

जब किसी वेब ऐप्लिकेशन को पहली बार लोड किया जाता है, तो 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-precaching के पिछले वर्शन में, प्रीकैश मेनिफ़ेस्ट में url और revision प्रॉपर्टी वाले ऑब्जेक्ट के साथ-साथ स्ट्रिंग यूआरएल भी शामिल हो सकते थे. वर्शन 5 में इसका इस्तेमाल बंद कर दिया जाता है. अब आपको हमेशा कोई ऑब्जेक्ट पास करना होगा. साथ ही, Workbox को कैश मेमोरी में मौजूद यूआरएल में बदलाव करने से रोकने के लिए, आपको revision प्रॉपर्टी को साफ़ तौर पर null पर सेट करना होगा. स्ट्रिंग को पास करने का काम वर्शन 5 में (चेतावनी के साथ) काम करता रहेगा, लेकिन वर्शन 6 में यह काम नहीं करेगा.

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

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

चेतावनी:हमारा सुझाव है कि आप इस प्री-कैश मेनिफ़ेस्ट को जनरेट करने के लिए, Workbox के किसी build टूल का इस्तेमाल करें. हार्डकोड रिव्यू की जानकारी को कभी भी "हाथ से लिखे हुए" मेनिफ़ेस्ट में न बदलें. ऐसा इसलिए, क्योंकि पहले से कैश मेमोरी में सेव किए गए यूआरएल को तब तक अप-टू-डेट नहीं रखा जाएगा, जब तक बदलाव की जानकारी में यूआरएल के कॉन्टेंट की जानकारी नहीं होती!

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

एक काम जो 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');

ध्यान दें:अगर precacheAndRoute के ज़रिए डिफ़ॉल्ट इंस्टेंस इस्तेमाल करने के बजाय, अपने PrecacheController इंस्टेंस का इस्तेमाल किया जा रहा है, तो आपको सीधे उसी इंस्टेंस पर matchPrecache() या getCacheKeyForURL() तरीके का इस्तेमाल करना चाहिए.

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

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.

टाइप

CleanupResult

प्रॉपर्टी

• deletedCacheRequests

  स्ट्रिंग[]

InstallResult

प्रॉपर्टी

• notUpdatedURLs

  स्ट्रिंग[]

• updatedURLs

  स्ट्रिंग[]

PrecacheController

एसेट को सटीक तरीके से प्री-कैश करता है.

प्रॉपर्टी

• कंस्ट्रक्टर

  void

  नया PrecacheController बनाएं.

  constructor फ़ंक्शन ऐसा दिखता है:

  (options?: PrecacheControllerOptions) => {...}

  • विकल्प

    PrecacheControllerOptions ज़रूरी नहीं

  • returns

    PrecacheController

• रणनीति वाले गेम

  रणनीति तैयार करें

• चालू करो

  void

  उन एसेट को मिटाता है जो अब मौजूदा प्रीकैश मेनिफ़ेस्ट में मौजूद नहीं हैं. सर्विस वर्कर ऐक्टिव इवेंट से इस तरीके को कॉल करें.

  ध्यान दें: यह तरीका आपके लिए event.waitUntil() को कॉल करता है, इसलिए आपको इसे अपने इवेंट हैंडलर में खुद कॉल करने की ज़रूरत नहीं है.

  activate फ़ंक्शन ऐसा दिखता है:

  (event: ExtendableEvent) => {...}

  • event

    ExtendableEvent

  • returns

    Promise<CleanupResult>

• addToCacheList

  void

  इस तरीके से, प्रीकैश मेमोरी में आइटम जोड़े जाएंगे. इससे डुप्लीकेट आइटम हट जाएंगे और यह पक्का हो जाएगा कि जानकारी मान्य है.

  addToCacheList फ़ंक्शन ऐसा दिखता है:

  (entries: (string | PrecacheEntry)[]) => {...}

  • एंट्री

    (स्ट्रिंग | PrecacheEntry)[]

    प्रीकैश मेमोरी में सेव की जाने वाली एंट्री की कैटगरी.

• createHandlerBoundToURL

  void

  यह फ़ंक्शन, प्रीकैश में url ढूंढता है (खाते की जानकारी को ध्यान में रखते हुए) और उससे जुड़ा Response दिखाता है.

  createHandlerBoundToURL फ़ंक्शन ऐसा दिखता है:

  (url: string) => {...}

  • यूआरएल

    स्ट्रिंग

    पहले से कैश मेमोरी में सेव किया गया यूआरएल, जिसका इस्तेमाल Response को खोजने के लिए किया जाएगा.

  • returns

    RouteHandlerCallback

• getCacheKeyForURL

  void

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

  getCacheKeyForURL फ़ंक्शन ऐसा दिखता है:

  (url: string) => {...}

  • यूआरएल

    स्ट्रिंग

    वह यूआरएल जिसकी कैश कुंजी आपको खोजना है.

  • returns

    स्ट्रिंग

    वह वर्शन वाला यूआरएल जो मूल यूआरएल के लिए कैश कुंजी से मिलता-जुलता है या अगर उस यूआरएल को पहले से कैश मेमोरी में सेव नहीं किया गया है, तो इसकी जानकारी नहीं दी जाती.

• getCachedURLs

  void

  उन सभी यूआरएल की सूची दिखाता है जिन्हें मौजूदा सर्विस वर्कर ने पहले से कैश मेमोरी में सेव किया है.

  getCachedURLs फ़ंक्शन ऐसा दिखता है:

  () => {...}

  • returns

    स्ट्रिंग[]

    पहले से कैश मेमोरी में सेव किए गए यूआरएल.

• getIntegrityForCacheKey

  void

  getIntegrityForCacheKey फ़ंक्शन ऐसा दिखता है:

  (cacheKey: string) => {...}

  • cacheKey

    स्ट्रिंग

  • returns

    स्ट्रिंग

    कैश कुंजी से जुड़ी सबरिसॉर्स इंटिग्रिटी की जानकारी या उसके सेट न होने पर, इसकी जानकारी नहीं दी जाती.

• getURLsToCacheKeys

  void

  यूआरएल के बदलाव की जानकारी को ध्यान में रखते हुए, इससे जुड़ी कैश मेमोरी की कुंजी पर पहले से कैश मेमोरी में सेव किए गए यूआरएल की मैपिंग दिखाता है.

  getURLsToCacheKeys फ़ंक्शन ऐसा दिखता है:

  () => {...}

  • returns

    मैप<string>

    कुंजी की मैपिंग को कैश मेमोरी में सेव करने के लिए यूआरएल.

• इंस्टॉल करो

  void

  नई और अपडेट की गई ऐसेट को पहले से कैश मेमोरी में सेव करता है. सर्विस वर्कर इंस्टॉल इवेंट से इस तरीके को कॉल करें.

  ध्यान दें: यह तरीका आपके लिए event.waitUntil() को कॉल करता है, इसलिए आपको इसे अपने इवेंट हैंडलर में खुद कॉल करने की ज़रूरत नहीं है.

  install फ़ंक्शन ऐसा दिखता है:

  (event: ExtendableEvent) => {...}

  • event

    ExtendableEvent

  • returns

    Promise<InstallResult>

• matchPrecache

  void

  इसका इस्तेमाल cache.match() के लिए, इन अंतरों के हिसाब से ड्रॉप-इन करने पर किया जाता है:

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

  उदाहरण, matchPrecache('index.html'), चालू सर्विस वर्कर के लिए, पहले से कैश मेमोरी में सेव किया गया सही रिस्पॉन्स ढूंढेगा. भले ही, असली कैश कुंजी '/index.html?__WB_REVISION__=1234abcd' हो.

  matchPrecache फ़ंक्शन ऐसा दिखता है:

  (request: string | Request) => {...}

  • CANNOT TRANSLATE

    स्ट्रिंग | अनुरोध

    प्रीकैश में खोजने के लिए कुंजी (पैरामीटर में बदलाव किए बिना).

  • returns

    वादा<Response>

• प्रीकैश मेमोरी

  void

  आइटम को प्री-कैश सूची में जोड़ता है. साथ ही, इससे डुप्लीकेट फ़ाइलों को हटाकर, कैश मेमोरी में सेव किया जाता है. ऐसा तब होता है, जब सर्विस वर्कर इंस्टॉल करता है.

  इस तरीके को एक से ज़्यादा बार कॉल किया जा सकता है.

  precache फ़ंक्शन ऐसा दिखता है:

  (entries: (string | PrecacheEntry)[]) => {...}

  • एंट्री

    (स्ट्रिंग | PrecacheEntry)[]

PrecacheEntry

प्रॉपर्टी

• रखरखाव करना

  स्ट्रिंग ज़रूरी नहीं

• बदलाव

  स्ट्रिंग ज़रूरी नहीं

• यूआरएल

  स्ट्रिंग

PrecacheFallbackPlugin

PrecacheFallbackPlugin की मदद से, किसी "ऑफ़लाइन फ़ॉलबैक" रिस्पॉन्स को तय किया जा सकता है. इसका इस्तेमाल तब किया जाता है, जब दी गई रणनीति कोई जवाब जनरेट नहीं कर पाती.

ऐसा करने के लिए, यह handlerDidError प्लगिन कॉलबैक को इंटरसेप्ट करता है और पहले से कैश मेमोरी में सेव किया गया रिस्पॉन्स भेजता है. इस प्रोसेस में, ज़रूरी रिविज़न पैरामीटर को अपने-आप खाते में ले जाया जाता है.

जब तक कंस्ट्रक्टर को साफ़ तौर पर PrecacheController इंस्टेंस पास नहीं किया जाता, तब तक डिफ़ॉल्ट इंस्टेंस का इस्तेमाल किया जाएगा. आम तौर पर, ज़्यादातर डेवलपर डिफ़ॉल्ट रूप से इसका इस्तेमाल करते हैं.

प्रॉपर्टी

• कंस्ट्रक्टर

  void

  इससे जुड़े फ़ॉलबैकयूआरएल के साथ एक नया PrecacheFallbackPlugin बनाता है.

  constructor फ़ंक्शन ऐसा दिखता है:

  (config: object) => {...}

  • कॉन्फ़िगरेशन

    ऑब्जेक्ट

    • fallbackURL

      स्ट्रिंग

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

    • precacheController

      PrecacheController ज़रूरी नहीं

  • returns

    PrecacheFallbackPlugin

PrecacheRoute

workbox-routing.Route की ऐसी सब-क्लास जो workbox-precaching.PrecacheController इंस्टेंस लेती है और इसका इस्तेमाल, आने वाले अनुरोधों को मैच करने और प्रीकैश मेमोरी से रिस्पॉन्स फ़ेच करने के लिए करती है.

प्रॉपर्टी

• कंस्ट्रक्टर

  void

  constructor फ़ंक्शन ऐसा दिखता है:

  (precacheController: PrecacheController, options?: PrecacheRouteOptions) => {...}

  • precacheController

    PrecacheController

    मैच करने के अनुरोधों और फ़ेच इवेंट का जवाब देने के लिए, PrecacheController इंस्टेंस का इस्तेमाल किया जाता है.

  • विकल्प

    PrecacheRouteOptions ज़रूरी नहीं है

  • returns

    PrecacheRoute

• catchHandler

  RouteHandlerObject ज़रूरी नहीं

• हैंडलर

  RouteHandlerObject

• मिलान

  RouteMatchCallback

• method

  HTTPMethod

• setCatchHandler

  void

  setCatchHandler फ़ंक्शन ऐसा दिखता है:

  (handler: RouteHandler) => {...}

  • हैंडलर

    RouteHandler

    ऐसा कॉलबैक फ़ंक्शन जो किसी जवाब के लिए प्रॉमिस रिज़ॉल्व करने पर रिटर्न करता है

PrecacheRouteOptions

प्रॉपर्टी

• cleanURLs

  बूलियन ज़रूरी नहीं

• directoryIndex

  स्ट्रिंग ज़रूरी नहीं

• ignoreURLParametersMatching

  RegExp[] ज़रूरी नहीं

• urlManipulation

  urlManipulation ज़रूरी नहीं

PrecacheStrategy

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

ध्यान दें: PrecacheController बनाते समय, इस क्लास का एक इंस्टेंस अपने-आप बन जाता है. आम तौर पर, इसे खुद बनाना ज़रूरी नहीं है.

प्रॉपर्टी

• कंस्ट्रक्टर

  void

  constructor फ़ंक्शन ऐसा दिखता है:

  (options?: PrecacheStrategyOptions) => {...}

  • विकल्प

    PrecacheTargetOptions ज़रूरी नहीं

  • returns

    PrecacheStrategy

• cacheName

  स्ट्रिंग

• fetchOptions

  requestInit ज़रूरी नहीं

• matchOptions

  CashQueryOptions ज़रूरी नहीं

• प्लगिन

  WorkboxPlugin[]

• copyRedirectedCacheableResponsesPlugin

  WorkboxPlugin

• defaultPrecacheCacheabilityPlugin

  WorkboxPlugin

• _awaitComplete

  void

  _awaitComplete फ़ंक्शन ऐसा दिखता है:

  (responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

  • responseDone

    वादा<Response>

  • हैंडलर

    StrategyHandler

  • CANNOT TRANSLATE

    अनुरोध

  • event

    ExtendableEvent

  • returns

    Promise<void>

• _getResponse

  void

  _getResponse फ़ंक्शन ऐसा दिखता है:

  (handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}

  • हैंडलर

    StrategyHandler

  • CANNOT TRANSLATE

    अनुरोध

  • event

    ExtendableEvent

  • returns

    वादा<Response>

• _हैंडल फ़ेच

  void

  _handleFetch फ़ंक्शन ऐसा दिखता है:

  (request: Request, handler: StrategyHandler) => {...}

  • CANNOT TRANSLATE

    अनुरोध

  • हैंडलर

    StrategyHandler

  • returns

    वादा<Response>

• _हैंडलइंस्टॉल

  void

  _handleInstall फ़ंक्शन ऐसा दिखता है:

  (request: Request, handler: StrategyHandler) => {...}

  • CANNOT TRANSLATE

    अनुरोध

  • हैंडलर

    StrategyHandler

  • returns

    वादा<Response>

• हैंडल

  void

  अनुरोध करने की रणनीति लागू करें और ऐसा Promise वापस करें जो Response के साथ रिज़ॉल्व हो जाएगा. ऐसा, सभी ज़रूरी प्लगिन कॉलबैक को शुरू करते हुए किया जाएगा.

  जब रणनीति इंस्टेंस, Workbox के साथ रजिस्टर किया जाता है workbox-routing.Route, तो रूट के मैच होने पर यह तरीका अपने-आप कॉल हो जाता है.

  इसके अलावा, इस तरीके को event.respondWith() को पास करके, स्टैंडअलोन FetchEvent लिसनर में भी इस्तेमाल किया जा सकता है.

  handle फ़ंक्शन ऐसा दिखता है:

  (options: FetchEvent | HandlerCallbackOptions) => {...}

  • विकल्प

    FetchEvent | HandlerCallbackOptions

    FetchEvent या नीचे दी गई प्रॉपर्टी वाला कोई ऑब्जेक्ट.

  • returns

    वादा<Response>

• handleAll

  void

  workbox-strategies.Strategy~handle की तरह ही, लेकिन सिर्फ़ Response को रिज़ॉल्व करने वाले Promise देने के बजाय, यह [response, done] प्रॉमिस का एक टपल दिखाएगा. इसमें पुराना (response) प्रॉमिस को handle() के बराबर होगा. साथ ही, बाद वाला प्रॉमिस ऐसा प्रॉमिस है जो रणनीति को पूरा करने के दौरान event.waitUntil() में जोड़े गए किसी भी प्रॉमिस को पूरा करेगा.

  यह पक्का करने के लिए कि done से कोई अतिरिक्त काम (आम तौर पर, कैश मेमोरी में सेव किए गए जवाब) पूरा हो जाए, यह पक्का करने के लिए आपको इंतज़ार करना होगा.

  handleAll फ़ंक्शन ऐसा दिखता है:

  (options: FetchEvent | HandlerCallbackOptions) => {...}

  • विकल्प

    FetchEvent | HandlerCallbackOptions

    FetchEvent या नीचे दी गई प्रॉपर्टी वाला कोई ऑब्जेक्ट.

  • returns

    [Promise<Response>, Promise<void>]

    [response, complete] वादाओं का एक टुकड़ा यह तय करने के लिए इस्तेमाल किया जा सकता है कि रिस्पॉन्स का समाधान कब हो और हैंडलर ने अपना सारा काम पूरा कर लिया हो.

urlManipulation()

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

टाइप

function

पैरामीटर

• { url }

  ऑब्जेक्ट

  • यूआरएल

    यूआरएल

लौटाए गए प्रॉडक्ट

• यूआरएल[]

तरीके

addPlugins()

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

पहले से कैश मेमोरी में सेव करने की रणनीति में प्लगिन जोड़ता है.

पैरामीटर

• प्लगिन

  WorkboxPlugin[]

addRoute()

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

सर्विस वर्कर के लिए, fetch लिसनर जोड़ें, जो पहले से कैश मेमोरी में सेव की गई ऐसेट के साथ [नेटवर्क अनुरोध]https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Custom_responses_to_requests को जवाब देगा.

ऐसी ऐसेट के लिए अनुरोध जो पहले से कैश मेमोरी में नहीं हैं, उनके लिए FetchEvent का जवाब नहीं दिया जाएगा. इससे, इवेंट को fetch इवेंट के दूसरे सदस्यों के ज़रिए शेयर नहीं किया जाएगा.

पैरामीटर

• विकल्प

  PrecacheRouteOptions ज़रूरी नहीं है

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

activate इवेंट लिसनर जोड़ा जाता है, जो काम नहीं करने वाले ऐसे प्रीकैश को हटा देगा जिन्हें Workbox के पुराने वर्शन से बनाया गया था.

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

डिफ़ॉल्ट PrecacheController इंस्टेंस पर PrecacheController#createHandlerBoundToURL को कॉल करने वाला हेल्पर फ़ंक्शन.

अगर आपको खुद का PrecacheController बनाना है, तो इस फ़ंक्शन का इस्तेमाल करने के बजाय, उस इंस्टेंस पर PrecacheController#createHandlerBoundToURL को कॉल करें.

पैरामीटर

• यूआरएल

  स्ट्रिंग

  पहले से कैश मेमोरी में सेव किया गया यूआरएल, जिसका इस्तेमाल Response को खोजने के लिए किया जाएगा.

लौटाए गए प्रॉडक्ट

• RouteHandlerCallback

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

यूआरएल ले लेता है और उससे जुड़ा यूआरएल दिखाता है, जिसका इस्तेमाल प्रीकैश में एंट्री को खोजने के लिए किया जा सकता है.

अगर कोई मिलता-जुलता यूआरएल दिया गया है, तो सर्विस वर्कर फ़ाइल की जगह को बेस के तौर पर इस्तेमाल किया जाएगा.

बिना बदलाव की जानकारी के पहले से कैश मेमोरी में सेव की गई एंट्री के लिए, कैश कुंजी कुंजी मूल यूआरएल की तरह ही होगी.

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

पैरामीटर

• यूआरएल

  स्ट्रिंग

  वह यूआरएल जिसकी कैश मेमोरी को खोजना है.

लौटाए गए प्रॉडक्ट

• स्ट्रिंग | इसके बारे में जानकारी नहीं है

  यूआरएल से जुड़ी कैश कुंजी.

matchPrecache()

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

डिफ़ॉल्ट PrecacheController इंस्टेंस पर PrecacheController#matchPrecache को कॉल करने वाला हेल्पर फ़ंक्शन.

अगर आपको खुद का PrecacheController बनाना है, तो इस फ़ंक्शन का इस्तेमाल करने के बजाय PrecacheController#matchPrecache को कॉल करें.

पैरामीटर

• CANNOT TRANSLATE

  स्ट्रिंग | अनुरोध

  प्रीकैश में खोजने के लिए कुंजी (पैरामीटर में बदलाव किए बिना).

लौटाए गए प्रॉडक्ट

• Promise<Response | undefined>

precache()

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

आइटम को प्री-कैश सूची में जोड़ता है. साथ ही, इससे डुप्लीकेट फ़ाइलों को हटाकर, कैश मेमोरी में सेव किया जाता है. ऐसा तब होता है, जब सर्विस वर्कर इंस्टॉल करता है.

इस तरीके को एक से ज़्यादा बार कॉल किया जा सकता है.

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

अगर आपके पास प्री-कैश करने के लिए फ़ाइलों का कलेक्शन है, तो workbox-precaching.precacheAndRoute को कॉल किया जा सकता है.

पैरामीटर

• एंट्री

  (स्ट्रिंग | PrecacheEntry)[]

precacheAndRoute()

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

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

यह सुविधा इस्तेमाल करने का ऐसा तरीका है जिसमें workbox-precaching.precache और workbox-precaching.addRoute को एक ही कॉल में कॉल किया जाएगा.

पैरामीटर

• एंट्री

  (स्ट्रिंग | PrecacheEntry)[]

  प्रीकैश मेमोरी में सेव की जाने वाली एंट्री की कैटगरी.

• विकल्प

  PrecacheRouteOptions ज़रूरी नहीं है