वर्कबॉक्स बनाने की रणनीतियां

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

workbox-strategies, कैश मेमोरी में डेटा सेव करने की सबसे सामान्य रणनीतियां उपलब्ध कराता है, ताकि उन्हें अपने सेवा वर्कर में आसानी से लागू किया जा सके.

हम Workbox की मदद से काम करने वाली रणनीतियों के अलावा, किसी और रणनीति के बारे में ज़्यादा जानकारी नहीं देंगे. हालांकि, ऑफ़लाइन कुकबुक में ज़्यादा जानें.

रणनीतियों का इस्तेमाल करना

नीचे दिए गए उदाहरणों में, हम आपको workbox-routing के साथ Workbox की कैश मेमोरी सेव करने की रणनीतियों का इस्तेमाल करने का तरीका बताएंगे. हर रणनीति के साथ कुछ विकल्प तय किए जा सकते हैं. इन विकल्पों के बारे में इस दस्तावेज़ के 'रणनीतियों को कॉन्फ़िगर करना' सेक्शन में बताया गया है.

बेहतर इस्तेमाल वाले सेक्शन में, हम आपको बताएंगे कि workbox-routing के बिना, कैश मेमोरी से जुड़ी रणनीतियों का इस्तेमाल कैसे किया जा सकता है.

Stale-While-Revalidate

डायग्राम की फिर से पुष्टि करते समय पुराना होना

stale-while-revalidate पैटर्न की मदद से, कैश मेमोरी में सेव किए गए जवाब का इस्तेमाल करके, अनुरोध का जवाब जल्द से जल्द दिया जा सकता है. हालांकि, अगर कैश मेमोरी में सेव किया गया जवाब उपलब्ध नहीं है, तो नेटवर्क अनुरोध का इस्तेमाल किया जाता है. इसके बाद, कैश मेमोरी को अपडेट करने के लिए नेटवर्क अनुरोध का इस्तेमाल किया जाता है. 'कैश मेमोरी में मौजूद डेटा का फिर से पुष्टि करना' सुविधा के कुछ तरीकों के मुकाबले, यह रणनीति हमेशा फिर से पुष्टि करने का अनुरोध करेगी. भले ही, कैश मेमोरी में मौजूद रिस्पॉन्स की उम्र कितनी भी हो.

यह एक आम रणनीति है, जिसमें ऐप्लिकेशन के लिए सबसे अप-टू-डेट संसाधन होना ज़रूरी नहीं है.

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';

registerRoute(
  ({url}) => url.pathname.startsWith('/images/avatars/'),
  new StaleWhileRevalidate()
);

पहले कैश मेमोरी में सेव करें (कैश मेमोरी में सेव करने के बाद, नेटवर्क से डाउनलोड करें)

कैश मेमोरी का पहला डायग्राम

ऑफ़लाइन वेब ऐप्लिकेशन, कैश मेमोरी पर काफ़ी निर्भर होंगे. हालांकि, ऐसी ऐसेट के लिए जिनकी ज़रूरत नहीं है और जिन्हें धीरे-धीरे कैश मेमोरी में सेव किया जा सकता है, पहले कैश मेमोरी में सेव करें सबसे अच्छा विकल्प है.

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

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';

registerRoute(({request}) => request.destination === 'style', new CacheFirst());

नेटवर्क फ़र्स्ट (नेटवर्क के कैश मेमोरी पर स्विच करना)

नेटवर्क का पहला डायग्राम

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

import {registerRoute} from 'workbox-routing';
import {NetworkFirst} from 'workbox-strategies';

registerRoute(
  ({url}) => url.pathname.startsWith('/social-timeline/'),
  new NetworkFirst()
);

सिर्फ़ नेटवर्क

सिर्फ़ नेटवर्क डायग्राम

अगर आपको नेटवर्क से कुछ खास अनुरोध पूरे करने हैं, तो सिर्फ़ नेटवर्क वाली रणनीति का इस्तेमाल करें.

import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

registerRoute(({url}) => url.pathname.startsWith('/admin/'), new NetworkOnly());

सिर्फ़ कैश मेमोरी

सिर्फ़ कैश मेमोरी का डायग्राम

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

import {registerRoute} from 'workbox-routing';
import {CacheOnly} from 'workbox-strategies';

registerRoute(({url}) => url.pathname.startsWith('/app/v2/'), new CacheOnly());

रणनीतियां कॉन्फ़िगर करना

सभी रणनीतियों की मदद से, ये कॉन्फ़िगर किए जा सकते हैं:

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

किसी रणनीति के लिए इस्तेमाल किए जा रहे कैश मेमोरी को बदलना

कैश मेमोरी का नाम डालकर, कैश मेमोरी की रणनीति बदली जा सकती है. अगर आपको डीबग करने में मदद करने के लिए, अपनी ऐसेट को अलग करना है, तो यह तरीका फ़ायदेमंद होता है.

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';

registerRoute(
  ({request}) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'image-cache',
  })
);

प्लग इन का इस्तेमाल करना

Workbox में प्लग इन का एक सेट होता है, जिसका इस्तेमाल इन रणनीतियों के साथ किया जा सकता है.

इनमें से किसी भी प्लग इन (या कस्टम प्लग इन) का इस्तेमाल करने के लिए, आपको plugins विकल्प में इंस्टेंस डालने होंगे.

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {ExpirationPlugin} from 'workbox-expiration';

registerRoute(
  ({request}) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new ExpirationPlugin({
        // Only cache requests for a week
        maxAgeSeconds: 7 * 24 * 60 * 60,
        // Only cache 10 requests.
        maxEntries: 10,
      }),
    ],
  })
);

कस्टम रणनीतियां

रणनीतियों को कॉन्फ़िगर करने के अलावा, Workbox की मदद से अपनी पसंद के मुताबिक रणनीतियां भी बनाई जा सकती हैं. ऐसा करने के लिए, workbox-strategies से Strategy बेस क्लास को इंपोर्ट और एक्सटेंड करें:

import {Strategy} from 'workbox-strategies';

class NewStrategy extends Strategy {
  _handle(request, handler) {
    // Define handling logic here
  }
}

इस उदाहरण में, handle() का इस्तेमाल अनुरोध की रणनीति के तौर पर किया गया है, ताकि डेटा को मैनेज करने का खास लॉजिक तय किया जा सके. अनुरोध करने के लिए, दो रणनीतियों का इस्तेमाल किया जा सकता है:

  • handle(): अनुरोध की रणनीति लागू करें और Promise दिखाएं. यह Response के तौर पर हल होगा. इसके लिए, काम के सभी प्लग इन कॉलबैक को लागू किया जाएगा.
  • handleAll(): handle() जैसा ही, लेकिन दो Promise ऑब्जेक्ट दिखाता है. पहला वैल्यू, handle() के रिटर्न के बराबर है और दूसरा तब रिज़ॉल्व होगा, जब रणनीति में event.waitUntil() में जोड़े गए प्रॉमिस पूरे हो जाएंगे.

अनुरोध की दोनों रणनीतियों को दो पैरामीटर के साथ शुरू किया जाता है:

  • request: वह Request जिसके लिए रणनीति से जवाब मिलेगा.
  • handler: मौजूदा रणनीति के लिए, अपने-आप जनरेट हुआ StrategyHandler इंस्टेंस.

नई रणनीति बनाना

यहां एक नई रणनीति का उदाहरण दिया गया है, जो NetworkOnly के व्यवहार को फिर से लागू करती है:

class NewNetworkOnlyStrategy extends Strategy {
  _handle(request, handler) {
    return handler.fetch(request);
  }
}

ध्यान दें कि नेटिव fetch मेथड के बजाय, handler.fetch() को कैसे कॉल किया जाता है. StrategyHandler क्लास, फ़ेच और कैश मेमोरी से जुड़ी कई कार्रवाइयां उपलब्ध कराती है. इनका इस्तेमाल, handle() या handleAll() का इस्तेमाल करने पर किया जा सकता है:

  • fetch: किसी अनुरोध को फ़ेच करता है और प्लग इन के लाइफ़साइकल के requestWillFetch(), fetchDidSucceed(), और fetchDidFail() तरीकों को लागू करता है
  • cacheMatch: कैश मेमोरी में मौजूद किसी अनुरोध से मैच करता है और cacheKeyWillBeUsed() और cachedResponseWillBeUsed() प्लग इन लाइफ़साइकल के तरीकों को शुरू करता है
  • cachePut: अनुरोध/रिस्पॉन्स पेयर को कैश मेमोरी में डालता है और cacheKeyWillBeUsed(), cacheWillUpdate(), और cacheDidUpdate() प्लग इन लाइफ़साइकल के तरीकों को लागू करता है
  • fetchAndCachePut: fetch() को कॉल करता है और fetch() से मिले रिस्पॉन्स पर बैकग्राउंड में cachePut() को चलाता है.
  • hasCallback: कॉलबैक को इनपुट के तौर पर लेता है और अगर रणनीति में दिए गए कॉलबैक के साथ कम से कम एक प्लग इन है, तो 'सही' दिखाता है.
  • runCallbacks: किसी दिए गए नाम से मैच करने वाले सभी प्लग इन कॉलबैक को क्रम से चलाता है. इसके लिए, दिए गए पैरामीटर ऑब्जेक्ट (प्लग इन की मौजूदा स्थिति के साथ मर्ज किया गया) को एकमात्र आर्ग्युमेंट के तौर पर पास किया जाता है.
  • iterateCallbacks: यह फ़ंक्शन एक कॉलबैक स्वीकार करता है और उससे मैच होने वाले प्लग इन कॉलबैक का एक कलेक्शन दिखाता है.इसमें हर कॉलबैक को मौजूदा हैंडलर स्टेटस के साथ रैप किया जाता है. इसका मतलब है कि हर कॉलबैक को कॉल करने पर, आपके पास जो भी ऑब्जेक्ट पैरामीटर होगा उसे प्लग इन की मौजूदा स्थिति के साथ मर्ज कर दिया जाएगा.
  • waitUntil: प्रोसेस किए जा रहे अनुरोध से जुड़े इवेंट के लाइफ़टाइम को बढ़ाने के वादे में एक वादा जोड़ता है. आम तौर पर, यह FetchEvent होता है.
  • doneWaiting: एक ऐसा प्रॉमिस दिखाता है जो waitUntil() में पास किए गए सभी प्रॉमिस के पूरा होने के बाद पूरा होता है.
  • destroy: रणनीति को चलाना बंद कर देता है और waitUntil() के किसी भी बाकी बचे वादे को तुरंत पूरा कर देता है.

कस्टम कैश नेटवर्क रेस की रणनीति

नीचे दिया गया उदाहरण, ऑफ़लाइन कुकबुक (जिसे Workbox उपलब्ध नहीं कराता) के cache-network-race पर आधारित है. हालांकि, यह एक कदम आगे बढ़ता है और नेटवर्क अनुरोध पूरा होने के बाद, हमेशा कैश मेमोरी को अपडेट करता है. यह रणनीति ज़्यादा जटिल है. इसमें कई कार्रवाइयों का इस्तेमाल किया जाता है.

import {Strategy} from 'workbox-strategies';

class CacheNetworkRace extends Strategy {
  _handle(request, handler) {
    const fetchAndCachePutDone = handler.fetchAndCachePut(request);
    const cacheMatchDone = handler.cacheMatch(request);

    return new Promise((resolve, reject) => {
      fetchAndCachePutDone.then(resolve);
      cacheMatchDone.then(response => response && resolve(response));

      // Reject if both network and cache error or find no response.
      Promise.allSettled([fetchAndCachePutDone, cacheMatchDone]).then(
        results => {
          const [fetchAndCachePutResult, cacheMatchResult] = results;
          if (
            fetchAndCachePutResult.status === 'rejected' &&
            !cacheMatchResult.value
          ) {
            reject(fetchAndCachePutResult.reason);
          }
        }
      );
    });
  }
}

बेहतर इस्तेमाल के लिए

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

उदाहरण के लिए, 'पुष्टि करते समय पुरानी जानकारी का इस्तेमाल करना' रणनीति का इस्तेमाल करने के लिए, ये काम किए जा सकते हैं:

self.addEventListener('fetch', event => {
  const {request} = event;
  const url = new URL(request.url);

  if (url.origin === location.origin && url.pathname === '/') {
    event.respondWith(new StaleWhileRevalidate().handle({event, request}));
  }
});

उपलब्ध क्लास की सूची, workbox-strategies के रेफ़रंस दस्तावेज़ में देखी जा सकती है.

टाइप

CacheFirst

कैश मेमोरी में पहले से मौजूद अनुरोध की रणनीति को लागू करना.

कैश मेमोरी का इस्तेमाल करने की रणनीति, उन ऐसेट के लिए काम की है जिनमें बदलाव किया गया है. जैसे, /styles/example.a8f5f1.css जैसे यूआरएल, क्योंकि इन्हें लंबे समय तक कैश मेमोरी में सेव किया जा सकता है.

अगर नेटवर्क अनुरोध पूरा नहीं होता और कैश मेमोरी में कोई मैच नहीं मिलता है, तो यह WorkboxError अपवाद दिखाएगा.

प्रॉपर्टी

  • constructor

    अमान्य

    रणनीति का नया इंस्टेंस बनाता है और दस्तावेज़ में मौजूद सभी विकल्प वाली प्रॉपर्टी को सार्वजनिक इंस्टेंस प्रॉपर्टी के तौर पर सेट करता है.

    ध्यान दें: अगर कोई कस्टम रणनीति क्लास, बुनियादी रणनीति क्लास को बढ़ाती है और उसे इन प्रॉपर्टी से ज़्यादा की ज़रूरत नहीं है, तो उसे अपना कंस्ट्रक्टर तय करने की ज़रूरत नहीं है.

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • 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] के टपल के वादों का इस्तेमाल, यह तय करने के लिए किया जा सकता है कि जवाब कब मिलता है और हैंडलर अपना सारा काम कब पूरा करता है.

CacheOnly

सिर्फ़ कैश मेमोरी के लिए अनुरोध की रणनीति लागू करना.

अगर आपको किसी Workbox प्लग इन का फ़ायदा लेना है, तो यह क्लास आपके लिए मददगार है.

अगर कैश मेमोरी में कोई मैच नहीं मिलता है, तो यह WorkboxError अपवाद दिखाएगा.

प्रॉपर्टी

  • constructor

    अमान्य

    रणनीति का नया इंस्टेंस बनाता है और दस्तावेज़ में मौजूद सभी विकल्प वाली प्रॉपर्टी को सार्वजनिक इंस्टेंस प्रॉपर्टी के तौर पर सेट करता है.

    ध्यान दें: अगर कोई कस्टम रणनीति क्लास, बुनियादी रणनीति क्लास को बढ़ाती है और उसे इन प्रॉपर्टी से ज़्यादा की ज़रूरत नहीं है, तो उसे अपना कंस्ट्रक्टर तय करने की ज़रूरत नहीं है.

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • 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] के टपल के वादों का इस्तेमाल, यह तय करने के लिए किया जा सकता है कि जवाब कब मिलता है और हैंडलर अपना सारा काम कब पूरा करता है.

NetworkFirst

नेटवर्क फ़र्स्ट अनुरोध की रणनीति को लागू करना.

डिफ़ॉल्ट रूप से, यह रणनीति 200 स्टेटस कोड के साथ-साथ ओपेक रिस्पॉन्स को कैश मेमोरी में सेव करेगी. ओपेक रिस्पॉन्स, क्रॉस-ऑरिजिन रिक्वेस्ट होते हैं. इनमें रिस्पॉन्स, CORS के साथ काम नहीं करता.

अगर नेटवर्क अनुरोध पूरा नहीं होता और कैश मेमोरी में कोई मैच नहीं मिलता है, तो यह WorkboxError अपवाद दिखाएगा.

प्रॉपर्टी

  • constructor

    अमान्य

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • 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] के टपल के वादों का इस्तेमाल, यह तय करने के लिए किया जा सकता है कि जवाब कब मिलता है और हैंडलर अपना सारा काम कब पूरा करता है.

NetworkFirstOptions

प्रॉपर्टी

  • cacheName

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

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • networkTimeoutSeconds

    number ज़रूरी नहीं

  • प्लग इन

    WorkboxPlugin[] ज़रूरी नहीं है

NetworkOnly

सिर्फ़ नेटवर्क के लिए अनुरोध की रणनीति को लागू करना.

अगर आपको किसी भी Workbox प्लग इन का फ़ायदा लेना है, तो यह क्लास आपके लिए मददगार है.

अगर नेटवर्क का अनुरोध पूरा नहीं हो पाता है, तो यह WorkboxError अपवाद दिखाएगा.

प्रॉपर्टी

  • constructor

    अमान्य

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • 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] के टपल के वादों का इस्तेमाल, यह तय करने के लिए किया जा सकता है कि जवाब कब मिलता है और हैंडलर अपना सारा काम कब पूरा करता है.

NetworkOnlyOptions

प्रॉपर्टी

  • fetchOptions

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

  • networkTimeoutSeconds

    number ज़रूरी नहीं

  • प्लग इन

    WorkboxPlugin[] ज़रूरी नहीं है

StaleWhileRevalidate

पुनरीपुष्टि करते समय पुराने डेटा का इस्तेमाल करने वाली अनुरोध रणनीति को लागू करना.

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

डिफ़ॉल्ट रूप से, यह रणनीति 200 स्टेटस कोड के साथ-साथ ओपेक रिस्पॉन्स को कैश मेमोरी में सेव करेगी. ओपेक रिस्पॉन्स, क्रॉस-ऑरिजिन रिक्वेस्ट होते हैं. इनमें रिस्पॉन्स, CORS के साथ काम नहीं करता.

अगर नेटवर्क अनुरोध पूरा नहीं होता और कैश मेमोरी में कोई मैच नहीं मिलता है, तो यह WorkboxError अपवाद दिखाएगा.

प्रॉपर्टी

  • constructor

    अमान्य

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • 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] के टपल के वादों का इस्तेमाल करके, यह तय किया जा सकता है कि जवाब कब मिलता है और हैंडलर अपना सारा काम कब पूरा करता है.

Strategy

एक ऐब्सट्रैक्ट बेस क्लास, जिससे रणनीति की अन्य सभी क्लास को एक्सटेंड करना ज़रूरी है:

प्रॉपर्टी

  • constructor

    अमान्य

    रणनीति का नया इंस्टेंस बनाता है और दस्तावेज़ में मौजूद सभी विकल्प वाली प्रॉपर्टी को सार्वजनिक इंस्टेंस प्रॉपर्टी के तौर पर सेट करता है.

    ध्यान दें: अगर कोई कस्टम रणनीति क्लास, बुनियादी रणनीति क्लास को बढ़ाती है और उसे इन प्रॉपर्टी से ज़्यादा की ज़रूरत नहीं है, तो उसे अपना कंस्ट्रक्टर तय करने की ज़रूरत नहीं है.

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन
  • _awaitComplete

    अमान्य

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

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

    • responseDone

      Promise<Response>

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    अमान्य

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

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

    • हैंडलर
    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<Response>

  • _handle

    अमान्य

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

    (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] के टपल के वादों का इस्तेमाल, यह तय करने के लिए किया जा सकता है कि जवाब कब मिलता है और हैंडलर अपना सारा काम कब पूरा करता है.

StrategyHandler

यह एक ऐसी क्लास है जो हर बार तब बनाई जाती है, जब रणनीति का कोई इंस्टेंस workbox-strategies.Strategy~handle या workbox-strategies.Strategy~handleAll को कॉल करता है.यह प्लग इन कॉलबैक के आस-पास सभी फ़ेच और कैश मेमोरी में सेव करने की कार्रवाइयों को रैप करती है. साथ ही, यह इस बात का भी ट्रैक रखती है कि रणनीति कब "पूरी हो गई" (यानी जोड़े गए सभी event.waitUntil() प्रॉमिस रिज़ॉल्व हो गए हैं).

प्रॉपर्टी

  • constructor

    अमान्य

    अनुरोध को मैनेज करने वाली रणनीति और इवेंट से जुड़ा नया इंस्टेंस बनाता है.

    कन्स्ट्रक्टर, उस स्थिति को भी शुरू करता है जिसे इस अनुरोध को मैनेज करने वाले हर प्लग इन को पास किया जाएगा.

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

    (strategy: Strategy, options: HandlerCallbackOptions) => {...}

  • इवेंट

    ExtendableEvent

  • पैरामीटर

    कोई भी ज़रूरी नहीं है

  • CANNOT TRANSLATE

    अनुरोध

  • url

    यूआरएल ज़रूरी नहीं

  • cacheMatch

    अमान्य

    रणनीति ऑब्जेक्ट पर तय किए गए cacheName, matchOptions, और plugins का इस्तेमाल करके, कैश मेमोरी में मौजूद किसी अनुरोध से मेल खाता है. साथ ही, लागू होने वाले प्लग इन कॉलबैक के तरीकों को भी चालू करता है.

    इस तरीके का इस्तेमाल करने पर, प्लग इन के लाइफ़साइकल के ये तरीके ट्रिगर होते हैं:

    • cacheKeyWillBeUsed()
    • cachedResponseWillBeUsed()

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

    (key: RequestInfo) => {...}

    • बटन

      RequestInfo

      कैश मेमोरी कुंजी के तौर पर इस्तेमाल करने के लिए अनुरोध या यूआरएल.

    • returns

      Promise<Response>

      मिलता-जुलता जवाब, अगर मिलता है.

  • cachePut

    अमान्य

    रणनीति ऑब्जेक्ट पर तय किए गए cacheName और plugins का इस्तेमाल करके, अनुरोध/जवाब के जोड़े को कैश मेमोरी में डालता है. साथ ही, लागू होने वाले प्लग इन कॉलबैक तरीकों को भी चालू करता है.

    इस तरीके का इस्तेमाल करने पर, प्लग इन के लाइफ़साइकल के ये तरीके ट्रिगर होते हैं:

    • cacheKeyWillBeUsed()
    • cacheWillUpdate()
    • cacheDidUpdate()

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

    (key: RequestInfo, response: Response) => {...}

    • बटन

      RequestInfo

      कैश मेमोरी कुंजी के तौर पर इस्तेमाल करने के लिए अनुरोध या यूआरएल.

    • जवाब

      जवाब

      कैश मेमोरी में सेव किया गया रिस्पॉन्स.

    • returns

      Promise<boolean>

      false अगर cacheWillUpdate की वजह से रिस्पॉन्स को कैश मेमोरी में सेव नहीं किया गया है, तो true.

  • बंद करें

    अमान्य

    रणनीति को चलाने से रोकता है और waitUntil() के लिए किए गए किसी भी बकाया वादे को तुरंत पूरा करता है.

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

    () => {...}

  • doneWaiting

    अमान्य

    एक प्रॉमिस दिखाता है. यह प्रॉमिस तब रिज़ॉल्व होता है, जब workbox-strategies.StrategyHandler~waitUntil को पास किए गए सभी प्रॉमिस सेटल हो जाते हैं.

    ध्यान दें: doneWaiting() सेटल होने के बाद किया गया कोई भी काम, मैन्युअल रूप से किसी इवेंट के waitUntil() तरीके (इस हैंडलर के waitUntil() तरीके के बजाय) पर पास किया जाना चाहिए. ऐसा न करने पर, काम पूरा होने से पहले ही सर्विस वर्कर थ्रेड को बंद किया जा सकता है.

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

    () => {...}

    • returns

      Promise<void>

  • लाएं

    अमान्य

    Strategy ऑब्जेक्ट पर तय किए गए fetchOptions (गैर-नेविगेशन अनुरोधों के लिए) और plugins का इस्तेमाल करके, किसी दिए गए अनुरोध को फ़ेच करता है. साथ ही, लागू होने वाले प्लग इन कॉलबैक तरीकों को भी चालू करता है.

    इस तरीके का इस्तेमाल करने पर, प्लग इन के लाइफ़साइकल के ये तरीके ट्रिगर होते हैं:

    • requestWillFetch()
    • fetchDidSucceed()
    • fetchDidFail()

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

    (input: RequestInfo) => {...}

    • इनपुट

      RequestInfo

      फ़ेच करने के लिए यूआरएल या अनुरोध.

    • returns

      Promise<Response>

  • fetchAndCachePut

    अमान्य

    this.fetch() को कॉल करता है और this.fetch() से जनरेट किए गए रिस्पॉन्स पर, बैकग्राउंड में this.cachePut() को चलाता है.

    this.cachePut() को कॉल करने पर, this.waitUntil() अपने-आप चालू हो जाता है. इसलिए, आपको इवेंट पर waitUntil() को मैन्युअल तरीके से कॉल करने की ज़रूरत नहीं है.

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

    (input: RequestInfo) => {...}

    • इनपुट

      RequestInfo

      फ़ेच और कैश मेमोरी में सेव करने के लिए अनुरोध या यूआरएल.

    • returns

      Promise<Response>

  • getCacheKey

    अमान्य

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

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

    (request: Request, mode: "read" 
     | "write"
    ) => {...}

    • CANNOT TRANSLATE

      अनुरोध

    • मोड

      "read"
       | "write"

    • returns

      Promise<Request>

  • hasCallback

    अमान्य

    अगर रणनीति में दिए गए कॉलबैक वाला कम से कम एक प्लग इन है, तो यह फ़ंक्शन True दिखाता है.

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

    (name: C) => {...}

    • नाम

      C

      उस कॉलबैक का नाम जिसकी जांच करनी है.

    • returns

      बूलियन

  • iterateCallbacks

    अमान्य

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

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

    (name: C) => {...}

    • नाम

      C

      चलाए जाने वाले कॉलबैक का नाम

    • returns

      Generator<NonNullable<indexedAccess>anyunknown>

  • runCallbacks

    अमान्य

    दिए गए नाम से मैच होने वाले सभी प्लग इन कॉलबैक को क्रम से चलाता है. इसके लिए, दिए गए पैरामीटर ऑब्जेक्ट (मौजूदा प्लग इन स्टेटस के साथ मर्ज किया गया) को एकमात्र आर्ग्युमेंट के तौर पर पास करता है.

    ध्यान दें: यह तरीका सभी प्लग इन चलाता है. इसलिए, यह उन मामलों के लिए सही नहीं है जहां अगले कॉलबैक को कॉल करने से पहले, कॉलबैक की रिटर्न वैल्यू को लागू करना ज़रूरी है. उस मामले को मैनेज करने का तरीका जानने के लिए, workbox-strategies.StrategyHandler#iterateCallbacks यहां देखें.

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

    (name: C, param: Omit<indexedAccess"state" 
    >) => {...}

    • नाम

      C

      हर प्लग इन में चलाए जाने वाले कॉलबैक का नाम.

    • param

      Omit<indexedAccess"state"
      >

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

    • returns

      Promise<void>

  • waitUntil

    अमान्य

    प्रोसेस किए जा रहे अनुरोध से जुड़े इवेंट के [extend lifetime promises]https://w3c.github.io/ServiceWorker/#extendableevent-extend-lifetime-promises में एक वादा जोड़ता है. आम तौर पर, यह एक FetchEvent होता है.

    ध्यान दें: जोड़े गए सभी वादे कब पूरे हो जाएंगे, यह जानने के लिए workbox-strategies.StrategyHandler~doneWaiting पर जाएं.

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

    (promise: Promise<T>) => {...}

    • वादा करना

      Promise<T>

      उस इवेंट के लाइफ़टाइम एक्सटेंशन के वादे में जोड़ने का वादा जिसकी वजह से अनुरोध ट्रिगर हुआ.

    • returns

      Promise<T>

StrategyOptions

प्रॉपर्टी

  • cacheName

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

  • fetchOptions

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

  • matchOptions

    CacheQueryOptions ज़रूरी नहीं

  • प्लग इन

    WorkboxPlugin[] ज़रूरी नहीं है