サーバーとvuex状態を同期するための推奨戦略
この単純なケースを想像してみてください。 Vue JSアプリケーションを使用して、ユーザーがタスクのリストを作成し、並べ替えることができます。これらのリストはサーバーによってデータベースに保存される必要があります。ListComponent UXの大部分を行います。
私の質問は、フロントエンドとバックエンドのデータ同期を処理するためにどのパターンを使用する必要があるかです。
A）Go through vuex：アクティブリスト（表示、編集、または作成されたもの）をvuex storeに保存します。 ListComponentはstoreを変更し、、次に、リストに加えられた変更は、バックエンドに送信されます。 API。
B）サーバーに直接移動する：リストが表示、編集、または作成されるたびに、ListComponentからサーバーに直接読み書きします。
Aに準拠している場合、ストアはどのアーキテクチャを持つ必要がありますか？いつどのようにして同期を開始する必要がありますか？変更点と変更点を追跡するにはどうすればよいですか？
どちらの場合も、ユースケースによっては正しい場合があります。現在作成しているアプリケーションは両方を使用しています。
Bを使用する場合：サーバーに直接移動しますデータの保存が非常に重要な場合は、Bを使用します。この場合、サーバーに直接アクセスして、DBにコミットされたことを確認するための応答を提供することができます。このプロセスは、管理者タイプの変更に使用します。サーバーの応答後にVuexを更新し、Vuexを使用してデータを提供することもできます。
Aを使用するタイミング：Vuexを通過するサーバーを待つ必要がないため、より高速なエクスペリエンスが必要な場合はAを使用します。実際に保存する前に、楽観的に変更を表示することに問題はありません。他の利点はあなたが同期できることです Vuex to localStorage 。これは、ビューのカスタマイズに使用されるユーザー設定に使用します。それらをフェッチするのを待つためだけにページを遅くするのは悪い体験です。
Aの使用方法：Vuexを実行しますこれを行うにはいくつかの方法があります。これが1つのパターンです。
- コンポーネントからVuexアクション1をディスパッチします
- 状態を更新するアクションからのVuex変更のコミット-これは通過すると想定しているため、これは楽観的な更新です
- アクション1から別のVuexアクション2をディスパッチします-これは、このアクションを複数のアクションで再利用することを前提としています。それ以外の場合は、すべてアクション1で実行できます。
- アクション2はサーバーにデータを送信します
- 約束が戻ると、アクション2はミューテーションをコミットしてVuex状態を更新します
- 変異は不一致（またはエラー）を処理する必要があります
Vuexのコストを数えます
コメントが示すように、Vuexを使用する必要がある場合は、オーバーヘッドを数え、複雑さを増すため、コストを数えるのは良いことです。 Vuexを介して状態を共有する必要がないように、1つのタイプのデータ（「リスト」など）とのすべてのやり取りを含むようにコンポーネントを記述することが理想的です。