Reduxビジネスロジック

一度、React_JS Telegramチャット（ところで、ロシア語チャット、参加）で、「Reactアプリケーションのどこにビジネスロジックを担当するコードがあるべきか」という質問について話し合いました。 いくつかのオプション、意見が分かれました。 さて、 ポッドキャストを記録することにしました（by @PetrMyazin ）。

クライアントのみでビジネスロジックを使用する特定の例を考えてみましょう。 ローン計算アプリケーション。 ユーザーは、フォームに初期データを入力します。金額、ローン条件、その他のパラメーター。 そして、その場で結果、例えば、過払いの金額を取得します。 過払いの金額を計算するためのトリッキーなアルゴリズムはすべて既知であり、JS関数として実装されています。fと呼びましょう。これはいくつかのパラメータを取ります。フォームからの同じデータ、abcd -これがビジネスロジックです。

関数がクリーンであることに注意してください。 結果は入力パラメーターのみに依存します。 副作用は発生せず、グローバル変数からは読み取りません。 また、この関数は、Reactアプリケーション、Angular、Ember、jQuery、およびVanillaJSでも同じように機能するため、フレームワークから独立して呼び出すことができます。

しかし、React + Reduxでインターフェイスを構築することに決めたため、「ビジネスロジックの計算をいつから開始するか」という疑問が生じました。 このポッドキャストでは、単純化された例のみを検討することを再度強調します。クライアント上のすべての計算であり、サーバーへのリクエストはありません。 実際のアプリケーションでは、サーバーとの通信に関連するロジックの一部が確実に存在しますが、既存のデータを使用してクライアント上で完全に計算できる部分もあります。 したがって、さらにすべての推論は、クライアントコンピューティングという第2部に正確に適用できます。

さて、フォームを見てください。 構成は次のとおりです。1組のテキストフィールド、スライダー、ドロップダウンリスト、チェックボックス。 これらのフィールドのユーザー入力値は、関数fへの入力パラメーターになります。 最初の質問：「フィールド値をどこにどのように保存するか」。 オプションは2つだけです。コンポーネント自体のローカル状態（チェックボックス、スライダーなど）、またはReduxストアです。

この場合、複数のコンポーネントにまたがるローカル状態は不便です。なぜなら、 最終的に、abcdパラメータをビジネスロジック関数に渡すために、すべての値を同時に取得する必要があります。 共通の祖先（ 状態を解除することを忘れないでください）またはRedux-storeのいずれかで、すべてを1か所に保存したいと思います。 このポッドキャストのトピックはReduxアプリケーションのビジネスロジックを確認することなので、Reduxに保存します。

イベントチェーン全体の手順を実行し、ビジネスロジック関数fを呼び出すのが最適なタイミングを判断します。

そのため、ユーザーはフォーム上の何かを変更したり、入力テキストボックスに新しい数字を入力したり、スライダーを移動したりします。 特定のhandleChangeハンドラーが機能します-これがビジネスロジックを呼び出す最初の場所です。 ただし、handleChangeハンドラーでは、現在の変更された入力フィールドの値のみをevent.target.valueから読み取ることができ、フォームデータの残りの部分はまだ利用できません。 関数fは純粋であり、グローバル変数からデータを読み取らないことを思い出させてください。 abcdパラメーターのみを受け取り、xの結果を返します。 つまり、handleChangeハンドラー自体は適切ではありません。

次のステップは、アクション作成機能です。 ここで、 Redux-thunkを使用して、状態オブジェクト全体を取得できます。 fを呼び出すabcdを取得します。 アクションクリエーターは優れた候補です。覚えておいてください。

続けましょう。 実行のスレッドは、すべてのリデューサー機能を起動します。 レデューサーはさまざまな方法で実装できます。 たとえば、フィールドa、フィールドb、フィールドc、およびフィールドdの4つの個別の関数を準備します。 この場合、各レデューサーは、入力フィールドの以前の状態とアクションオブジェクトにアクセスできます。 関数fを開始するには、abcdのすべての値が同時に必要です。 このようなレデューサーの組織では、アクションオブジェクト内の4つのabcd値すべてを転送することが唯一のチャンスです。 つまり、本質的には、ストアのほぼ完全なコピーをアクションオブジェクトに渡します。 あまり聞こえません。やる気がありません。

レデューサーを整理するもう1つの方法は、すべてのフォームフィールドを一度に更新する単一のレデューサーを使用することです。これは、formDataレデューサーの一種です。 フォームフィールドの以前の状態をabcdを含むオブジェクトとして取得し、変更された値を更新してから、ビジネスロジック関数fを実行します。 しかし、計算結果、つまり過剰支払xをどこに追加するのでしょうか？ formDataレデューサー内で、xを保存できる唯一の場所は同じオブジェクト内にあります。このオブジェクトには、abcdとxという5つのフィールドがあります。 このリデューサーの名前をformDataAndResult-reducerに変更するのは正しいことです。 彼はすべてを行います。フォームの変化を覚えており、ビジネスロジックの計算結果を覚えています。 5つのフィールドの1つの大きなオブジェクトにすべて含まれています。 それはあまり良く聞こえません。 脂肪減少剤が多すぎる。 Reduxは、レデューサーの構成のための機能的アプローチを設定します。 そして、ここでは、すべてを一度に管理するための1つの大きな関数を作成しています。

次に、コンテナコンポーネントでセレクターを起動します。 セレクターはmapStateToPropsの関数です。 最終結果xを表示するコンポーネントのセレクターに興味があります。 はい、ここでビジネスロジック関数を呼び出すことができます。 セレクターは状態全体、および新しいabcd値を持つ既に更新された状態にアクセスできます（これについては少し強調します）。 セレクター内で呼び出される関数fの計算結果は、過払いの金額を表示するコンポーネントの小道具に分類されます-これは完全に機能するソリューションです。

セレクターにない場合、ビジネスロジックを呼び出す最後の機会は、コンポーネントxのrenderメソッドで関数fを直接呼び出すことです。このメソッドは、支払い超過額を表示します。 これを行うには、小道具で、4つの必須abcd値すべてをスキップする必要があります。 私の意見では、これは以前のものよりもエレガントなソリューションではありません。 セレクターは、計算を開始し、既製のxを渡して表示するのに適切な場所のようです。

すべてのオプションを検討しました。 まあ、ほとんどすべて。 コンポーネントで計算を開始するなどの物の言えない方法については、小道具を受け取るか、または何か他のものを思いつくことができました。 しかし、時間を無駄にしないようにしましょう。

合計で、ビジネスロジックを起動するための2つの明白な候補があります。これはアクションクリエーターとコンポーネントセレクターxです。

アクションクリエーターの詳細をご覧ください。 最初に、「フォームのすべてのフィールドに対して1人のアクションクリエーターを使用するか、フィールドごとに個別の関数を使用する」という質問に答えます。 別々の関数を作成すると、4つのアクション作成者、changeA、changeB、changeC、changeDが得られます。 実際には、2滴の水のように互いに似ています。 アクションクリエーター内で関数fを呼び出す場合、これらの呼び出しを4つの関数すべてのコードにコピーする必要があります。 コピー＆ペーストがたくさん。 Reduxと密接に連携している人なら誰でも、定型コードは恐れません。 ここでファクトリを整理できます-コードをコピーしないようにアクションクリエーターを作成します。

しかし、この方向に深く入らないことをお勧めします。fieldNameとnewValueを受け入れるアクション作成関数を1つ説明しましょう。 fieldNameは、ユーザーが何かを入力した入力フィールドを示す文字列変数です。 Redux-thunkを使用すると、アクションクリエーター内の現在の状態全体にアクセスできます。これは、関数fを呼び出すために必要なものです。

ただし、関数fは最新のabcd値を取得する必要があり、Reduxサンクのおかげで取得する状態はすでに古い状態であることに注意してください。 フィールドの1つには古い意味があります。 関数fを呼び出す前に、newValueを置き換えるパラメーターを理解する必要があります。 JSシンタックスの観点から、ここでは多くのエレガントでそれほどそうではないソリューションを思いつくことができます。 ただし、アクションクリエーター内でfを呼び出したい場合は、現在の状態、つまり すでに時代遅れで、到着したばかりのnewValueと組み合わせます。 これは、まったく同じことを行うリデューサー関数を思い出させませんか？ 最新のabcd値を形成するために、アクション作成者内でレデューサーのロジックを複製する必要があることがわかります。

さらにもっと。 アクションクリエーター内でビジネスロジック関数を呼び出した結果を取得したと仮定しますが、今度はxの結果の値を、支払い超過額を表示するコンポーネントに渡す必要があります。 適切なリデューサーとセレクターを作成して、Reduxストアを転送する必要があります。 これを行った後、ストアはabcdという形式のデータを格納すると同時に、xを評価した結果も格納することに注意してください。 ストアは冗長であることが判明しました。 ソースデータに加えて、微分計算の結果も含まれます。 これは多くの理由で良くありません。 以前のリリースでそれらのいくつかについて説明しました。 結論：アクションクリエーターは、ビジネスロジック関数を呼び出すための適切な選択肢ではありません。

セレクタからビジネスロジック関数を呼び出すオプションに渡します。 私はすでにそのメカニズムについて上記で言及しました。 過払い額を表示するコンポーネントのセレクターは、ストア全体にアクセスできます。 そして、最も関連するabcd値。 レデューサーコードの重複はありません。 セレクター内にabcdがある場合、fを呼び出し、xの結果を小道具として、過払い額を表示するコンポーネントに渡します。 コードの重複や冗長性のないシンプルで論理的な。 セレクタは、データの純粋な関数で表されるビジネスロジック関数を呼び出すのに最適な場所です。

クライアントでのコンピューティングのみを検討した最後のフレーズに焦点を当てます。 あなたのビジネスロジックが純粋な機能ではなく、サーバーへの旅行を伴うプロセス全体である場合、すなわち いくつかの副作用がある場合、これは別の議論のトピックです。 ここでは、アクション作成者とミドルウェアの両方に注意を払うだけです。 しかし、それについてはまた別の機会に議論します。

Reactで書いて繁栄しましょう！

PS 次のポッドキャストには鋭い質問と回答があります。