React、Redux、およびRedux Sagaアプリでコンポーネント間で共有されているエラーとisFetching

Question

ReduxとRedux Sagaを使用したReact Nativeアプリがあります。私はIgniteのスターターのパターンも使用しています。また、他の多くの場所で使用されています。状態には、isFetchingフラグとAPI呼び出しが行われたときのエラーを表す「error」プロパティがあります。 APIコールの結果として発生します。

Reduxストアをドメインや機能別に分割することをお勧めします。また、コンポーネントとReduxファイルの間に1対1の関係を持たせることは、一般的には良い考えではありません。

今、クレジットカードの支払いや管理ができるアプリがいくつかあるとしましょう。だから私の場合、私は "支払い"は良いドメインかもしれないと思っています。たとえば、画面Aでクレジットカードを使用して支払いを行い、画面Bに新しいクレジットカードを追加することができます。これを処理する2つのサガ、getCards sagaとmakePayment sagaがあります。どちらも、isFetchingフラグがtrueに設定されている、対応する「要求」アクションを持っています。そこから、それぞれがいくつかのAPI呼び出しを行い、データを変換してから、新しいデータでPaymentRedux状態を更新します。完了すると、isFetchingフラグをfalseに更新します。エラーが発生した場合は、適切なエラータイプで状態を更新します。

しかし、1つの画面の読み込みインジケータまたはエラー状態が、別の画面で開始された可能性のある結果に本当に結びついている必要がありますか？たとえば、画面Aで何らかの理由で支払いが失敗した場合、画面Bに移動します。画面Aで発生した無関係のエラーを画面Bに知らせますか？

だから私の質問は以下のとおりです。

1. は、これが最初の の場所で私のReduxの状態のための賢明なスプリットでしょうか？そして、私はこのように私の異なる画面間で状態を共有する必要がありますか？
2. エラー/ isFetchingを処理するにはどうすればよいですか？操作ごとに1つずつ、複数の "isFetching"フラグがありますか？各画面は興味のある特定のエラータイプに登録するだけですか？

推奨パターンが何であるか不思議です。アドバイスをいただければ幸いです。ありがとう！

Answer 1

私はあなたの状況では、このレデューサーを2つに分割する方がよいと信じています。したがって、お支払いレシピターとクレジットカードレデューサーがあります。クレジットカードの減額は、クレジットカードの追加、削除、変更に関するすべてのデータの責任を負います。支払いの減額が成功した場合、注文番号、使用されたクレジットカードなどの支払い状態を処理します。

これは非常に主観的です.Reduxに適切な方法がないためです。あなたは2つの減速を持つことが本当に必要だとは思わない場合は、多分あなたは、このように、以下のように同じ減速の両方の状態を有する、自身に支払減速を分割することができます：

const INITIAL_STATE = { 
    payment: { 
    error: null, 
    fetching: false, 
    ... 
    }, 
    creditCards: { 
    error: null, 
    fetching: false 
    } 
} 

この方法では、あなただけを実装する必要がありますセレクタ、およびアクションハンドラを使用して、状態をモデル化します。