さまざまな種類のブラウザストレージのプライマー

バックエンド開発では、ストレージは一般的なタスクです。アプリケーションデータはデータベースに保存され、ファイルはオブジェクトストアに保存され、一時データはキャッシュに保存されます...さまざまなデータを保存する方法は無限に見えます。ただし、データストレージはバックエンドに限定されません。フロントエンド（ブラウザ）には、データを保存するための多くのオプションも装備されています。このストレージを活用して、アプリケーションのパフォーマンスを向上させ、ユーザー設定を節約し、複数のセッションや異なるコンピューターでアプリケーションの状態を維持できます。

この記事では、データをブラウザに保存するさまざまな方法を紹介します。各アプローチの3つのユースケースをカバーして、その長所と短所を理解します。最後に、ユースケースに最適なストレージを決定できるようになります。始めましょう！

LocalStorage API

LocalStorageは、ブラウザで最も人気のあるストレージオプションの1つであり、多くの開発者にとって最初の選択肢です。データはセッション全体に保存され、サーバーと共有されることはなく、同じプロトコルとドメインの下のすべてのページで使用できます。ストレージ制限は約5MBです。

驚くべきことに、Google Chromeチームはメインスレッドをブロックし、Webワーカーとサービスワーカーがアクセスできないため、このオプションを推奨していません。彼らはより良いバージョンとして実験的なKVストレージを起動しましたが、これは単なる実験であり、まだ進歩がないようです。

LocalStorage APIはwindow.localStorageとして使用でき、UTF-16文字列のみを保存できます。データをLocalStorageに保存する前に、データが文字列に変換されることを確認する必要があります。 3つの主な機能は次のとおりです。

• setItem('key', 'value')
• getItem('key')
• removeItem('key')

それらはすべて同期しているため、使いやすくなりますが、メインスレッドをブロックします。

LocalStorageにはSessionStorageという名前の双子の兄弟がいることに言及する価値があります。唯一の違いは、SessionStorageに保存されているデータが現在のセッションでのみ有効であることですが、APIは同じです。

その実用的なアプリケーションを見てみましょう。最初の例は、LocalStorageを使用してユーザーの好みを保存する方法を示しています。この場合、これは私たちのウェブサイトの暗いテーマをオンまたはオフにするために使用されるブールのプロパティです。

チェックボックスを選択してページを更新して、セッション全体でステータスが保存されているかどうかを確認できます。保存およびロード機能をチェックして、値を文字列に変換する方法とそれを解析する方法を確認してください。文字列しか保存できないことを覚えておくことが重要です。

2番目の例では、ポケモンの名前をポケAPIからロードします。

Fetchを使用してGETリクエストを送信し、UL要素のすべての名前をリストします。応答を受信したら、次のアクセスがより速くなり、オフラインで動作するように、LocalStorageにキャッシュします。 json.stringifyを使用してデータを文字列に変換し、json.parseを使用してキャッシュから読み取る必要があります。

この最後の例では、ユーザーが異なるポケモンページ間で閲覧できるユースケースを示し、次の訪問のために現在のページが保存されます。

この場合、LocalStorageの問題は、状態が地元で救われることです。この動作により、必要なページを友達と共有することはできません。後で、この問題を克服する方法がわかります。

また、次のストレージオプションでこれらの3つの例を使用します。ペンをフォークし、関連する機能のみを変更しました。すべての方法の全体的なフレームワークは同じです。

indexedDB API

IndexEdDBは、ブラウザ内の最新のストレージソリューションです。多くの構造化されたデータを保存できます - ファイルやブロブもあります。すべてのデータベースと同様に、indexedDBはデータをインデックス化してクエリを効率的に実行します。 IndexEdDBの使用はより複雑です。データベース、テーブル、およびトランザクションを使用する必要があります。

indexedDBには、LocalStorageよりも多くのコードが必要です。この例では、Promise Lapperを使用してネイティブAPIを使用していますが、サードパーティライブラリを使用してお手伝いすることを強くお勧めします。私の提案は、同じLocalStorage APIを使用しているため、Localforageですが、徐々に強化された方法で実装しています。そうでない場合は、LocalStorageに戻ります。

コードを書き、ユーザー設定の例に移動しましょう！

IDBは、低レベルのイベントベースのAPIを使用する代わりに使用する約束ラッパーです。彼らはほとんど同じですので、心配しないでください。最初に注意すべきことは、データベースへのすべてのアクセスが非同期であるため、メインスレッドをブロックしないことを意味します。これは、LocalStorageと比較して大きな利点です。

データベース接続を開き、アプリケーション全体で読み書きに使用できるようにする必要があります。データベースMy-DB、スキーマバージョンは1、異なるバージョン間で変更を適用する更新関数に名前を付けました。これは、データベースの移行に非常に似ています。データベーススキーマはシンプルです。オブジェクトストア、設定は1つだけです。オブジェクトストレージは、SQLテーブルと同等です。データベースに書き込みまたは読み取るには、トランザクションを使用する必要があります。これは、indexedDBを使用することの退屈な部分です。デモで新しい保存とロード機能を表示します。

IndexEdDBのオーバーヘッドがはるかに大きく、ローカルストレージよりもはるかに大きく、より急な学習曲線を持っていることは間違いありません。キー価値のユースケースの場合、LocalStorageまたは生産性の向上に役立つサードパーティライブラリを使用する方が理にかなっている場合があります。

アプリケーションデータ（たとえば、ポケモンの例の場合）は、indexedDBの長所です。このデータベースに数百メガバイトまたはさらに多くのデータを保存できます。すべてのポケモンをIndexEdDBに保管して、オフラインで利用できるようにすることも、インデックス付けもできます。これは間違いなくアプリケーションデータを保存するための最良の選択です。

indexedDBは、LocalStorageと比較してこの場合に何の違いももたらさないため、3番目の例の実装をスキップしました。 IndexEdDBを使用しても、選択したページを他の人と共有したり、将来の使用のためにブックマークしたりすることはできません。それらのどれも、このユースケースに正しい選択ではありません。

クッキー

Cookieを使用することは、一意のストレージオプションです。サーバーと共有される唯一のストレージです。 Cookieは、各リクエストの一部として送信されます。これは、ユーザーがアプリケーションでページを閲覧したり、AJAXリクエストを送信したりすると発生する場合があります。これにより、クライアントとサーバーの間に共有状態を作成し、異なるサブドメインの複数のアプリケーション間で状態を共有できます。この記事で説明する他のストレージオプションはこれを行うことができません。警告：クッキーは各リクエストで送信されます。つまり、合理的なリクエストサイズを維持するためにCookieサイズを維持する必要があります。

Cookieの最も一般的な使用は認証です。これは、この記事の範囲を超えています。 LocalStorageと同様に、Cookieは文字列のみを保存できます。 Cookieは、セミコロン削除された文字列に連結され、要求されたCookieヘッダーに送信されます。有効期限、許可ドメイン、許可ページなど、各クッキーに多くの属性を設定できます。

この例では、クッキーを介してCookieを操作する方法を示しましたが、サーバー側のアプリケーションでそれらを変更することもできます。

サーバーが何らかの方法でそれを利用できる場合、Cookieでユーザーの設定を保存することが良い選択肢かもしれません。たとえば、トピックユースケースでは、サーバーは関連するCSSファイルを提供し、潜在的なパッケージサイズを削減できます（サーバー側のレンダリングを行っている場合）。別のユースケースは、データベースを必要とせずに複数のサブドメインアプリケーションでこれらの設定を共有することです。

JavaScriptを使用してCookieを読んで書くことは、あなたが思うほど簡単ではありません。新しいCookieを保存するには、document.cookieを設定する必要があります - 上記の例の保存関数を参照してください。 Dark_theme Cookieを設定し、最大年齢属性を追加して、タグが閉じたときに期限切れにならないようにしました。さらに、SamesIteとSecure Propertiesを追加しました。 Codepenはiframesを使用して例を実行するため、これらが必要ですが、ほとんどの場合、それらは必要ありません。 Cookieを読むには、Cookie文字列を解析する必要があります。

クッキー文字列は次のようになります：

 <code>key1=value1;key2=value2;key3=value3</code>

したがって、最初に、文字列をセミコロンで分割する必要があります。これで、フォームkey1 = value1のクッキーの配列があるため、配列に正しい要素を見つける必要があります。最後に、等号で分割し、新しい配列の最後の要素を取得します。それは少し退屈ですが、GetCookie関数を実装すると（または私の例からコピーする）、それを忘れることができます。

Cookieでアプリケーションデータを保存することは、悪い考えになる可能性があります！要求のサイズを大幅に増やし、アプリケーションのパフォーマンスを低下させます。さらに、サーバーはこの情報に既にこの情報の古いバージョンをデータベースに持っているため、この情報の恩恵を受けることはできません。 Cookieを使用している場合は、それらが小さくなっていることを確認してください。

Paginationの例は、Cookieにも適していません。Cookieは、LocalStorageやIndexEdDBなどです。現在のページは、私たちが他の人と共有したい一時的な状態であり、これらの方法はどれもそれを実装できません。

URLストレージ

URL自体はストレージではありませんが、共有可能な状態を作成するのに最適な方法です。実際、これは、現在の状態を再現するために使用できる現在のURLにクエリパラメーターを追加することを意味します。最良の例は、検索クエリとフィルターです。 CSS-TricksでFlexBox用語を検索すると、URLはhttps://www.php.cn/link/ada9e980b20ac07f6a938ef15106c224に更新されます。もう1つの利点は、クエリの新しい結果を取得したり、ブックマークしたりすることもできることです。

URLの文字列のみを保存することができ、最大長は限られているため、スペースはあまりありません。フォームを小さく保つ必要があります。長くて怖いURLが好きな人はいません。

同様に、CodePenはIFRAMEを使用して例を実行するため、URLが実際に変更されることがわかりません。心配しないでください。すべての部品がそこにあるので、どこでも使用できます。

window.location.searchを介してクエリ文字列にアクセスできます。幸いなことに、urlsearchparamsクラスを使用して解析できます。これ以上複雑な文字列解析は必要ありません。現在の値を読みたい場合は、GET機能を使用できます。書きたいときは、セットを使用できます。値を設定するだけでは不十分です。また、URLを更新する必要があります。これは、history.pushStateまたはhistory.replacestateを使用して実行できます。

ユーザーが訪問するすべてのURLにこのステータスを追加する必要があるため、URLでユーザーの設定を保存することはお勧めしません。保証することはできません。たとえば、ユーザーがGoogle検索のリンクをクリックした場合。

Cookieと同じように、スペースが限られているため、URLにアプリケーションデータを保存することはできません。たとえそれを保存できたとしても、URLはクリックするのが長くて不便です。ある種のフィッシング攻撃のように見えるかもしれません。

ページングの例と同じように、一時的なアプリケーション状態はURLクエリ文字列に最適です。繰り返しますが、URLの変更はわかりませんが、ページをクリックするたびに、URLは？page = x queryパラメーターで更新されます。 Webページが読み込まれると、このクエリパラメーターを探し、それに応じて正しいページを取得します。これで、このURLを友達と共有して、お気に入りのポケモンを楽しむことができます。

キャッシュAPI

キャッシュAPIは、ネットワークレベルのストレージです。ネットワークリクエストとその応答をキャッシュするために使用されます。キャッシュAPIは、サービスワーカーと完全に適合します。サービスワーカーは、各ネットワークリクエストをインターセプトし、キャッシュAPIを使用できます。これにより、リクエストが簡単にキャッシュできます。サービスワーカーは、サーバーから取得する代わりに、ネットワーク応答として既存のキャッシュエントリを返すこともできます。これを行うことで、ネットワークの読み込み時間を短縮し、オフラインでもアプリケーションを機能させることができます。当初は、サービスワーカー向けに作成されていましたが、最新のブラウザでは、キャッシュAPIもウィンドウ、iframe、およびワーカーコンテキストで使用できます。これは、アプリケーションのユーザーエクスペリエンスを大幅に改善できる非常に強力なAPIです。

indexedDBのように、キャッシュAPIストレージに制限はありません。必要に応じて、数百メガバイトまたはさらに多くのデータを保存できます。 APIは非同期であるため、メインスレッドをブロックしません。また、グローバルプロパティキャッシュからアクセスできます。

キャッシュAPIの詳細については、Google Chromeチームが素晴らしいチュートリアルを作成しました。

クリスは、サービスワーカーとキャッシュAPIを組み合わせた実用的な例を備えた素晴らしいペンを作成しました。

デモ###添付を開く：ブラウザ拡張機能

ブラウザ拡張機能を構築する場合、データを保存する別のオプションがあります。拡張機能をdaily.devの開発中に見つけました。 Chrome.storageまたはbrowser.storageを介して使用できます（Mozillaのポリフィルを使用する場合）。インベントリのストレージ権限を要求してアクセスしてください。

ストレージオプションには、ローカルと同期の2種類があります。ローカルストレージは自明です。これは、共有されていないが、地元で予約されていることを意味します。同期ストレージは、Googleアカウントの一部として同期されます。同じアカウントを使用して拡張機能をインストールする場所であれば、このストレージは同期されます。あなたが私に尋ねると、これはクールな機能です。どちらも同じAPIを持っているため、必要に応じて切り替えるのは非常に簡単です。非同期ストレージであるため、LocalStorageのようなメインスレッドをブロックしません。残念ながら、ブラウザ拡張機能が必要であるため、このストレージオプションのデモを作成することはできませんが、ColalStorageのように非常に使いやすいです。正確な実装の詳細については、Chromeドキュメントを参照してください。

結論は

ブラウザには、データを保存するための多くのオプションがあります。 Chromeチームの推奨によると、お好みのストレージはindexedDBでなければなりません。それは非同期ストレージであり、私たちが望むすべてを保存するのに十分なスペースがあります。 LocalStorageは落胆していますが、indexedDBよりも使いやすいです。 Cookieは、クライアント状態をサーバーと共有するのに最適な方法ですが、主に認証に使用されます。

共有可能な状態（検索ページなど）を持つページを作成する場合は、URLのクエリ文字列を使用してこの情報を保存します。最後に、拡張機能を構築する場合は、Chrome.storageについて必ずお読みください。

以上がさまざまな種類のブラウザストレージのプライマーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。