データ変更コードは関数内に置くべきですか、それともアクション内に置くべきですか?

Question

私は現在、オブジェクト タイプを使用して時刻表の「ドキュメント」をモデル化するバス時刻表アプリケーションを作成しています。

リーリー

型に加えて、多くの関数があり、ミューテーションを使用する場合は、通常、それらをクラスのメソッドとして記述します。私は主に Immer を使用するため、多くの拡張構文を記述する必要はありません。例えば、＃＃＃ リーリー

状態を管理するために Zustand と Immer を使用していますが、Redux を使用しても問題は同じになるような気がします。私のストアには、Timetable オブジェクトの配列と、Immer を使用して現在選択されている Timetable オブジェクトを再割り当てする操作があります:

リーリー

次に、React コンポーネントのデータ変更関数を呼び出し、更新操作を呼び出します。 リーリー

これは機能しますが、正しく実行しているかどうかはわかりません。現在、Immer 呼び出しの 2 つのレイヤーがあり、コンポーネントにはイベント ハンドラーで直接呼び出されるデータ変更関数が含まれています。全体的には小さなバグですが、「メソッド」の外観があまり好きではありません。

検討しました:

すべてのデータ変更を操作に変換します。ストアのオブジェクト配列のインデックス付けには多くの重複があるため、これは保守が難しく、理解しにくくなるように見えます。

• 各データ変更関数のアクションを作成し、イベント ハンドラーからこれらのアクションを呼び出します。これにより、名前だけでも重複が生じるようです。
Timetable
• をクラスに型キャストし、データ変更関数を突然変異メソッドとして書き直し、[immerable] = true を設定して、Immer にすべての作業を実行させます。これを実行しましたが、むしろ不変記録モードにこだわりたいと思います。
実際のところ、Flux、Zustand、または Immer のドキュメントでは最初のオプションが示されることが多く、ごくまれですが、

counter = counter 1

ほど単純なアプリケーションはありません。 Flux アーキテクチャを使用してアプリケーションを構築する最良の方法は何ですか?

Answer 1

(Zusand と Immer については詳しくありませんが、お役に立てるかもしれません...)

常にさまざまな方法がありますが、ここでは私のお気に入りの方法を提案します。

「scheduling」アクションと実際の状態の「mutations」を明確に区別します。 (たぶん 間に別のレベルを追加します)。

特定の「突然変異」機能

一般的なものではなく、 特定の 「突然変異」関数を作成することをお勧めします。つまり、

• の代わりに updateThisTt: () => { ...,
• addStop: () => { ... などの関数を使用します。

それぞれの目的を持った、必要なだけのミューテーション関数を作成します。

「突然変異」関数で新しい状態を構築する

概念的には、immer ジェネレーターはミューテーション関数内でのみ使用してください。
(ストアのことです。もちろん、immer を他の目的に使用することもできます) 。

この公式の例によると: リーリー

コンポーネント内で「mutator」関数を呼び出すことができるようになりました。

リーリー

新しい国を築く

新しい状態の構築が複雑になった場合でも、いくつかの「ビルダー」関数を抽出できます。 ただし、最初に次のセクション「大きなファイルと重複」を検討してください。

たとえば、

addStop 関数は Zustand ミューテーション内で呼び出すこともできます。 リーリー

大きなファイルと重複

コードの重複は確かに避けるべきですが、常にトレードオフが存在します。

特定のアプローチは提案しませんが、通常、コードは

書かれるよりも読まれることが多いことに注意してください 。 時々 さらにいくつかの文字、たとえば state.timetables[index] のようなものを複数回書く価値があると思います。 コードの目的がより明確になる場合。自分で判断する必要があります。

とにかく、ミューテーション関数を

別のファイル に入れて、他には何もしないことをお勧めします。 こうしてみると、思ったよりも理解しやすいかもしれません。

非常に大きなファイルがあるが、

状態の変更のみに完全に集中している場合 、 構造が一貫しているため、スクロールする必要がある場合でも読みやすくなっています。 数ページ。

たとえば次のようになります:

リーリー

また、これらの可変引数関数は完全に独立していることにも注意してください

(それともそうなのですか?ここでは Zustand が純粋な関数を使用すると予想しています、いいえ?) 。

これは、複雑になった場合には、複数の突然変異関数を分割することもできることを意味します。 フォルダー内で個別のファイルに分割する

/store/mutators/timeTable.js のように。

ただし、これは後でいつでも簡単に行うことができます。

「ペイロード」(「アクション呼び出し元」) の構築

別の「レベル」が必要だと感じるかもしれません

イベント ハンドラーとミューテーション関数の間。 通常、このようなレイヤーを作成しますが、適切な名前がありません。 これを一時的に「オペレーション呼び出し元」と呼びます。

何が「変化関数」に属し、何が「変化関数」に属するのかを判断するのが難しい場合があります。 「アクションコーラー」。

とにかく、「アクション呼び出し元」内で「データを構築」することはできますが、そうすべきではありません。

ここでは、immer を使用する場合も含め、いかなる種類の状態操作も実行されません。

状態の変換とペイロードの作成

これは微妙な違いであり、おそらくあまり心配する必要はありません (例外もあるかもしれません) ただし、例として:

「アクション呼び出し元」内で古い状態の一部を使用できます。例: リーリー ただし、

not古い状態を新しい状態にマッピング (または変換) しないでください。例: リーリー ＃＃＃もう一つの例＃＃＃ ここでは具体的な提案はしません。単なる例です:

多くの値をミューテーターに渡すと面倒になる可能性があります。例:

リーリー

イベント ハンドラーでは、「新しい項目の追加」など、本当にやりたいことに集中したいと考えています。 ただし、すべての議論を考慮する必要はありません。さらに、他の用途で新しいアイテムが必要になる場合もあります。

または次のように書くこともできます:

リーリー