Reduxアクションクリエイターの役割で悩む

Question

私はredux "アクション"の正しい概念を得るのに苦労しています。これは、ユーザーインターフェイスで何が起こったかを表す単純なメッセージに似ていますか、それとも新しい状態をすべて保持している太ったレコードですか？

私が読んだReduxの例では、操作は常に操作のような単純なCRUDです。この例では、TODOを追加するときに、ビュー・ボタン・イベント・ハンドラー（またはTODOコントローラーと言う必要があります）は、すでに新しいTODOオブジェクトを含む新しいADD_TODOアクションを作成します。レジューサーは単にデータを挿入するだけです。レデューサーは「スマート」ではありません。

しかし、これにより、コントローラはアクションのデータを計算するための多くのロジックを持っています。シンプルなTODOアプリケーションでは問題ありませんが、より複雑なアプリケーションでは、これらのコントローラには多くの "ビジネスロジック"が含まれ、レデューサーには含まれません（後者は単にCRUD操作を実行するだけです）。

アクションを作成中にコントローラがクラッシュした場合、アクションはまったくログに記録されず、アクションログは重要なReduxセールスポイントIMHOの1つです。

アクションのデータを設定する複雑なコードでアクションを作成する際のガイドラインは何ですか？私はこれらのアクションクリエータの周りにtry/catchを入れ、別のログシステムを使うべきですか？複雑なアクションの作成を2つのアクションに分割する（または、エラーが発生した場合は3、非同期APIコールと全く同じように処理する）。

おかげで、 ピーター

Answer 1

はあなたのためにいくつかの明確化を手に入れました。

最初に、typeフィールド以外のアクションが含まれている必要があるかどうか、またはロジックの大部分をアクション作成者またはレデューサーに含めるべきかどうかに関する特別なルールはありません。 {type : "UPDATE_STUFF"}のアクションを持つことは完全に有効であり、レデューサーにすべての作業を行わせるか、アクション作成者に新しい状態を生成させ、レデューサーにreturn {...state, ...action.payload}を実行させるだけです。 Redux FAQ on where to put business logicの両方のアプローチの賛否両論とトレードオフ、そしてブログ記事Idiomatic Redux: The Tao of Redux, Part 2 - Practice and Philosophyの「アクションセマンティクス」と「厚いと薄いリキザーズ」のセクションについて、いくつかの議論があります。その投稿からの引用：

アクションクリエイターにもっと多くのロジックを置くことと、より多くのロジックをレデューサーに入れることとの間には、有効なトレードオフがあります。私が最近見た1つの良い点は、減速機にもっと多くのロジックがあると、時間旅行のデバッグ（一般的には良いことになる）の場合に再実行できることが増えていることです。

私は個人的に論理を一度に両方の場所に置く傾向があります。私は、アクションが派遣されるべきかどうかを判断する時間がかかるアクションクリエイターを作成します。しかし、私はしばしば、アクションの内容を見てレスポンスでいくつかの複雑な状態更新を行う、対応するレデューサーを書くこともあります。

私は通常、返信する場所の数を最小限に抑えようとしています。{...state, ...action.payload}このアプローチは、フォームの複数の可能なフィールドを更新するようなやり方で、フィールドごとに個別のupdateName/updateAge/updateWhateverハンドラを書きたくない場合には、間違いなく役に立ちます。

私はどちらも「イディオム的」であり、完全に有効な選択肢ではないと言いますが、レデューサーのロジックの面で間違っているといういくつかの利点があります。

だから、それは「スマート」レデューサーを持つこと結構です、と私は私の"Practical Redux" tutorial seriesに複雑な減速ロジックの例をいくつか持っています。

アクションクリエイターとレデューサーのどちらが発生しても、エラーとクラッシュは問題になります。実際、減速機に予期しないエラーがある場合、私はその動作がRedux DevToolsに正しく記録されないと考えています。

また、1つのアクションをディスパッチするか、複数の「トランザクションを構成するサブアクション」をディスパッチするかについての特別なルールもありません。私は私のポストでそれについていくつかの議論をしていますIdiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability。

最後に、質問のタイトルの行に沿って、私の投稿Idiomatic Redux: Why use action creators?を読むこともできます。

Answer 2

「行動」について語るとき、私はCRUDが正しい単語ではないと思う。あなたは、減速機を変態として考えるべきです。アクションは、変換に必要な特定の情報としての「ペイロード」を持つビジネスロジックです。

削減はスマートです。既存の状態を使用して次の状態を計算するためです。

どういう意味ですか？

...これらのコントローラに含まれる「ロジックはビジネス」がたくさん...

あなたが「複雑なコード」と「のtry/catch」の話..あなたの場合APIで作業したい場合は、redux-autoを使用してください。 documantasionから

：

redux-autoは、単にあなたが約束を返す「アクション」関数を作成できるようにすることで、この非同期の問題を修正しました。あなたの "デフォルト"機能アクションロジックに同行する。

1. 他のRedux非同期ミドルウェアは必要ありません。例えばサンク、約束-ミドルウェア、佐賀
2. は簡単にあなたはReduxのに約束を渡すことができますし、あなた
3. あなたは、彼らが「ファイルの命名
4. を変換する場所と同じ場所に配置外部サービスの呼び出しを可能にするためには、管理していますinit.js "はアプリの起動時に一度呼び出されます。これは、起動時にサーバーからデータをロードするのに適しています

考えてみるとそれぞれaction in a specific fileになります。 "保留中"、 "完了済み"、 "拒否済み"のレデューサー機能を使用してサーバーコールをファイル内に配置します。これにより、取り扱いの約束事は非常に簡単になります。

また自動的にhelper object(called "async")をあなたの状態のプロトタイプに添付して、あなたのUIを追跡し、遷移を要求することができます。

希望します。