ReactとReduxのサンクをメンテナンス可能な方法でサーバ/接続例外を処理する方法

Question

Reduxサンクを使用して、サーバへのフェッチや投稿などの非同期アクションをディスパッチしています。それぞれのアクションクリエータコールは約束を返します。これは、ajaxがマジックを行った後、そしてReduxが実際にajaxの成功/失敗に従って状態を更新するための正しいアクションを送出したときに解決されます。このようにして、コンポーネントレベルでディスパッチ後のコールバックをカスタマイズできます。

componentsDoPostHandler(data) { 
    this.props.doPostActionCreator(data) 
    .catch(error => { 
     alert(error) 
     this.setState({...}) 
    }) 
} 

すべてがこの単純な例で結構ですが、私はこのパターンでロジックを処理し、実際のエラーを導入しようとすると、キャッチ内から再帰的にcomponentsDoPostHandlerを呼び出し、そして、カウンタ壊すような -

doPostActionCreator(data) { 
    return dispatch => { 
    return httpService.post(data) { 
     .then(response => { 
     dispatch({type: POST_SUCCESS, data: response}) 
     return response 
     }) 
     .catch(error => { 
     dispatch({type: POST_ERROR}) 
     return error 
    )} 
    } 
    } 
} 

制限が超過すると、物事は醜く見え始め、維持しにくくなり、壊れやすい。私の実際の世界のシナリオでは、実際にはfetchCsrfTokenActionCreatorのコールバックであり、それ自体が同じエラー処理ロジックを必要とし、X回フェッチして失敗した場合は何か他の処理を行う必要があります。今では、1つのページに2つの異なるコンテナが含まれていて、どちらもこのロジックを紹介している場合、アクションクリエイターと呼ばれると取り消すことはできないため、最初にリカバリを実行した後、結局のところ、プログラムがどのように動作しているのかを知ることは難しく、「同期が外れている」アクションの問題が発生し始め、アプリケーションが不整合な状態になり、問題を追跡するのが困難になります。

アクションクリエイターからの約束を返すのが実際に反パターンであり、最終的には維持できないコードにつながるのではないかと思います。 React/Reduxスタックを使用して非同期サービスエラーを処理する方法を実際の例では見つけられませんでした。私はそれを間違っているのですか？非同期の例外を処理するためのよりクリーンな方法があります（理想的にはX回試し、ユーザーに警告してログインページに戻ります）。

トピックに関する任意の実世界の例は非常に私はあなたがアクションの作成者自身の中にあなたの再試行ロジックのすべてを扱うことができると信じて

Answer 1

をいただければ幸いです。つまり、コンポーネントから、またはアクション作成者に電話しているどこからでも、.catch()に電話をかけるために何かを返す必要はないと思います。サンクのgetState()メソッドにアクセスできることを忘れないでください。つまり、アクション作成者の.post().catch()には、何かが失敗したことを示すために何かをディスパッチできます。これはおそらく失敗の数を追跡する減速器によって処理できますディスパッチコール.getState()は、そこにいくつの失敗があったかを確認し、そこから何をすべきかを決定します（つまり、もう一度やり直すか、何かが何度も失敗したことを示す別のアクションを送ります。状態）。

あなたが見ている問題を簡略化すると、私はアクションクリエイターの外で.catch()を心配しないと思います。このロジックをいくつかのアクションクリエータで発生させたい場合は、このロジックを処理するAPI呼び出しメソッドに抽象化することができます。