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

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

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

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

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

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

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

पुरानी-पुरानी-फिर से पुष्टि की गई

फिर से सत्यापित करते समय पुरानी जानकारी देने वाला डायग्राम

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

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

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}));
  }
});

वर्कबॉक्स-रणनीतियों के रेफ़रंस दस्तावेज़ में उपलब्ध क्लास की सूची देखी जा सकती है.

टाइप

CacheFirst

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

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

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

प्रॉपर्टी

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

    void

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

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

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

    WorkboxPlugin[]

  • _awaitComplete

    void

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

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

    • responseDone

      वादा<Response>

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

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

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

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

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

CacheOnly

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

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

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

प्रॉपर्टी

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

    void

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

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

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

    WorkboxPlugin[]

  • _awaitComplete

    void

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

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

    • responseDone

      वादा<Response>

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

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

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

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

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

NetworkFirst

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

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

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

प्रॉपर्टी

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

    void

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

    WorkboxPlugin[]

  • _awaitComplete

    void

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

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

    • responseDone

      वादा<Response>

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

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

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

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

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

NetworkFirstOptions

प्रॉपर्टी

  • cacheName

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

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • networkTimeoutSeconds

    नंबर ज़रूरी नहीं

  • प्लगिन

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

NetworkOnly

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

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

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

प्रॉपर्टी

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

    void

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

    WorkboxPlugin[]

  • _awaitComplete

    void

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

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

    • responseDone

      वादा<Response>

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

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

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

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

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

NetworkOnlyOptions

प्रॉपर्टी

  • fetchOptions

    requestInit ज़रूरी नहीं

  • networkTimeoutSeconds

    नंबर ज़रूरी नहीं

  • प्लगिन

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

StaleWhileRevalidate

मौजूदा समय में दोबारा पुष्टि करने के अनुरोध की रणनीति को लागू करना.

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

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

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

प्रॉपर्टी

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

    void

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

    WorkboxPlugin[]

  • _awaitComplete

    void

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

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

    • responseDone

      वादा<Response>

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

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

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

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

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

Strategy

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

प्रॉपर्टी

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

    void

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

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

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

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

  • cacheName

    स्ट्रिंग

  • fetchOptions

    requestInit ज़रूरी नहीं

  • matchOptions

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

    WorkboxPlugin[]

  • _awaitComplete

    void

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

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

    • responseDone

      वादा<Response>

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      Promise<void>

  • _getResponse

    void

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

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

    • हैंडलर

      StrategyHandler

    • CANNOT TRANSLATE

      अनुरोध

    • इवेंट

      ExtendableEvent

    • returns

      वादा<Response>

  • _हैंडल

    void

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

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

StrategyHandler

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

प्रॉपर्टी

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

    void

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

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

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

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

  • इवेंट

    ExtendableEvent

  • params

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

  • CANNOT TRANSLATE

    अनुरोध

  • यूआरएल

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

  • cacheMatch

    void

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

    इस तरीके का इस्तेमाल करते समय, प्लगिन के नीचे दिए गए लाइफ़साइकल तरीकों को शुरू किया जाता है:

    • cacheKeyWillByUsed()
    • cachedResponseWillByUsed()

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

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

    • बटन

      RequestInfo

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

    • returns

      वादा<Response>

      अगर मिलता-जुलता जवाब मिला हो, तो उसे.

  • cachePut

    void

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

    इस तरीके का इस्तेमाल करते समय, प्लगिन के नीचे दिए गए लाइफ़साइकल तरीकों को शुरू किया जाता है:

    • cacheKeyWillByUsed()
    • cacheWillUpdate()
    • cacheDidUpdate()

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

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

    • बटन

      RequestInfo

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

    • जवाब

      जवाब

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

    • returns

      Promise<boolean>

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

  • destroy

    void

    रणनीति को चलाना बंद कर देता है और waitUntil() से जुड़े सभी अधूरे वादों को तुरंत ठीक कर देता है.

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

    ()=> {...}

  • doneWaiting

    void

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

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

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

    ()=> {...}

    • returns

      Promise<void>

  • fetch

    void

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

    इस तरीके का इस्तेमाल करते समय, प्लगिन के नीचे दिए गए लाइफ़साइकल तरीकों को शुरू किया जाता है:

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

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

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

    • इनपुट

      RequestInfo

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

    • returns

      वादा<Response>

  • fetchAndCachePut

    void

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

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

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

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

    • इनपुट

      RequestInfo

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

    • returns

      वादा<Response>

  • getCacheKey

    void

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

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

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

    • CANNOT TRANSLATE

      अनुरोध

    • मोड

      "read"
      |"write"

    • returns

      वादा<अनुरोध>

  • hasCallback

    void

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

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

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

    • नाम

      C

      जांच करने के लिए कॉलबैक का नाम.

    • returns

      boolean

  • iterateCallbacks

    void

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

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

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

    • नाम

      C

      कॉलबैक को चलाने के लिए उसका नाम

    • returns

      जनरेटर<NonNullable<indexedAccess>anyunknown>

  • runCallbacks

    void

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

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

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

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

    • नाम

      C

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

    • पैरामीटर

      <indexedAccess"state"
      > हटाएं

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

    • returns

      Promise<void>

  • waitUntil

    void

    जिस इवेंट को मैनेज किया जा रहा है उससे जुड़े इवेंट इवेंट के लिए, [Extendend endend फ़ौरन मिटाए]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

    CashQueryOptions ज़रूरी नहीं

  • प्लगिन

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