1

エラーデータをストアに追加したくなります。例えば、

var store = {
      error: {msg:'',info:{}},
      others: '',
      etc: ''
}

アプリでエラーが発生すると、アクションによってディスパッチャを介してエラーが更新され、エラー パネルがユーザーに表示されます。エラー パネルのレンダリングは、エラー メッセージの状態をテストすることにより、条件付きで div を表示します。

次のユーザー入力、アクション、つまり userAction で、モデルの状態がディスパッチャーによって更新されます。問題: エラー メッセージの状態が「リセット」されていないため、エラー パネルが引き続き表示されます。

userAction は、他の非エラー状態を設定します。Flux は、この変更に対して変更を発行します。それでも、Flux モデルに従う場合、このアクションでエラーのリセットも実行する必要がありますが、それによってエミットが発生し、UI に更新するように指示されます。間違っているようです。

私の考えは次のとおりです。 1. この種のものを店に置かないでください。または、 2. ストアは、状態のエラー以外の更新ごとにエラー状態をリセットします。または、 3. 各アクションには、状態更新のエラー状態オブジェクトも含まれます。

現在、私の解決策は、ストア関数内のエラーデータをクリアすることです:

}, function(payload){
    API.setError({msg:'',info:{}});

    switch(payload.actionType){
        case "BRANCH_SELECTED":

これを行う非慣用的な方法は何ですか？私は React と Flux を初めて使用するので、これは初心者の質問だと確信しています。Flux の実装としてMcFlyを使用しています。

4

1 に答える 1

0

あなたの質問はコメント内で既に回答されているかもしれませんが、現在のReactプロジェクトで同様の質問について瞑想したので、私の経験と結果を共有します。私は McFly の代わりにフラックスサーを使用していますが、ここでは問題ありません。

フラックスストアにはすべてのアプリケーションの状態とロジックが含まれている必要があるため、ストア関数内で条件付きでエラー状態をプログラムでクリアしても、フラックスアーキテクチャの意味ではまったく問題ないという結論に達しました。

私の理解では、特定のストアに関連するエラー状態の処理を正確にそのストア内に保持することは理にかなっています (したがって、おそらくいくつかのリッスン コンポーネントによって受信およびレンダリングされます)。@fisherwebdevで言及されているように、ストア ロジックは、具体的にはコールバック関数を登録したアクション タイプに基づいて、エラーの状態を判断する必要があります。あなたの場合、BRANCH_SELECTION_ERRORエラー状態を設定する型アクションがディスパッチされると考えてください。一方、BRANCH_SELECTEDアクション タイプは常にこの状態をクリアする必要があります。

私の具体的な解決策は、実際には「プライベート」ストア関数を呼び出すclearErrorMessages()かclearFormValidationMesssages()、現在ディスパッチされているアクションに依存する状態変数を単純にクリアすることです。

グローバル エラー、つまり、サーバー通信タイムアウトなどのアプリケーションの状態に関連するエラーは、何らかの「appStore」に入り、同等の方法で更新またはクリアされる場合があります。たとえば、ルーターの遷移によって、グローバル エラー状態がクリアされる場合があります。

于 2015-04-27T08:53:59.800 に答える