サービスワーカーに対して調べたことで大まかに概要が把握できるものをさらっとまとめました。

概要

端的に言うとブラウザ上でバックグランドに処理を実行する機能
オフラインアプリの実装、サポートのために作られた。

大まかな構成は上の通りで、
対応表はここを参照
https://caniuse.com/?search=service%20workers

状態

サービスワーカーはいくつかの状態を遷移して、対象のページを動作しようとする。

googleより引用

register

serviceWorker のファイルを登録する。

 navigator.serviceWorker.register('/service-worker.js');

この登録関数にswファイルを指定すると、その階層のページがserviceWorkerの制御対象になる
そして、実際にswのファイルがダウンロードされる。

install

クライアント制御のためのリソースを取得したり、キャッシュしたりするイベント
ブラウザはこのinstallのイベントが成功 or 失敗を検知でき、失敗の場合はserviceworkerを破棄する

activate

installが終わり、実際にswがページを制御下に置いた状態。これでpush や syncといった処理を扱える様になる。
ただし、初期読み込みの場合はactivateまで行かず、二回目以降の読み込みでactivateまで到達する
activate時にclients.claim()をすれば、１度目のinstallでも制御下における。

fetch

[** fetch]
他ページへの遷移やリロードが行われる時に、呼び出されるイベント。
ここで、リクエストを確認して、キャッシュにヒットするものがあればそれを返す。なければfetch結果を返す

制約・特徴

• Worker独自のコンテキスト(スコープ)で動く
  • メインスレッド(javascript)とは違うスレッドで動作するのでDOMにアクセスできない
• 完全なノンブロッキング且つ非同期の処理になる
  • 結果としてXHRのような同期処理やLocalStorageは使えない,
    • ただ fetch　関数は使える。

活用法

• fetchイベントを活用して、APIのリクエストをキャッシュする。キャッシュが古ければAPIを投げ、新しければキャッシュ内容を活用してページを表示する。
• pushイベントを活用して、push通知を行う。service workerは独自のAPIのエンドポイントのような物を生成し、そのAPIに対してリクエストするとpushイベントが発火、そこで、通知処理(スマホに通知が来たと表示する)をすれば擬似的なpush通知ができる。

終わりに

相当、雑にまとめましたが、メインスレッドとは別に独自のライフサイクルで動き、そのライフサイクルで発生するイベントに処理を登録することで、色々できると言うのが大きな強みだと感じました。