👨🏻‍🎤 ⚾️ 💿 Service Workerを使用する際の微妙な点 🦇 🤳🏽 🎨

まえがき

今日のサービスワーカー（Service Worker、ご容赦ください）は、サイトの基本機能への便利な追加機能です。ここでは、オフライン作業、バックグラウンドデータの同期、トレンディなプッシュ通知を見つけることができます。

ただし、サービスワーカーに関する多くの記事は、かなり簡潔で、簡単な例を説明しています。サービスワーカーの作業のいくつかの機能に注意を向けようとするため、基本的な知識が必要です。出発点は、この記事（翻訳）またはもう少し詳細な記事です。

同じドメイン上の複数のサービスワーカー

特定のサービスワーカーの登録には、 スコープなどの概念があります。特定のドメインのどのページがその管理下に入るかを決定します。この場合、同じドメインに複数のService Workerを登録できますが、スコープは異なります。それらを別の名前で登録しようとすると、1つのスコープで、その後にインストールされたワーカーが彼の前の兄弟を「置き換え」ます。

ところで、上記のパスのサービスワーカーとして指定されたパスにファイルをインストールするために（この動作はデフォルトでは禁止されています。パスを増やしたり、パスを減らしたりできます）、 Service-Worker-Allowed http-headerを使用できます。

パラメーターなしのgetRegistration（）メソッドは、現在のページに適した、おそらく非アクティブなService Worker登録を返します。また、ネストされたパスに沿って、より適切でない場合は同じ登録を受け取ることを意味します。複数のサービスワーカーが同じドメインで作業すると予想される場合、これは驚きにつながる可能性があります。

例を見てみましょう：スコープ/を持つインストールされたService Workerがあります。それをニュースサイトにして、オフライン版のテキストを提供します。パス/ admin /に沿って、独自のサービスワーカーを備えたコントロールパネルもあります。 2番目のサービスワーカーがまだインストールされていない場合、getRegistaration（）は最初のサービスワーカーの登録を返します。これによりエラーが発生する可能性があります（たとえば、管理パネルからサービスワーカーに通知を送信します。

getRegistrationにはオプションのパラメーター-scopeがあります。指定すると、メソッドは渡されたスコープに最適な（必ずしも等しくない）登録を返します。したがって、サブページでサービスワーカーの登録を解除するか、現在のドメインから登録を受け取ることができます。適切な範囲を知る必要があります。

そして、すべてのスコープ、つまりgetRegistrations（）メソッドがわからない場合は、現在のドメインからのすべての登録を単に配列として返します。 FirefoxまたはChrome 45以降が必要です。

ページとService Worker間のリンク

サービスワーカーとサブページ間でデータを交換できる可能性があるため、元の作業スキームに至る可能性があります。たとえば、キャッシュからデータをすぐに送信しながら、同時に新しいデータを要求できます。新しいデータがあるとすぐに-キャッシュに入れてページに送信します。

serviceworke.rsの例は、サービスワーカーと簡単に通信する方法を示しています。

navigator.serviceWorker.controller.postMessage(message.value);

ここで、コントローラーはページを制御するサービスワーカーです。新しいブラウザ（FirefoxおよびChrome 51以降のすべてのバージョン）では、次のリクエストに簡単に答えることができます。

 self.addEventListener('message', function (event) { event.source.postMessage('response'); });

古いバージョンでは、すべてのタブを移動して適切なタブを見つけるか、MessageChannelの手で作成する必要がありました。また、フェッチイベントからタブにメッセージを送信できるようになりました。これについては、最新のAPIが既にあることを除いて、記事で説明されています。

もう1つのポイントは、Service Workerでのデータの保存です。すでにサービスワーカーを試した人は、LocalStorageがそこにないことに気付いているかもしれません。これは、サービスワーカーのコースが完全に非同期のAPIで行われたためです（ importScriptsの例外を除きます）。しかし、内部はまだ利用可能です：

キャッシュ
indexedDB
ワーカーのコンテキストで宣言された変数のみ（ただし、それらは短命であり、サービスワーカーが停止すると忘れられます）

キャッシュとindexedDBはどちらもページ上で通常の方法でアクセスでき、ワーカーと完全にデータを共有します。前の段落を参照すると、同じオリジンの複数のサービスワーカーがデータを共有するという結論に達することもできます。この場合、別のサービスワーカーのキャッシュをこすらないでください。たとえば、次のようにプレフィックスでチェックします。

 var CACHE_PREFIX = 'my-page-'; var CACHE_VERSION = 1; var CACHE_NAME = CACHE_PREFIX + CACHE_VERSION; self.addEventListener('activate', function(event) { event.waitUntil( caches.keys().then(function (cacheNames) { return Promise.all( cacheNames.map(function (cacheName) { if (cacheName.indexOf(CACHE_PREFIX) === 0) { return caches.delete(cacheName); } }) ); }) ); });

またはそのようなものですが、その場合、可能なキャッシュの完全なリストを1か所に保持する必要があります。

しかし、これらすべてにより、ストレージ内のデータの100％の安全性を保証する人はいないことを覚えておく価値があります。十分なディスク容量がない場合、ブラウザはCacheStorageとindexedDBを自動的に消去できます。ユーザーは自分で実行できます。

クロスドメインリクエストおよび他のドメインとのその他のやり取り

フェッチの導入により、状況は少し混乱しているように見えるかもしれません（異なる要求/応答モードがあります）。サービスワーカーでは、すべてが2倍難しくなります。

最も簡単に理解できるのは、CORSを「チート」し、ヘッダーなしで別のドメインのコンテンツにアクセスすることです。 2つのタイプの使用を分離することが重要です：javascriptのサイドからのアクセスありとなし。たとえば、問題なく1つの画像を別の画像に置き換えることができます。フェッチサービスワーカーモードで「no-cors」と指定するだけで、ヘッダーが何であるかは関係ありません。「no-cors」を使用しない場合、フェッチはCORSヘッダーを待機し、ヘッダーがない場合、すべてが失敗します。

より厳密には、ページからのリクエストにはモードがあります。たとえば、画像リクエストは「no-cors」であり、crossOrigin属性（匿名または使用資格情報）を持つ画像リクエストはすでに「cors」です。 XMLHttpRequestを介したリクエストは、常に「cors」モードです。また、フェッチを使用すると、モードを直接設定できます。

応答にはtypeプロパティがあります。現在のドメインに対する要求は「基本」です。それ以外の場合、要求モードが「cors」の場合、必要なヘッダーが存在する場合、応答タイプも「cors」になります。応答モード「opaque」は、「no-cors」モードの要求で受信できます。応答データにはアクセスできません。

クエリモードのすべての可能なタイプがここで説明されているわけではありませんが、これは一般的な理解に十分なはずです。詳細については、 fetchの記事をご覧ください。

それでは、すべてを組み合わせてみましょう。要求はページを離れ、サービスワーカーによってインターセプトされ、フェッチを行い、応答を受け取ります。これまで状況は整理されていましたが、今では微妙な違いがあります。ページリクエストへの応答で「不透明」タイプの応答を送信する場合です。「no-cors」モードでは実行されなかったため、エラーが発生します。

リクエストだけでなく、Service Workerを別のドメインにインストールできます。いいえ、サービスワーカーを通じて別のページを制御することはできません。サービスワーカーの条件は同じままです（スクリプト自体は、ワーカーが登録されているのと同じドメインに存在する必要があります）。これを行うには、目的のドメインのiframeを使用できます。ユーザー権限は不要で、iframeを単純に非表示にすることができます。

現在、以前のバージョンにある別の興味深い機能はForeign Fetchです。通常のサービスワーカーが自分のスコープ内のページ（リクエストではなく、スコープ内のページ）からのリクエストを制御する場合、外部フェッチにより、ドメインへのリクエストを制御できます。 CDN上のライブラリに対してリクエストが行われると通常のフェッチイベントが発生し、このライブラリに対するすべてのリクエストがサイトで行われるとforeignFetchが発生するとしましょう。この好奇心が強い機会は、たとえば分析サービスで使用できます。

テスト中

サービスワーカー向けのテストの作成にはいくつかの困難があります。テストの作成はそれほど簡単ではありません：オフラインモードを確認する場合は、何らかの方法でネットワークエラーをエミュレートする必要があります。更新を確認する場合は、ファイルを新しいファイルなどに置き換える必要があります。

追加の問題は、現時点で「ヘッドレス」ブラウザがサービスワーカーをサポートしていないという事実にもあります。つまり、実際のサービスワーカーが必要です。

サービスワーカーのテストに関する価値のある記事があります。また、 sw-unit-test-sampleおよびplatinum-sw （Polymerの要素であり、いくつかのテストもあります）のいくつかのツールへのリンクもあります。また、この記事では興味深いトリックについても説明しています。iframeを作成して、テストされたサービスワーカーが制御できるようにします。一般的に、iframe要素とオブジェクト要素には別の機能があります。それらに対する要求とそのコンテンツは、独自のサービスワーカーを使用して現在のページサービスワーカーをバイパスします。

ページ自体でキャッシュが利用可能であるという事実は、キャッシュの内容をクリアして検証するテストに役立ちます。

自動テストの作業中の重要なニュアンスは、サービスワーカーがページを制御してリクエストをインターセプトできる瞬間を決定することです。単純なnavigator.serviceWorker.readyが常に正しい決定とは限りません-ワーカーサービスがアクティブ化されたとき、clients.claim（）が完了する前に準備完了がトリガーされます。解決策の1つはcontrollerchangeイベントをリッスンすることであるため、ここで詳しく説明します。

サービスワーカーの更新

サービスワーカーを更新する際には、注意を払う価値のあるいくつかのニュアンスがあります。

サービスワーカースクリプトを要求する際のヘッダーのキャッシュのサポートにもかかわらず、ブラウザーはキャッシュの有効期間を24時間に短縮します。これは、ユーザーが誤って長時間サイトを強制終了状態にしないために行われます。キャッシングに関するStackOverflowの良い答えは次のとおりです。

別のニュアンス：更新は、 Service Worker スクリプト自体が更新された場合にのみ機能し、これはバイトで決定されます。 importScripts を介して接続されているファイルを更新しても、Service Worker自体は更新されません。

更新すると、多くの場合、一部のファイルがネットワークからキャッシュに追加されます。しかし、ブラウザのキャッシュは機能しています！サービスワーカー内のフェッチ呼び出しと同様。ファイルが変更されていないことを確認する（ファイル名にバージョン/ハッシュを含めるなど）か、キャッシュをバイパスしてリソースをロードする必要があります。キャッシュをバイパスしてリソースをロードするには、手動でフェッチを呼び出してから、キャッシュに応答を追加するか（たとえばresponse.okを確認することを忘れずに）、キャッシュを使用します： 'no-cache' Requestオプション（これまではFirefox Nightlyでのみ動作します）。どちらもJake Archibaldの記事で説明されています。

更新中のService Workerスクリプトへのリクエストは、現在のService Workerのフェッチイベントハンドラーをバイパスすることにも言及する価値があります。

Service Workerを使用する際の微妙な点