4

Hoodie の API の URL である /_api を除くすべての URL パスをキャッシュするように、Polymer のプラチナ-sw-キャッシュまたはプラチナ-sw-fetch を構成するにはどうすればよいですか? 次のように、/_api パスを処理するようにplatinum-sw-fetch要素を構成し、残りのパスを処理するためにplatinum-sw-cache要素を構成しました。

<platinum-sw-register auto-register
                      clients-claim
                      skip-waiting
                      on-service-worker-installed="displayInstalledToast">
  <platinum-sw-import-script href="custom-fetch-handler.js"></platinum-sw-import-script>
  <platinum-sw-fetch handler="HoodieAPIFetchHandler"
                 path="/_api(.*)"></platinum-sw-fetch>
  <platinum-sw-cache default-cache-strategy="networkFirst"
                     precache-file="precache.json"/>
  </platinum-sw-cache>
</platinum-sw-register>

custom-fetch-handler.js には以下が含まれます。その意図は、Service Worker がリクエストを処理していない場合と同じように、ブラウザがリクエストの結果を返すことだけです。

var HoodieAPIFetchHandler = function(request, values, options){
  return fetch(request);
}

正しく機能していないように見えるのは、ユーザー 1 がサインインしてからサインアウトした後、ユーザー 2 がサインインした後、Chrome 開発ツールの [ネットワーク] タブで、Hoodie が両方のユーザーに定期的にリクエストを出し続けていることです。次のような API エンドポイント:

http://localhost:3000/_api/?hoodieId=uw9rl3p
http://localhost:3000/_api/?hoodieId=noaothq

代わりに、これらの API エンドポイントの 1 つだけにリクエストを送信する必要があります。[ネットワーク] タブでは、これらの URL がそれぞれ 2 回続けて表示されます。[サイズ] 列には、最初の要求には「(ServiceWorker から)」と表示され、2 番目の要求には、関連する場合に備えて応答サイズがバイト単位で表示されます。

関連すると思われるもう 1 つの問題は、ユーザー 2 としてサインインしてフォームを送信すると、アプリがサーバー側のユーザー 1 のデータベースに書き込むことです。これは、アプリが /_api ルートのキャッシュをバイパスできないことが原因であると思われます。

ドキュメントには互いの代替であると記載されているため、1つのplatinum-sw-register要素内でplatinum-sw-cacheとplatinum-sw-fetchの両方を使用すべきではありませんでしたか?

4

1 に答える 1

3

一般に、あなたがしていることはうまくいくはずであり、それは正当なアプローチです。

で定義されたパスに一致する HTTP 要求が行われた場合<platinum-sw-fetch>、そのカスタム ハンドラーが使用され、既定のハンドラー (この場合はnetworkFirst実装) は実行されません。HTTP 要求は 1 回しか応答できないため、複数のハンドラーが有効になる可能性はありません。

いくつかのローカル サンプルを実行し、<platinum-sw-fetch>ハンドラがリクエストを適切にインターセプトしていることを確認しました。これをローカルでデバッグするときはconsole.log()、カスタム ハンドラー内に を追加して Inspect インターフェイス経由でそれらのログを確認するchrome://serviceworker-internalsか、同じインターフェイスを使用してハンドラー内にいくつかのブレークポイントを設定すると便利です。

制御されたページの [ネットワーク] タブに表示される内容は想定どおりです。Service Worker のネットワーク インタラクションは、カスタムハンドラーHoodieAPIFetchHandlerまたはデフォルトnetworkFirstハンドラーのどちらからのものかに関係なく、そこに記録されます。制御されたページの観点からのネットワーク インタラクションもログに記録されます。サービス ワーカーのアクティビティと常に 1 対 1 で対応するとは限らないため、両方をログに記録すると便利な場合があります。

そのため、アプリケーションが複数のリクエストを行っている理由を詳しく調べることをお勧めします。パーソナライズされたリソースのキャッシュについて考えるのは常に注意が必要であり、別のユーザー用にパーソナライズされたリソースをキャッシュすることになってしまうと、いくつかの方法で問題が発生する可能性があります。2 番目のリクエストを開始するコード行を見て/_api/、ユーザーがログアウトするときにクリアする必要があるキャッシュされたリソースからのものかどうかを確認してください。<platinum-sw>は内部でsw-toolboxライブラリを使用し、そのuncache()メソッドをカスタム ハンドラ スクリプト内で直接利用してキャッシュ メンテナンスを実行できます。

于 2015-06-25T09:53:50.743 に答える