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

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

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

Workbox, एपीआई को आसान बनाकर और यह पक्का करके, पहले से कैश मेमोरी में सेव करने की प्रोसेस को आसान बनाता है कि एसेट बेहतर तरीके से डाउनलोड की जाएं.

workbox-precaching कैसे काम करता है

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

workbox-precaching, सेवा वर्कर के install इवेंट के दौरान यह सब करता है.

जब कोई उपयोगकर्ता बाद में आपके वेब ऐप्लिकेशन पर फिर से आता है और आपके पास पहले से कैश मेमोरी में सेव की गई अलग-अलग एसेट के साथ एक नया सेवा वर्कर है, तो workbox-precaching नई सूची देखेगा और यह तय करेगा कि कौनसी एसेट पूरी तरह से नई हैं और कौनसी मौजूदा एसेट को अपडेट करने की ज़रूरत है. यह तय करने के लिए, 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 और CSS संसाधनों के उलट, एचटीएमएल फ़ाइलें आम तौर पर अपने यूआरएल में बदलाव करने की जानकारी शामिल नहीं कर सकतीं. ऐसा न करने पर, पेज का कॉन्टेंट बदलने पर वेब पर इन फ़ाइलों के लिंक काम नहीं करेंगे.

precacheAndRoute() को रिविज़न प्रॉपर्टी पास करके, Workbox यह जान सकता है कि फ़ाइल कब बदली है और उसे उसी हिसाब से अपडेट कर सकता है.

Workbox में ऐसे टूल मौजूद हैं जिनकी मदद से, इस सूची को जनरेट किया जा सकता है:

  • workbox-build: यह एक नोड पैकेज है. इसका इस्तेमाल gulp टास्क या npm run स्क्रिप्ट के तौर पर किया जा सकता है.
  • workbox-webpack-plugin: webpack के उपयोगकर्ता इस प्लगिन का इस्तेमाल कर सकते हैं.
  • 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 का सीधे तौर पर इस्तेमाल करना

डिफ़ॉल्ट रूप से, 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');

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

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

इस पुराने डेटा से, सामान्य कामों में कोई रुकावट नहीं आती. हालांकि, यह आपके स्टोरेज कोटा के इस्तेमाल में योगदान देता है. इसलिए, इसे साफ़ तौर पर मिटाने से आपके उपयोगकर्ताओं को मदद मिल सकती है. ऐसा करने के लिए, अपने सर्विस वर्कर में 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

    string[]

InstallResult

प्रॉपर्टी

  • notUpdatedURLs

    string[]

  • updatedURLs

    string[]

PrecacheController

ऐसेट को पहले से कैश मेमोरी में सेव करने की सुविधा देता है.

प्रॉपर्टी

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

    अमान्य

    नया PrecacheController बनाएं.

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

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

    • विकल्प

      PrecacheControllerOptions ज़रूरी नहीं

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

    रणनीति

  • चालू करो

    अमान्य

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

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

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

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

    • इवेंट

      ExtendableEvent

  • addToCacheList

    अमान्य

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

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

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

    • एंट्री

      (string | PrecacheEntry)[]

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

  • createHandlerBoundToURL

    अमान्य

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

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

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

    • url

      स्ट्रिंग

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

  • getCacheKeyForURL

    अमान्य

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

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

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

    • url

      स्ट्रिंग

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

    • returns

      स्ट्रिंग

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

  • getCachedURLs

    अमान्य

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

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

    () => {...}

    • returns

      string[]

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

  • getIntegrityForCacheKey

    अमान्य

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

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

    • cacheKey

      स्ट्रिंग

    • returns

      स्ट्रिंग

      कैश मेमोरी कुंजी से जुड़ा सब-रिसॉर्स इंटिग्रिटी या अगर यह सेट नहीं है, तो 'तय नहीं किया गया'.

  • getURLsToCacheKeys

    अमान्य

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

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

    () => {...}

    • returns

      Map<stringstring>

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

  • इंस्टॉल करो

    अमान्य

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

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

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

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

    • इवेंट

      ExtendableEvent

  • matchPrecache

    अमान्य

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

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

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

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

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

    • CANNOT TRANSLATE

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

      प्रीकैश मेमोरी में खोजने के लिए, बदलाव करने वाले पैरामीटर के बिना पासकोड.

    • returns

      Promise<Response>

  • precache

    अमान्य

    सेवा वर्कर्स के इंस्टॉल होने पर, प्रीकैश सूची में आइटम जोड़ता है, डुप्लीकेट आइटम हटाता है, और फ़ाइलों को कैश मेमोरी में सेव करता है.

    इस तरीके को कई बार इस्तेमाल किया जा सकता है.

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

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

PrecacheEntry

प्रॉपर्टी

  • इंटिग्रिटी

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

  • बदलाव

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

  • url

    स्ट्रिंग

PrecacheFallbackPlugin

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

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

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

प्रॉपर्टी

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

    अमान्य

    इससे, fallbackURL से जुड़ा एक नया PrecacheFallbackPlugin बनता है.

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

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

    • config

      ऑब्जेक्ट

      • fallbackURL

        स्ट्रिंग

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

      • precacheController

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

PrecacheRoute

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

प्रॉपर्टी

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

    अमान्य

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

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

    • precacheController

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

    • विकल्प

      PrecacheRouteOptions ज़रूरी नहीं

  • catchHandler

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

  • मिलान
  • तरीका

    HTTPMethod

  • setCatchHandler

    अमान्य

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

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

    • handler

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

PrecacheRouteOptions

प्रॉपर्टी

  • cleanURLs

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

  • directoryIndex

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

  • ignoreURLParametersMatching

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

  • urlManipulation

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

PrecacheStrategy

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

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

प्रॉपर्टी

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

    अमान्य

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

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

    • विकल्प

      PrecacheStrategyOptions ज़रूरी नहीं

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • copyRedirectedCacheableResponsesPlugin
  • defaultPrecacheCacheabilityPlugin
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • handler
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • handler
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<Response>

  • _handleFetch

    अमान्य

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

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

    • returns

      Promise<Response>

  • _handleInstall

    अमान्य

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

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

    • returns

      Promise<Response>

  • हैंडल

    अमान्य

    अनुरोध की रणनीति लागू करें और Promise दिखाएं. यह Response के साथ हल होगा और सभी काम के प्लग इन कॉलबैक को लागू करेगा.

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

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

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

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

    • विकल्प

      FetchEvent | HandlerCallbackOptions

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

    • returns

      Promise<Response>

  • handleAll

    अमान्य

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

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

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

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

    • विकल्प

      FetchEvent | HandlerCallbackOptions

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

    • returns

      [Promise<Response>, Promise<void>]

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

urlManipulation()

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

टाइप

फ़ंक्शन

पैरामीटर

  • { url }

    ऑब्जेक्ट

    • url

      URL

रिटर्न

  • यूआरएल[]

तरीके

addPlugins()

workbox-precaching.addPlugins(
  plugins: 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 इवेंट के लिसनर पर भेजा जा सकता है.

पैरामीटर

cleanupOutdatedCaches()

workbox-precaching.cleanupOutdatedCaches()

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

createHandlerBoundToURL()

workbox-precaching.createHandlerBoundToURL(
  url: string,
)

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

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

पैरामीटर

  • url

    स्ट्रिंग

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

रिटर्न

getCacheKeyForURL()

workbox-precaching.getCacheKeyForURL(
  url: string,
)

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

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

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

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

पैरामीटर

  • url

    स्ट्रिंग

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

रिटर्न

  • स्ट्रिंग | तय नहीं

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

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 को कॉल करें.

पैरामीटर

precacheAndRoute()

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

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

यह एक आसान तरीका है, जो एक ही कॉल में workbox-precaching.precache और workbox-precaching.addRoute को कॉल करेगा.

पैरामीटर

  • एंट्री

    (string | PrecacheEntry)[]

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

  • विकल्प

    PrecacheRouteOptions ज़रूरी नहीं