جعبه کار - استراتژی ها

وقتی سرویس ورکرها برای اولین بار معرفی شدند، مجموعه‌ای از استراتژی‌های رایج ذخیره‌سازی پدیدار شدند. استراتژی ذخیره‌سازی الگویی است که تعیین می‌کند یک سرویس ورکرها چگونه پس از دریافت یک رویداد واکشی، پاسخی تولید کنند.

workbox-strategies رایج‌ترین استراتژی‌های ذخیره‌سازی را ارائه می‌دهد، بنابراین اعمال آنها در service worker شما آسان است.

ما به جزئیات بیشتری خارج از استراتژی‌های پشتیبانی‌شده توسط Workbox نمی‌پردازیم، اما می‌توانید در کتاب آشپزی آفلاین اطلاعات بیشتری کسب کنید .

استفاده از استراتژی‌ها

در مثال‌های زیر، نحوه استفاده از استراتژی‌های ذخیره‌سازی Workbox با workbox-routing را به شما نشان خواهیم داد. گزینه‌هایی وجود دارد که می‌توانید با هر استراتژی تعریف کنید که در بخش پیکربندی استراتژی‌ها در این سند پوشش داده شده‌اند.

در بخش استفاده پیشرفته ، نحوه استفاده مستقیم از استراتژی‌های ذخیره‌سازی بدون استفاده از 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());

فقط حافظه پنهان

نمودار فقط حافظه پنهان

استراتژی فقط کش تضمین می‌کند که پاسخ‌ها از یک کش دریافت می‌شوند. این مورد در workbox کمتر رایج است، اما اگر مرحله precaching مخصوص به خودتان را داشته باشید، می‌تواند مفید باشد.

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

استفاده از افزونه‌ها

ورک‌باکس با مجموعه‌ای از افزونه‌ها ارائه می‌شود که می‌توانند با این استراتژی‌ها مورد استفاده قرار گیرند.

برای استفاده از هر یک از این افزونه‌ها (یا یک افزونه سفارشی)، فقط باید نمونه‌ها را به گزینه 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 به شما امکان می‌دهد استراتژی‌های سفارشی خود را ایجاد کنید. این کار را می‌توان با وارد کردن و گسترش کلاس پایه Strategy از workbox-strategies انجام داد:

import {Strategy} from 'workbox-strategies';

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

در این مثال، handle() به عنوان یک استراتژی درخواست برای تعریف منطق خاص مدیریت استفاده می‌شود. دو استراتژی درخواست وجود دارد که می‌توان از آنها استفاده کرد:

  • handle() : یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.
  • handleAll() : مشابه handle() است، اما دو شیء Promise را برمی‌گرداند. اولی معادل چیزی است که handle() برمی‌گرداند و دومی زمانی حل می‌شود که promiseهایی که به event.waitUntil() در استراتژی اضافه شده‌اند، تکمیل شوند.

هر دو استراتژی درخواست با دو پارامتر فراخوانی می‌شوند:

  • request : Request که استراتژی برای آن پاسخی برمی‌گرداند.
  • handler : یک نمونه StrategyHandler که به طور خودکار برای استراتژی فعلی ایجاد می‌شود.

ایجاد یک استراتژی جدید

در ادامه مثالی از یک استراتژی جدید که رفتار NetworkOnly را مجدداً پیاده‌سازی می‌کند، آورده شده است:

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

توجه کنید که چگونه به جای متد بومی fetch handler.fetch() فراخوانی شده است. کلاس StrategyHandler تعدادی عمل fetch و cache ارائه می‌دهد که می‌توانند هر زمان که handle() یا handleAll() استفاده می‌شود، مورد استفاده قرار گیرند:

  • fetch : یک درخواست داده شده را دریافت می‌کند و متدهای چرخه عمر افزونه requestWillFetch() ، fetchDidSucceed() و fetchDidFail() را فراخوانی می‌کند.
  • cacheMatch : یک درخواست از حافظه پنهان را تطبیق می‌دهد و متدهای چرخه عمر افزونه‌های cacheKeyWillBeUsed() و cachedResponseWillBeUsed() را فراخوانی می‌کند.
  • cachePut : یک جفت درخواست/پاسخ را در حافظه پنهان قرار می‌دهد و متدهای چرخه عمر افزونه‌های cacheKeyWillBeUsed() ، cacheWillUpdate() و cacheDidUpdate() را فراخوانی می‌کند.
  • fetchAndCachePut : تابع fetch() را فراخوانی کرده و cachePut() را در پس‌زمینه روی پاسخ تولید شده توسط fetch() اجرا می‌کند.
  • hasCallback : یک callback را به عنوان ورودی می‌گیرد و اگر استراتژی حداقل یک افزونه با callback داده شده داشته باشد، مقدار true را برمی‌گرداند.
  • runCallbacks : تمام فراخوانی‌های افزونه‌ای که با یک نام مشخص مطابقت دارند را به ترتیب اجرا می‌کند و یک شیء param مشخص (که با وضعیت افزونه فعلی ادغام شده است) را به عنوان تنها آرگومان ارسال می‌کند.
  • iterateCallbacks : یک فراخوانی برگشتی را می‌پذیرد و مجموعه‌ای از فراخوانی‌های پلاگین منطبق را برمی‌گرداند، که در آن هر فراخوانی برگشتی با وضعیت فعلی کنترل‌کننده پوشش داده می‌شود (یعنی وقتی هر فراخوانی برگشتی را فراخوانی می‌کنید، هر پارامتر شیء که ارسال می‌کنید با وضعیت فعلی پلاگین ادغام می‌شود).
  • waitUntil : یک promise به promise های با طول عمر طولانی رویداد مرتبط با درخواست در حال پردازش (معمولاً یک FetchEvent ) اضافه می‌کند.
  • doneWaiting : یک promise را برمی‌گرداند که به محض اینکه تمام promiseهای ارسال شده به waitUntil() حل و فصل شوند، اجرا می‌شود.
  • destroy : اجرای استراتژی را متوقف می‌کند و بلافاصله هرگونه promise در حال انتظار waitUntil() را حل می‌کند.

استراتژی رقابتی شبکه کش سفارشی

مثال زیر بر اساس cache-network-race از کتاب آشپزی آفلاین (که Workbox آن را ارائه نمی‌دهد) است، اما یک قدم فراتر می‌رود و همیشه پس از یک درخواست موفق شبکه، حافظه پنهان را به‌روزرسانی می‌کند. این مثالی از یک استراتژی پیچیده‌تر است که از چندین اقدام استفاده می‌کند. 

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

کاربرد پیشرفته

اگر می‌خواهید از استراتژی‌ها در منطق رویداد واکشی خود استفاده کنید، می‌توانید از کلاس‌های استراتژی برای اجرای یک درخواست از طریق یک استراتژی خاص استفاده کنید.

برای مثال، برای استفاده از استراتژی stale-while-revalidate، می‌توانید موارد زیر را انجام دهید: 

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

پیاده‌سازی استراتژی درخواست cache-first .

استراتژی cache first برای فایل‌هایی که قبلاً ویرایش شده‌اند، مانند URLهایی مانند /styles/example.a8f5f1.css ، مفید است، زیرا می‌توانند برای مدت طولانی در حافظه پنهان (cache) ذخیره شوند.

اگر درخواست شبکه با شکست مواجه شود و هیچ تطابقی در حافظه پنهان وجود نداشته باشد، این یک خطای WorkboxError ایجاد می‌کند.

خواص

  • سازنده

    باطل

    یک نمونه جدید از استراتژی ایجاد می‌کند و تمام ویژگی‌های گزینه مستند شده را به عنوان ویژگی‌های نمونه عمومی تنظیم می‌کند.

    نکته: اگر یک کلاس استراتژی سفارشی، کلاس پایه استراتژی را توسعه دهد و به بیش از این ویژگی‌ها نیاز نداشته باشد، نیازی به تعریف سازنده مخصوص به خود ندارد.

    تابع constructor به شکل زیر است: 

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

  • نام حافظه پنهان

    رشته

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • _awaitکامل

    باطل

    تابع _awaitComplete به شکل زیر است: 

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

    • پاسخانجام شد

      قول<پاسخ>

    • رسیدگی کننده

      استراتژی هندلر

    • درخواست

      درخواست

    • رویداد

      رویداد قابل توسعه

    • بازده

      قول<void>

  • _getResponse

    باطل

    تابع _getResponse به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • رسیدگی

    باطل

    یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.

    وقتی یک نمونه استراتژی با Workbox workbox-routing.Route ثبت می‌شود، این متد به طور خودکار هنگام تطابق مسیر فراخوانی می‌شود.

    به عنوان یک روش جایگزین، می‌توان این متد را با ارسال به event.respondWith() در یک شنونده‌ی مستقل FetchEvent استفاده کرد.

    تابع handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • همه را مدیریت کنید

    باطل

    مشابه workbox-strategies.Strategy~handle ، اما به جای اینکه فقط یک Promise که به یک Response ختم می‌شود، برگرداند، یک چندتایی از Promiseهای [response, done] را برمی‌گرداند، که اولی ( response ) معادل چیزی است که handle() برمی‌گرداند، و دومی Promise ای است که پس از تکمیل هر Promise اضافه شده به event.waitUntil() به عنوان بخشی از اجرای strategy، حل خواهد شد.

    شما می‌توانید منتظر « done » بمانید تا مطمئن شوید که هرگونه کار اضافی انجام شده توسط استراتژی (معمولاً ذخیره‌سازی پاسخ‌ها) با موفقیت انجام می‌شود.

    تابع handleAll به صورت زیر است: 

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

    • بازده

      [قول <پاسخ>، قول <باطل>]

      یک چندتایی از promise های [response, done] که می‌توانند برای تعیین زمان حل شدن پاسخ و همچنین زمان اتمام تمام کارهای هندلر استفاده شوند.

CacheOnly

پیاده‌سازی استراتژی درخواست فقط-حافظه پنهان .

این کلاس در صورتی مفید است که بخواهید از هرگونه افزونه Workbox بهره ببرید.

اگر هیچ تطابقی در حافظه پنهان وجود نداشته باشد، این یک خطای WorkboxError ایجاد می‌کند.

خواص

  • سازنده

    باطل

    یک نمونه جدید از استراتژی ایجاد می‌کند و تمام ویژگی‌های گزینه مستند شده را به عنوان ویژگی‌های نمونه عمومی تنظیم می‌کند.

    نکته: اگر یک کلاس استراتژی سفارشی، کلاس پایه استراتژی را توسعه دهد و به بیش از این ویژگی‌ها نیاز نداشته باشد، نیازی به تعریف سازنده مخصوص به خود ندارد.

    تابع constructor به شکل زیر است: 

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

  • نام حافظه پنهان

    رشته

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • _awaitکامل

    باطل

    تابع _awaitComplete به شکل زیر است: 

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

    • پاسخانجام شد

      قول<پاسخ>

    • رسیدگی کننده

      استراتژی هندلر

    • درخواست

      درخواست

    • رویداد

      رویداد قابل توسعه

    • بازده

      قول<void>

  • _getResponse

    باطل

    تابع _getResponse به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • رسیدگی

    باطل

    یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.

    وقتی یک نمونه استراتژی با Workbox workbox-routing.Route ثبت می‌شود، این متد به طور خودکار هنگام تطابق مسیر فراخوانی می‌شود.

    به عنوان یک روش جایگزین، می‌توان این متد را با ارسال به event.respondWith() در یک شنونده‌ی مستقل FetchEvent استفاده کرد.

    تابع handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • همه را مدیریت کنید

    باطل

    مشابه workbox-strategies.Strategy~handle ، اما به جای اینکه فقط یک Promise که به یک Response ختم می‌شود، برگرداند، یک چندتایی از Promiseهای [response, done] را برمی‌گرداند، که اولی ( response ) معادل چیزی است که handle() برمی‌گرداند، و دومی Promise ای است که پس از تکمیل هر Promise اضافه شده به event.waitUntil() به عنوان بخشی از اجرای strategy، حل خواهد شد.

    شما می‌توانید منتظر « done » بمانید تا مطمئن شوید که هرگونه کار اضافی انجام شده توسط استراتژی (معمولاً ذخیره‌سازی پاسخ‌ها) با موفقیت انجام می‌شود.

    تابع handleAll به صورت زیر است: 

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

    • بازده

      [قول <پاسخ>، قول <باطل>]

      یک چندتایی از promise های [response, done] که می‌توانند برای تعیین زمان حل شدن پاسخ و همچنین زمان اتمام تمام کارهای هندلر استفاده شوند.

NetworkFirst

پیاده‌سازی استراتژی درخواست مبتنی بر شبکه (Network First Request Strategy).

به طور پیش‌فرض، این استراتژی پاسخ‌هایی با کد وضعیت ۲۰۰ و همچنین پاسخ‌های مبهم را ذخیره می‌کند. پاسخ‌های مبهم، درخواست‌های بین‌منبعی هستند که در آن‌ها پاسخ از CORS پشتیبانی نمی‌کند.

اگر درخواست شبکه با شکست مواجه شود و هیچ تطابقی در حافظه پنهان وجود نداشته باشد، این یک خطای WorkboxError ایجاد می‌کند.

خواص

  • سازنده

    باطل

    تابع constructor به شکل زیر است: 

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

  • نام حافظه پنهان

    رشته

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • _awaitکامل

    باطل

    تابع _awaitComplete به شکل زیر است: 

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

    • پاسخانجام شد

      قول<پاسخ>

    • رسیدگی کننده

      استراتژی هندلر

    • درخواست

      درخواست

    • رویداد

      رویداد قابل توسعه

    • بازده

      قول<void>

  • _getResponse

    باطل

    تابع _getResponse به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • رسیدگی

    باطل

    یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.

    وقتی یک نمونه استراتژی با Workbox workbox-routing.Route ثبت می‌شود، این متد به طور خودکار هنگام تطابق مسیر فراخوانی می‌شود.

    به عنوان یک روش جایگزین، می‌توان این متد را با ارسال به event.respondWith() در یک شنونده‌ی مستقل FetchEvent استفاده کرد.

    تابع handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • همه را مدیریت کنید

    باطل

    مشابه workbox-strategies.Strategy~handle ، اما به جای اینکه فقط یک Promise که به یک Response ختم می‌شود، برگرداند، یک چندتایی از Promiseهای [response, done] را برمی‌گرداند، که اولی ( response ) معادل چیزی است که handle() برمی‌گرداند، و دومی Promise ای است که پس از تکمیل هر Promise اضافه شده به event.waitUntil() به عنوان بخشی از اجرای strategy، حل خواهد شد.

    شما می‌توانید منتظر « done » بمانید تا مطمئن شوید که هرگونه کار اضافی انجام شده توسط استراتژی (معمولاً ذخیره‌سازی پاسخ‌ها) با موفقیت انجام می‌شود.

    تابع handleAll به صورت زیر است: 

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

    • بازده

      [قول <پاسخ>، قول <باطل>]

      یک چندتایی از promise های [response, done] که می‌توانند برای تعیین زمان حل شدن پاسخ و همچنین زمان اتمام تمام کارهای هندلر استفاده شوند.

NetworkFirstOptions

خواص

  • نام حافظه پنهان

    رشته اختیاری

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • networkTimeoutSeconds

    شماره اختیاری

  • افزونه‌ها

    افزونه‌ی WorkboxPlugin [] اختیاری

NetworkOnly

پیاده‌سازی استراتژی درخواست فقط از طریق شبکه .

این کلاس در صورتی مفید است که بخواهید از هرگونه افزونه Workbox بهره ببرید.

اگر درخواست شبکه با شکست مواجه شود، این یک خطای WorkboxError ایجاد می‌کند.

خواص

  • سازنده

    باطل

    تابع constructor به شکل زیر است: 

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

  • نام حافظه پنهان

    رشته

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • _awaitکامل

    باطل

    تابع _awaitComplete به شکل زیر است: 

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

    • پاسخانجام شد

      قول<پاسخ>

    • رسیدگی کننده

      استراتژی هندلر

    • درخواست

      درخواست

    • رویداد

      رویداد قابل توسعه

    • بازده

      قول<void>

  • _getResponse

    باطل

    تابع _getResponse به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • رسیدگی

    باطل

    یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.

    وقتی یک نمونه استراتژی با Workbox workbox-routing.Route ثبت می‌شود، این متد به طور خودکار هنگام تطابق مسیر فراخوانی می‌شود.

    به عنوان یک روش جایگزین، می‌توان این متد را با ارسال به event.respondWith() در یک شنونده‌ی مستقل FetchEvent استفاده کرد.

    تابع handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • همه را مدیریت کنید

    باطل

    مشابه workbox-strategies.Strategy~handle ، اما به جای اینکه فقط یک Promise که به یک Response ختم می‌شود، برگرداند، یک چندتایی از Promiseهای [response, done] را برمی‌گرداند، که اولی ( response ) معادل چیزی است که handle() برمی‌گرداند، و دومی Promise ای است که پس از تکمیل هر Promise اضافه شده به event.waitUntil() به عنوان بخشی از اجرای strategy، حل خواهد شد.

    شما می‌توانید منتظر « done » بمانید تا مطمئن شوید که هرگونه کار اضافی انجام شده توسط استراتژی (معمولاً ذخیره‌سازی پاسخ‌ها) با موفقیت انجام می‌شود.

    تابع handleAll به صورت زیر است: 

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

    • بازده

      [قول <پاسخ>، قول <باطل>]

      یک چندتایی از promise های [response, done] که می‌توانند برای تعیین زمان حل شدن پاسخ و همچنین زمان اتمام تمام کارهای هندلر استفاده شوند.

NetworkOnlyOptions

خواص

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • networkTimeoutSeconds

    شماره اختیاری

  • افزونه‌ها

    افزونه‌ی WorkboxPlugin [] اختیاری

StaleWhileRevalidate

پیاده‌سازی استراتژی درخواست‌های stale-while-revalidate .

منابع به صورت موازی از حافظه پنهان و شبکه درخواست می‌شوند. در صورت وجود، استراتژی با نسخه ذخیره شده در حافظه پنهان پاسخ می‌دهد، در غیر این صورت منتظر پاسخ شبکه می‌ماند. حافظه پنهان با پاسخ شبکه با هر درخواست موفق به‌روزرسانی می‌شود.

به طور پیش‌فرض، این استراتژی پاسخ‌هایی با کد وضعیت ۲۰۰ و همچنین پاسخ‌های مبهم را ذخیره می‌کند. پاسخ‌های مبهم، درخواست‌های بین‌منبعی هستند که در آن‌ها پاسخ از CORS پشتیبانی نمی‌کند.

اگر درخواست شبکه با شکست مواجه شود و هیچ تطابقی در حافظه پنهان وجود نداشته باشد، این یک خطای WorkboxError ایجاد می‌کند.

خواص

  • سازنده

    باطل

    تابع constructor به شکل زیر است: 

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

  • نام حافظه پنهان

    رشته

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • _awaitکامل

    باطل

    تابع _awaitComplete به شکل زیر است: 

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

    • پاسخانجام شد

      قول<پاسخ>

    • رسیدگی کننده

      استراتژی هندلر

    • درخواست

      درخواست

    • رویداد

      رویداد قابل توسعه

    • بازده

      قول<void>

  • _getResponse

    باطل

    تابع _getResponse به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • رسیدگی

    باطل

    یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.

    وقتی یک نمونه استراتژی با Workbox workbox-routing.Route ثبت می‌شود، این متد به طور خودکار هنگام تطابق مسیر فراخوانی می‌شود.

    به عنوان یک روش جایگزین، می‌توان این متد را با ارسال به event.respondWith() در یک شنونده‌ی مستقل FetchEvent استفاده کرد.

    تابع handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • همه را مدیریت کنید

    باطل

    مشابه workbox-strategies.Strategy~handle ، اما به جای اینکه فقط یک Promise که به یک Response ختم می‌شود، برگرداند، یک چندتایی از Promiseهای [response, done] را برمی‌گرداند، که اولی ( response ) معادل چیزی است که handle() برمی‌گرداند، و دومی Promise ای است که پس از تکمیل هر Promise اضافه شده به event.waitUntil() به عنوان بخشی از اجرای strategy، حل خواهد شد.

    شما می‌توانید منتظر « done » بمانید تا مطمئن شوید که هرگونه کار اضافی انجام شده توسط استراتژی (معمولاً ذخیره‌سازی پاسخ‌ها) با موفقیت انجام می‌شود.

    تابع handleAll به صورت زیر است: 

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

    • بازده

      [قول <پاسخ>، قول <باطل>]

      یک چندتایی از promise های [response, done] که می‌توانند برای تعیین زمان حل شدن پاسخ و همچنین زمان اتمام تمام کارهای هندلر استفاده شوند.

Strategy

یک کلاس پایه انتزاعی که همه کلاس‌های استراتژی دیگر باید از آن مشتق شوند:

خواص

  • سازنده

    باطل

    یک نمونه جدید از استراتژی ایجاد می‌کند و تمام ویژگی‌های گزینه مستند شده را به عنوان ویژگی‌های نمونه عمومی تنظیم می‌کند.

    نکته: اگر یک کلاس استراتژی سفارشی، کلاس پایه استراتژی را توسعه دهد و به بیش از این ویژگی‌ها نیاز نداشته باشد، نیازی به تعریف سازنده مخصوص به خود ندارد.

    تابع constructor به شکل زیر است: 

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

  • نام حافظه پنهان

    رشته

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • _awaitکامل

    باطل

    تابع _awaitComplete به شکل زیر است: 

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

    • پاسخانجام شد

      قول<پاسخ>

    • رسیدگی کننده

      استراتژی هندلر

    • درخواست

      درخواست

    • رویداد

      رویداد قابل توسعه

    • بازده

      قول<void>

  • _getResponse

    باطل

    تابع _getResponse به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • دسته

    باطل

    تابع _handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • رسیدگی

    باطل

    یک استراتژی درخواست را اجرا می‌کند و یک Promise برمی‌گرداند که با یک Response حل می‌شود و تمام callbackهای افزونه مربوطه را فراخوانی می‌کند.

    وقتی یک نمونه استراتژی با Workbox workbox-routing.Route ثبت می‌شود، این متد به طور خودکار هنگام تطابق مسیر فراخوانی می‌شود.

    به عنوان یک روش جایگزین، می‌توان این متد را با ارسال به event.respondWith() در یک شنونده‌ی مستقل FetchEvent استفاده کرد.

    تابع handle به شکل زیر است: 

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

    • بازده

      قول<پاسخ>

  • همه را مدیریت کنید

    باطل

    مشابه workbox-strategies.Strategy~handle ، اما به جای اینکه فقط یک Promise که به یک Response ختم می‌شود، برگرداند، یک چندتایی از Promiseهای [response, done] را برمی‌گرداند، که اولی ( response ) معادل چیزی است که handle() برمی‌گرداند، و دومی Promise ای است که پس از تکمیل هر Promise اضافه شده به event.waitUntil() به عنوان بخشی از اجرای strategy، حل خواهد شد.

    شما می‌توانید منتظر « done » بمانید تا مطمئن شوید که هرگونه کار اضافی انجام شده توسط استراتژی (معمولاً ذخیره‌سازی پاسخ‌ها) با موفقیت انجام می‌شود.

    تابع handleAll به صورت زیر است: 

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

    • بازده

      [قول <پاسخ>، قول <باطل>]

      یک چندتایی از promise های [response, done] که می‌توانند برای تعیین زمان حل شدن پاسخ و همچنین زمان اتمام تمام کارهای هندلر استفاده شوند.

StrategyHandler

کلاسی که هر بار یک نمونه Strategy، workbox-strategies.Strategy~handle یا workbox-strategies.Strategy~handleAll فراخوانی می‌کند، ایجاد می‌شود. این کلاس تمام اقدامات fetch و cache را حول فراخوانی‌های افزونه قرار می‌دهد و زمان "انجام شدن" استراتژی را پیگیری می‌کند (یعنی تمام promiseهای event.waitUntil() اضافه شده، اجرا شده‌اند).

خواص

  • سازنده

    باطل

    یک نمونه جدید مرتبط با استراتژی و رویداد ارسالی که درخواست را مدیریت می‌کند، ایجاد می‌کند.

    سازنده همچنین حالتی را که به هر یک از افزونه‌های مدیریت‌کننده این درخواست ارسال خواهد شد، مقداردهی اولیه می‌کند.

    تابع constructor به شکل زیر است: 

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

  • رویداد

    رویداد قابل توسعه

  • پارامترها

    هر اختیاری

  • درخواست

    درخواست

  • آدرس اینترنتی

    آدرس اینترنتی (URL) اختیاری

  • کش مچ

    باطل

    با استفاده از cacheName ، matchOptions و plugins تعریف شده در شیء strategy، یک درخواست از حافظه پنهان (cache) را تطبیق می‌دهد (و هر متد فراخوانی افزونه مربوطه را فراخوانی می‌کند).

    هنگام استفاده از این روش، متدهای چرخه حیات افزونه زیر فراخوانی می‌شوند:

    • تابع ()cacheKeyWillBeUsed
    • تابع ()cacheedResponseWillBeUsed را فراخوانی می‌کند.

    تابع cacheMatch به شکل زیر است: 

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

    • کلید

      درخواست اطلاعات

      درخواست یا URL مورد نظر برای استفاده به عنوان کلید کش.

    • بازده

      قول<پاسخ>

      پاسخی منطبق، در صورت یافتن.

  • کش‌پوت

    باطل

    یک جفت درخواست/پاسخ را در حافظه پنهان قرار می‌دهد (و هر متد فراخوانی افزونه مربوطه را فراخوانی می‌کند) با استفاده از cacheName و plugins تعریف شده در شیء strategy.

    هنگام استفاده از این روش، متدهای چرخه حیات افزونه زیر فراخوانی می‌شوند:

    • تابع ()cacheKeyWillBeUsed
    • cacheWillUpdate()
    • cacheDidUpdate()

    تابع cachePut به شکل زیر است: 

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

    • کلید

      درخواست اطلاعات

      درخواست یا URL مورد استفاده به عنوان کلید حافظه پنهان.

    • پاسخ

      پاسخ

      پاسخ به حافظه پنهان.

    • بازده

      قول <boolean>

      اگر cacheWillUpdate باعث شود پاسخ ذخیره نشود، false و در غیر این صورت true برمی‌گرداند.

  • نابود کردن

    باطل

    اجرای استراتژی را متوقف می‌کند و بلافاصله هرگونه promise در حال انتظار waitUntil() را حل می‌کند.

    تابع destroy به شکل زیر است: 

    () => {...}

  • انجام شددر انتظار

    باطل

    یک promise را برمی‌گرداند که به محض اینکه تمام promise های ارسال شده به workbox-strategies.StrategyHandler~waitUntil حل و فصل شوند، حل و فصل می‌شود.

    نکته: هر کاری که پس از انجام تابع doneWaiting() انجام شود، باید به صورت دستی به متد waitUntil() یک رویداد (نه متد waitUntil() این هندلر) ارسال شود، در غیر این صورت ممکن است نخ سرویس ورکر قبل از اتمام کار شما از بین برود.

    تابع doneWaiting به شکل زیر است: 

    () => {...}

    • بازده

      قول<void>

  • واکشی کردن

    باطل

    با استفاده از fetchOptions (برای درخواست‌های غیر ناوبری) و plugins تعریف‌شده در شیء Strategy ، یک درخواست داده‌شده را دریافت می‌کند (و هرگونه متد فراخوانی افزونه‌ی مربوطه را فراخوانی می‌کند).

    هنگام استفاده از این روش، متدهای چرخه حیات افزونه زیر فراخوانی می‌شوند:

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

    تابع fetch به شکل زیر است: 

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

    • ورودی

      درخواست اطلاعات

      آدرس اینترنتی یا درخواست برای واکشی.

    • بازده

      قول<پاسخ>

  • واکشی و ذخیره سازی

    باطل

    تابع this.fetch() را فراخوانی می‌کند و (در پس‌زمینه) this.cachePut() را روی پاسخ تولید شده توسط this.fetch() اجرا می‌کند.

    فراخوانی this.cachePut() به طور خودکار this.waitUntil() فراخوانی می‌کند، بنابراین لازم نیست waitUntil() به صورت دستی در رویداد فراخوانی کنید.

    تابع fetchAndCachePut به شکل زیر است: 

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

    • ورودی

      درخواست اطلاعات

      درخواست یا URL برای واکشی و ذخیره سازی.

    • بازده

      قول<پاسخ>

  • کلید دریافت کش

    باطل

    لیست افزونه‌ها را برای فراخوانی cacheKeyWillBeUsed بررسی می‌کند و هر یک از فراخوانی‌های یافت شده را به ترتیب اجرا می‌کند. شیء Request نهایی که توسط آخرین افزونه برگردانده می‌شود، به عنوان کلید حافظه پنهان برای خواندن و/یا نوشتن در حافظه پنهان در نظر گرفته می‌شود. اگر هیچ فراخوانی افزونه cacheKeyWillBeUsed ثبت نشده باشد، درخواست ارسالی بدون تغییر برگردانده می‌شود.

    تابع getCacheKey به شکل زیر است: 

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

    • درخواست

      درخواست

    • حالت

      «خواندن»
      | «بنویس»

    • بازده

      قول<درخواست>

  • hasCallback

    باطل

    اگر استراتژی حداقل یک افزونه با فراخوانی داده شده داشته باشد، مقدار true را برمی‌گرداند.

    تابع hasCallback به شکل زیر است: 

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

    • نام

      سی

      نام فراخوانی که باید بررسی شود.

    • بازده

      بولی

  • تکرار فراخوانی‌های برگشتی

    باطل

    یک تابع فراخوانی (callback) را می‌پذیرد و مجموعه‌ای از توابع فراخوانی افزونه منطبق را برمی‌گرداند، که در آن هر تابع فراخوانی با وضعیت فعلی کنترل‌کننده (handler state) ادغام می‌شود (یعنی وقتی هر تابع فراخوانی را فراخوانی می‌کنید، هر پارامتر شیء که ارسال می‌کنید با وضعیت فعلی افزونه ادغام خواهد شد).

    تابع iterateCallbacks به شکل زیر است: 

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

    • نام

      سی

      نام فراخوانی برای اجرا

    • بازده

      مولد <NonNullable<indexedAccess>anyunknown>

  • اجرای فراخوانی‌های برگشتی

    باطل

    تمام فراخوانی‌های افزونه‌ای که با نام داده شده مطابقت دارند را به ترتیب اجرا می‌کند و شیء پارامتر داده شده (که با وضعیت افزونه فعلی ادغام شده است) را به عنوان تنها آرگومان ارسال می‌کند.

    توجه: از آنجایی که این روش تمام افزونه‌ها را اجرا می‌کند، برای مواردی که مقدار برگشتی یک تابع فراخوانی قبل از فراخوانی تابع فراخوانی بعدی باید اعمال شود، مناسب نیست. برای نحوه مدیریت این مورد، به workbox-strategies.StrategyHandler#iterateCallbacks در زیر مراجعه کنید.

    تابع runCallbacks به شکل زیر است: 

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

    • نام

      سی

      نام تابع فراخوانی که قرار است درون هر افزونه اجرا شود.

    • پارام

      حذف <indexedAccess "state"
      >

      شیء‌ای که به عنوان اولین (و تنها) پارامتر هنگام اجرای هر فراخوانی برگشتی ارسال می‌شود. این شیء قبل از اجرای فراخوانی برگشتی با وضعیت فعلی افزونه ادغام خواهد شد.

    • بازده

      قول<void>

  • صبر کنید تا

    باطل

    یک promise به [extend lifetime promises] https://w3c.github.io/ServiceWorker/#extendableevent-extend-lifetime-promises رویداد مرتبط با درخواست در حال پردازش (معمولاً یک FetchEvent ) اضافه می‌کند.

    نکته: می‌توانید منتظر بمانید تا ببینید چه زمانی همه promiseهای اضافه شده اجرا می‌شوند. (یا: می‌توانید منتظر بمانید workbox-strategies.StrategyHandler~doneWaiting تا بدانید چه زمانی همه promiseهای اضافه شده اجرا می‌شوند.)

    تابع waitUntil به شکل زیر است: 

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

    • وعده

      قول بده<T>

      وعده‌ای برای افزودن به وعده‌های طول عمر طولانی رویدادی که درخواست را فعال کرده است.

    • بازده

      قول بده<T>

StrategyOptions

خواص

  • نام حافظه پنهان

    رشته اختیاری

  • گزینه‌های واکشی

    درخواست شروع (اختیاری)

  • گزینه‌های تطبیق

    گزینه‌های CacheQuery اختیاری

  • افزونه‌ها

    افزونه‌ی WorkboxPlugin [] اختیاری