जब सर्विस वर्कर पहली बार पेश किए गए थे, तब सामान्य कैशिंग रणनीतियों का एक सेट उभरकर सामने आया. कैश मेमोरी की रणनीति एक ऐसा पैटर्न है जिससे तय होता है कि फ़ेच इवेंट मिलने के बाद सर्विस वर्कर कैसे रिस्पॉन्स जनरेट करता है.
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 में प्लगिन का एक सेट होता है, जिसे इन रणनीतियों के साथ इस्तेमाल किया जा सकता है.
- वर्कबॉक्स-बैकग्राउंड-सिंक
- workbox-broadcast-अपडेट
- workbox-cacheable-response
- वर्कबॉक्स खत्म होने की समयसीमा
- workbox-range-requests
इनमें से किसी भी प्लग इन (या किसी कस्टम प्लगिन) का इस्तेमाल करने के लिए, आपको बस 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) => {...}
-
विकल्प
StrategyOptions ज़रूरी नहीं
-
returns
-
-
cacheName
स्ट्रिंग
-
fetchOptions
requestInit ज़रूरी नहीं
-
matchOptions
CashQueryOptions ज़रूरी नहीं
-
प्लगिन
-
_awaitComplete
void
_awaitComplete
फ़ंक्शन ऐसा दिखता है:(responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
responseDone
वादा<Response>
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
Promise<void>
-
-
_getResponse
void
_getResponse
फ़ंक्शन ऐसा दिखता है:(handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
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) => {...}
-
विकल्प
StrategyOptions ज़रूरी नहीं
-
returns
-
-
cacheName
स्ट्रिंग
-
fetchOptions
requestInit ज़रूरी नहीं
-
matchOptions
CashQueryOptions ज़रूरी नहीं
-
प्लगिन
-
_awaitComplete
void
_awaitComplete
फ़ंक्शन ऐसा दिखता है:(responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
responseDone
वादा<Response>
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
Promise<void>
-
-
_getResponse
void
_getResponse
फ़ंक्शन ऐसा दिखता है:(handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
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) => {...}
-
विकल्प
NetworkFirstOptions ज़रूरी नहीं है
-
returns
-
-
cacheName
स्ट्रिंग
-
fetchOptions
requestInit ज़रूरी नहीं
-
matchOptions
CashQueryOptions ज़रूरी नहीं
-
प्लगिन
-
_awaitComplete
void
_awaitComplete
फ़ंक्शन ऐसा दिखता है:(responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
responseDone
वादा<Response>
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
Promise<void>
-
-
_getResponse
void
_getResponse
फ़ंक्शन ऐसा दिखता है:(handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
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) => {...}
-
विकल्प
NetworkOnlyOptions ज़रूरी नहीं
-
returns
-
-
cacheName
स्ट्रिंग
-
fetchOptions
requestInit ज़रूरी नहीं
-
matchOptions
CashQueryOptions ज़रूरी नहीं
-
प्लगिन
-
_awaitComplete
void
_awaitComplete
फ़ंक्शन ऐसा दिखता है:(responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
responseDone
वादा<Response>
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
Promise<void>
-
-
_getResponse
void
_getResponse
फ़ंक्शन ऐसा दिखता है:(handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
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) => {...}
-
विकल्प
StrategyOptions ज़रूरी नहीं
-
returns
-
-
cacheName
स्ट्रिंग
-
fetchOptions
requestInit ज़रूरी नहीं
-
matchOptions
CashQueryOptions ज़रूरी नहीं
-
प्लगिन
-
_awaitComplete
void
_awaitComplete
फ़ंक्शन ऐसा दिखता है:(responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
responseDone
वादा<Response>
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
Promise<void>
-
-
_getResponse
void
_getResponse
फ़ंक्शन ऐसा दिखता है:(handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
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) => {...}
-
विकल्प
StrategyOptions ज़रूरी नहीं
-
returns
-
-
cacheName
स्ट्रिंग
-
fetchOptions
requestInit ज़रूरी नहीं
-
matchOptions
CashQueryOptions ज़रूरी नहीं
-
प्लगिन
-
_awaitComplete
void
_awaitComplete
फ़ंक्शन ऐसा दिखता है:(responseDone: Promise<Response>, handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
responseDone
वादा<Response>
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
Promise<void>
-
-
_getResponse
void
_getResponse
फ़ंक्शन ऐसा दिखता है:(handler: StrategyHandler, request: Request, event: ExtendableEvent) => {...}
-
हैंडलर
-
CANNOT TRANSLATE
अनुरोध
-
event
ExtendableEvent
-
returns
वादा<Response>
-
-
_हैंडल
void
_handle
फ़ंक्शन ऐसा दिखता है:(request: Request, handler: StrategyHandler) => {...}
-
CANNOT TRANSLATE
अनुरोध
-
हैंडलर
-
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) => {...}
-
रणनीति वाले गेम
-
विकल्प
-
returns
-
-
event
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[] ज़रूरी नहीं है