ウェブサーバーにデータを送信すると、リクエストが失敗することがあります。これは、 ユーザーの接続が失われたり、 サーバーがダウンしています。いずれの場合も、リクエストの送信を試行し、 後でもう一度試します。
新しい BackgroundSync API
この問題の理想的なソリューションです。Service Worker がユーザーの
ネットワーク リクエストが失敗した場合、sync
イベントを受信するように登録できます。
ブラウザが接続が回復したと判断したときに配信されます。
なお、ユーザーが Google Chat を離れても、同期イベントは
従来の方法よりもはるかに効率的です。
失敗したリクエストを再試行します。
Workbox Background Sync は、 BackgroundSync API を実装し、その使用を他のワークボックス モジュールと統合します。これは、 ブラウザが代替機能に対応している場合に、 BackgroundSync
BackgroundSync API をサポートするブラウザでは、自動的にリプレイが失敗します お客様に代わって ブラウザで管理される間隔 リプレイの試行間に指数バックオフが 使用されている可能性が高いからですブラウザが BackgroundSync API をネイティブにサポートしていない場合、Workbox Background Sync は Service Worker が起動するたびに自動的にリプレイが試行されます。
基本的な使用法
Background Sync を使用する最も簡単な方法は、Plugin
失敗したリクエストを自動的にキューに入れ、将来の sync
発生します。
import {BackgroundSyncPlugin} from 'workbox-background-sync';
import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
const bgSyncPlugin = new BackgroundSyncPlugin('myQueueName', {
maxRetentionTime: 24 * 60, // Retry for max of 24 Hours (specified in minutes)
});
registerRoute(
/\/api\/.*\/*.json/,
new NetworkOnly({
plugins: [bgSyncPlugin],
}),
'POST'
);
BackgroundSyncPlugin
は、
fetchDidFail
プラグインのコールバック
fetchDidFail
は、例外がスローされた場合にのみ呼び出されます。
判断できますつまり、タイムアウトが発生してもリクエストは再試行されません。
レスポンスを
4xx
または 5xx
のエラー ステータス。
結果的に 5xx
ステータスになったすべてのリクエストを再試行する場合は、
これを行うには、
fetchDidSucceed
プラグインの追加
戦略に
const statusPlugin = {
fetchDidSucceed: ({response}) => {
if (response.status >= 500) {
// Throwing anything here will trigger fetchDidFail.
throw new Error('Server error.');
}
// If it's not 5xx, use the response as-is.
return response;
},
};
// Add statusPlugin to the plugins array in your strategy.
高度な使用方法
Workbox Background Sync には、Queue
クラスも用意されています。
失敗したリクエストをインスタンス化して追加します失敗したリクエストは、
IndexedDB 内
接続が復元されたことをブラウザが判断したときに再試行されます(つまり、
呼び出すことができます)。
キューの作成
Workbox のバックグラウンド同期キューを作成するには、 キュー名(プロジェクトに固有の origin):
import {Queue} from 'workbox-background-sync';
const queue = new Queue('myQueueName');
キュー名は、タグ名の一部として
register()
- 編集
世界全体で
SyncManager
。です。
「新規顧客の獲得」目標を
オブジェクト ストア名
IndexedDB データベースを使用します。
リクエストをキューに追加する
Queue インスタンスを作成したら、失敗したリクエストをキュー インスタンスに追加できます。
失敗したリクエストを追加するには、.pushRequest()
メソッドを呼び出します。たとえば
次のコードは、失敗したリクエストをすべてキャッチしてキューに追加します。
import {Queue} from 'workbox-background-sync';
const queue = new Queue('myQueueName');
self.addEventListener('fetch', event => {
// Add in your own criteria here to return early if this
// isn't a request that should use background sync.
if (event.request.method !== 'POST') {
return;
}
const bgSyncLogic = async () => {
try {
const response = await fetch(event.request.clone());
return response;
} catch (error) {
await queue.pushRequest({request: event.request});
return error;
}
};
event.respondWith(bgSyncLogic());
});
キューに追加されたリクエストは、
Service Worker が sync
イベントを受信します(これはブラウザが
接続が回復したと判断した)
BackgroundSync API は、Service Worker が更新されるたびにキューを再試行します。
起動しました。そのためには、Service Worker をコントロールするページで、
それほど効果は得られません
Workbox のバックグラウンド同期のテスト
残念ながら、BackgroundSync のテストはやや直感的でなく難しく、 さまざまな理由があります
実装をテストする最善の方法として、次のことを行います。
- ページを読み込み、Service Worker を登録します。
- パソコンのネットワークやウェブサーバーをオフにします。
- Chrome DevTools をオフラインで使用しないでください。オフライン チェックボックスは DevTools は、ページからのリクエストにのみ影響します。Service Worker リクエスト 引き続き処理が行われます。
- Workbox Background Sync でキューに入れるべきネットワーク リクエストを作成します。
- リクエストがキューに追加されたことは、
Chrome DevTools > Application > IndexedDB > workbox-background-sync > requests
- リクエストがキューに追加されたことは、
- ネットワークまたはウェブサーバーをオンにします。
以下に移動して、早期の
sync
イベントを強制します。Chrome DevTools > Application > Service Workers
、タグ名をworkbox-background-sync:<your queue name>
(<your queue name>
は) キューの名前を入力して [同期] ボタンを] ボタンを離します。失敗したリクエストに対してネットワーク リクエストが実行されていることと、 リクエストはすでに完了しているため、IndexedDB のデータは空になっているはずです。 正常に再生できました。
型
BackgroundSyncPlugin
fetchDidFail
ライフサイクル コールバックを実装するクラス。これにより、
失敗したリクエストをバックグラウンド同期キューに追加しやすくなりました。
プロパティ
-
コンストラクタ
void
constructor
関数は次のようになります。(name: string, options?: QueueOptions) => {...}
-
name
文字列
workbox-background-sync.Queue
をご覧ください。 のドキュメントをご覧ください。 -
オプション
QueueOptions(省略可)
-
Queue
失敗したリクエストを IndexedDB に保存し、再試行を管理するためのクラス 後で説明します保存と再生プロセスのすべての部分は、 使用できます。
プロパティ
-
コンストラクタ
void
指定されたオプションでキューのインスタンスを作成する
constructor
関数は次のようになります。(name: string, options?: QueueOptions) => {...}
-
name
文字列
このキューの一意の名前。この名前は 同期イベントの登録とリクエストの保存に使用されるため、一意です。 IndexedDB に記録されます。次の場合、エラーがスローされます。 名前の重複が検出されます。
-
オプション
QueueOptions(省略可)
-
戻り値
-
-
name
文字列
-
getAll
void
有効期限が切れていないすべてのエントリを返します(
maxRetentionTime
単位)。 期限切れのエントリはキューから削除されます。getAll
関数は次のようになります。() => {...}
-
戻り値
Promise<QueueEntry[]>
-
-
popRequest
void
キュー内の最後のリクエスト(およびそのリクエスト)を あります。返されるオブジェクトの形式は次のとおりです。
{request, timestamp, metadata}
。popRequest
関数は次のようになります。() => {...}
-
戻り値
Promise<QueueEntry>
-
-
pushRequest
void
渡されたリクエストを IndexedDB に保存します(タイムスタンプと metadata)に追加されます。
pushRequest
関数は次のようになります。(entry: QueueEntry) => {...}
-
必要事項を入力します。
QueueEntry
-
戻り値
約束 <void>
-
-
registerSync
void
このインスタンスに固有のタグで同期イベントを登録します。
registerSync
関数は次のようになります。() => {...}
-
戻り値
約束 <void>
-
-
replayRequests
void
キュー内の各リクエストをループし、再取得を試みます。 いずれかのリクエストが再取得に失敗した場合、そのリクエストは キュー(次の同期イベントの再試行を登録します)。
replayRequests
関数は次のようになります。() => {...}
-
戻り値
約束 <void>
-
-
shiftRequest
void
キュー内の最初のリクエストを削除して返します( あります。返されるオブジェクトの形式は次のとおりです。
{request, timestamp, metadata}
。shiftRequest
関数は次のようになります。() => {...}
-
戻り値
Promise<QueueEntry>
-
-
サイズ
void
キュー内のエントリ数を返します。 この数には、(
maxRetentionTime
あたり)期限切れのエントリも含まれます。size
関数は次のようになります。() => {...}
-
戻り値
Promise<number>
-
-
unshiftRequest
void
渡されたリクエストを IndexedDB に保存します(タイムスタンプと metadata)です。
unshiftRequest
関数は次のようになります。(entry: QueueEntry) => {...}
-
必要事項を入力します。
QueueEntry
-
戻り値
約束 <void>
-
QueueOptions
プロパティ
-
forceSyncFallback
ブール値(省略可)
-
maxRetentionTime
数値(省略可)
-
onSync
OnSyncCallback(省略可)
QueueStore
IndexedDB のキューからの保存リクエストを管理するためのクラス。 キュー名でインデックスが作成されます。
ほとんどのデベロッパーは、このクラスに直接アクセスする必要はありません。 高度なユースケース向けに公開されています
プロパティ
-
コンストラクタ
void
このインスタンスをキュー インスタンスに関連付けて、追加されたエントリを キュー名で識別されます。
constructor
関数は次のようになります。(queueName: string) => {...}
-
queueName
文字列
-
戻り値
-
-
deleteEntry
void
指定された ID のエントリを削除します。
警告: この方法では、削除されたエントリがこのエントリに属することが保証されるわけではありません キューに格納されます(つまり、
queueName
と一致します)。ただし、この制限は許容されます。 このクラスは公開されていません。さらに確認すると このメソッドが必要以上に遅くなります。deleteEntry
関数は次のようになります。(id: number) => {...}
-
id
数値
-
戻り値
約束 <void>
-
-
getAll
void
queueName
に一致するストア内のすべてのエントリを返します。getAll
関数は次のようになります。() => {...}
-
戻り値
Promise<QueueStoreEntry[]>
-
-
popEntry
void
queueName
に一致するキューの最後のエントリを削除して返します。popEntry
関数は次のようになります。() => {...}
-
戻り値
Promise<QueueStoreEntry>
-
-
pushEntry
void
エントリをキューの最後に追加します。
pushEntry
関数は次のようになります。(entry: UnidentifiedQueueStoreEntry) => {...}
-
必要事項を入力します。
UnidentifiedQueueStoreEntry
-
戻り値
約束 <void>
-
-
shiftEntry
void
queueName
に一致するキュー内の最初のエントリを削除して返します。shiftEntry
関数は次のようになります。() => {...}
-
戻り値
Promise<QueueStoreEntry>
-
-
サイズ
void
queueName
に一致するストア内のエントリ数を返します。size
関数は次のようになります。() => {...}
-
戻り値
Promise<number>
-
-
unshiftEntry
void
エントリをキューの先頭に追加します。
unshiftEntry
関数は次のようになります。(entry: UnidentifiedQueueStoreEntry) => {...}
-
必要事項を入力します。
UnidentifiedQueueStoreEntry
-
戻り値
約束 <void>
-
StorableRequest
リクエストのシリアル化 / シリアル化解除を簡単に行えるようにするクラス。 IndexedDB に保存できます。
ほとんどのデベロッパーは、このクラスに直接アクセスする必要はありません。 高度なユースケース向けに公開されています
プロパティ
-
コンストラクタ
void
使用できるリクエスト データのオブジェクトを受け入れて、
Request
ですが、IndexedDB に保存することもできます。constructor
関数は次のようになります。(requestData: RequestData) => {...}
-
requestData
RequestData
リクエスト データのオブジェクト。
url
と、次の関連プロパティ: [requestInit]https://fetch.spec.whatwg.org/#requestinit
。
-
-
clone
void
インスタンスのディープ クローンを作成して返します。
clone
関数は次のようになります。() => {...}
-
toObject
void
インスタンス
_requestData
オブジェクトのディープ クローンを返します。toObject
関数は次のようになります。() => {...}
-
戻り値
RequestData
-
-
toRequest
void
このインスタンスをリクエストに変換します。
toRequest
関数は次のようになります。() => {...}
-
戻り値
リクエスト
-
-
fromRequest
void
Request オブジェクトを、構造化可能なプレーン オブジェクトに変換します。 JSON 文字列化されます。
fromRequest
関数は次のようになります。(request: Request) => {...}
-
request
リクエスト
-
戻り値
Promise<StorableRequest>
-