フロントエンドの状態管理（パート 1）

序文：

状態管理に関して言えば、 Vuex 、 Redux 、 Flux 、 Mobxなどのソリューションがすぐに思い浮かぶかもしれません。実際、どのソリューションを選択しても、コンテンツが増えれば増えるほど頭が痛くなるようです。自分に合ったソリューションがあるか、単にモジュールに注釈を付けて区別するだけかもしれません。今日はフロントエンドの状態管理についてお話ししましょう。何か良い提案や質問があれば、下にメッセージを残してください。

1. フロントエンドの状態管理とは何ですか?

たとえば、図書館の利用者は誰でも自由に図書館に出入りして、本を借りたり返却したりできます。人数が少ない場合は、この方法により効率が向上し、手順の数を減らすことができます。しかし、人数が多くなると、混乱が生じやすく、本の所在が不明瞭になったり、紛失したりすることがあります。したがって、本の貸出を具体的に記録する司書が必要であり、つまり、本の貸出と返却を司書に委託する必要があります。

実際、ほとんどの状態管理ソリューションは上記のアイデアに基づいており、管理者（Vuexなど）を使用して図書館の本の貸出と返却（プロジェクトに保存する必要があるデータ）を管理しています。

2. ヴュークス

国内のビジネス利用ではVuexの割合が最も高いはずです。Vuex Vuex Fluxコンセプトに基づいた製品です。Vuexではstateを変更することができますVuexその理由は、Vue の動作メカニズムに関係しています。Vue Vue ES5でgetter/setterに基づいてビューとデータの双方向バインディングを実装しています。そのため、 Vuexでのstateの変化は、 setterを通じてビュー内の対応する命令に通知され、ビューの更新が実現されます。 Vuex store内の状態を変更する唯一の方法はmutationを送信することです。図書館を例に挙げてみましょう。

定数状態 = {
  本: 0
}

const 変異 = {
  借りる本(状態) {
    状態.book++
  }
}

//store.commit('borrow_book') を呼び出すとき

actionはどうですか？ 非同期呼び出しとmutationを混在させると、プログラムのデバッグが非常に困難になる可能性があります。どれが最初に実行されるかはどうやってわかるのでしょうか? acitonは任意の非同期操作を含めることができます。その使用方法は上記と同様なので、ここでは説明しません。

実際、私は Vuex を使って、関連する使用法を簡単に紹介しているだけです。誰もが Vuex をよく知っているはずです。では、Vuex はどのような問題を解決するのでしょうか?

• 複数のコンポーネント間で共有される状態を管理します。
• グローバル状態管理。
• 状態変更の追跡。
• 状態管理を標準にして、コード構造を明確にします。
  

実際、ほとんどのプログラマーは（まったく）怠け者で、複数のコンポーネント間で状態を共有することだけを望んでおり、他のすべては後付けです。最も典型的な例は、ショッピングカートに追加されたアイテムの数です。 1 つのアイテムが追加されると、最終的な合計が Vuex レコードを通じて保存され、下の列に表示されます。

ここで疑問になるのは、目的が複数の状態を共有することだけであるのに、なぜBusを使用しないのかということです。

3. バス

Bus 、実際には、 emitとonイベントの処理に特化したパブリック Vue インスタンスです。

実際、Bus は非常に軽量です。Dom 構造はなく、 Domメソッドのみを備えています。

Vue.prototype.$Bus = 新しいVue()

次に、 emit経由でイベントを送信し、 on経由でイベントを受信できます。

//イベントを送信します this.$Bus.$emit('borrow_book', 1)

// どのコンポーネントでも受信 this.$Bus.$on('borrow_book', (book) => {
    console.log(`${book} の本を借りました`)
})

もちろん、 off （削除）やonce （一度聞く）などの操作もあります。気になる方は自分で検索してみてください。

どうですか？上記は、状態を共有する上で Vuex よりもはるかに簡単ですか?実際、はるかにシンプルですが、これは中小規模のプロジェクトに適していることも意味します。大規模なプロジェクトの場合、 Bus変更されたソースをトレースするときに混乱が生じるだけで、どこが変更されたのかさえわからない可能性があります。

その動作原理は、パブリッシュとサブスクライブという考え方です。非常にエレガントでシンプルですが、 Vueこの書き方を推奨しておらず、バージョン 3.0 では関連するApi (emit、on など) のほとんどが削除されました。実際、パブリッシュ サブスクライブ モードを実装するために自分で書くこともできます。

クラスバス{
 コンストラクタ() {
  // サブスクリプション情報を収集し、センターに発送します。this.list = {};
 }

 // Subscribe$on(name, fn) {
  this.list[名前] = this.list[名前] || [];
  this.list[名前].push(fn);
 }

 // 公開 $emit(name, data) {
  if (this.list[名前]) {
                    this.list[name].forEach((fn) => {
                        fn(データ);
                    });
                }
 }

 // 購読解除 $off(name) {
  if (this.list[名前]) {
   this.list[名前]を削除します。
  }
 }
}
デフォルトのバスをエクスポートします。

簡単ですよね？ Vue Busの場合と同じように、インスタンス化して使用するだけです。何？ 2 つ、3 つ、あるいはそれ以下の状態 (1 つ) を共有する場合、 Busをカプセル化する必要はないのではないでしょうか。 OK、それならweb storageを使用できます。

4. ウェブストレージ

実際、この点に関しては、 storage単にデータを保存する方法に過ぎません。状態管理とは何の関係もありません。単にデータを共有することです。しかし、すでに言及されているので、ついでに言っておきます（犬の頭）

Web ストレージには、 cookie 、 local storage 、 session storage web storage 3 種類があります。

これら 3 つのいずれの場合も、機密情報を入れないことを強くお勧めします。暗号化するか、重要度の低いデータを入れるようにしてください。

次の 3 つを簡単に確認してみましょう。

loaclStorage 、理論上は永続的に有効なデータを保存できます。状態を保存する場合は、通常、 sessionStorageに配置することをお勧めします。LocalStorage localStorageは、次の制限もあります。

• ブラウザのサイズは統一されておらず、IE8 以上の IE バージョンのみがlocalStorageプロパティをサポートしています。
• 現在、すべてのブラウザはlocalStorageの値の型をstring型に制限しているため、日常生活でより使い慣れているJSONオブジェクト型への変換が必要になります。
• localStorageはブラウザのプライバシーモードでは読み取れません。
• localStorageは基本的に文字列の読み取りです。ストレージが大量にあると、メモリ領域が消費され、ページが停止する原因になります。
• localStorageクローラーによってクロールできません。

localStorageとsessionStorageの唯一の違いは、 localStorageは永続的なストレージであるのに対し、 sessionStorageセッション終了時にクリアされるsessionStorage内のキーと値のペアである点です。

localStorage自体は文字列のストレージのみをサポートしているため、整数を保存すると出力は文字列になります。

sessionStorage基本的にlocalStorageと同じですが、セッションが閉じられるとデータがクリアされる点が異なります。

要約:

どのソリューションを選択する場合でも、プロジェクトに適したものを選択するのがベストプラクティスです。最善の解決策というものは存在せず、自分に合った解決策があるだけです。

フロントエンドステータス管理に関するこの記事はこれで終わりです。フロントエンドステータス管理に関するその他のコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。