問題タブ [redux]

成功/エラー応答に対して異なる通知バーを表示したいので、次のように、反応コンポーネントの redux async アクションに 2 つの callBacks を渡します。

asyncAction は次のようになります。

これはパターンに反すると考えられますか? つまり、コールバックではなく、状態の変化に応じて通知バーを開く必要がありますか?

redux-formは、react アプリケーションのフォームに redux バインディングを提供するための非常に魅力的なライブラリであり、非常に便利です。残念ながら、ライブラリの独自の例を使用すると、実際には何もバインドできず、非常に不便です。

プロジェクト サイトのサンプル コードを使用しようとしていますが、忠実に再現しようとしても、複数の障害が見つかります。この API のどこを誤解していますか? デモ コードが作成されてから API は変更されましたか? いくつかの重要で明白な還元知識が欠けていますか?

問題 1 : handleSubmit メソッドの署名はhandleSubmit(data). しかし、handleSubmit は現在、送信アクションから React SyntheticEvent のみを受信して​​おり、データは受信していません。onSubmit(実際、この例をそのまま使用すると、2 つの別個のイベントが送信されます。これは、フォーム上とボタン上でアクションが積み上げられているためと思わonClickれます。) そのデータはどこから来ているはずで、なぜ私はそれを渡せなかったのですか?ハンドラーに？

問題 2 :fieldsフォームの親で定義し、フォームの小道具として提供する必要がある重要なオブジェクトがあります。残念ながら、そのfieldsオブジェクトの形状はドキュメントでは説明されておらず、その目的も実際には説明されていません。それは本質的に初期の「状態」オブジェクトですか？実行時にエラーなどに使用する redux-form の単純なオブジェクト コンテナーですか? fieldsのフィールド名にprops を一致させることでエラーを停止するようにしましたconnectReduxFormが、データがバインドされていないため、正しい形状ではないと想定しています。

問題 3onBlur : フィールドは、およびのハンドラーに自動バインドされるonChangeため、ストアが適切に更新されます。それは決して起こっていません。(これは、Redux dev-tools のおかげでわかります。ただし、アクションhandleSubmitのディスパッチに成功しています。initializeこれは、ストア、リデューサー、およびその他の基本的な配管がすべて機能していることを示しています。)

問題 4 : validateContactinit で一度発火しますが、二度と発火しません。

残念ながら、これは単純な Fiddle には複雑すぎますが、レポ全体 (基本的な ReduxStarterApp とこのフォーム POC に加えて)はこちらから入手できます。

そして、ここに外側のコンポーネントがあります：

内部フォーム コンポーネント:

Redux(+React) を使用して階層構造を操作していますが、2 つの質問があります。

1. Reduxでポリモーフィズムを実装するには?
2. 「アクションバブリング」の作り方

私の質問はより正確に表現されています：

1. .

Redux を使用して、React で構造コード エディターを作成しています。構造エディターとは、ノードを含むツリー構造があり、アプリがプレーン テキストではなく AST で動作することを意味します。

これらのノードにはさまざまなタイプがあります (これは CSS ファイルを編集するためのエディターであるため、これらのタイプは「ルール」、「宣言」、「プロパティ」、「値」などですが、何らかのタイプを持っていることがより重要です) . したがって、JSにはプロパティtypeを持ち、typeその...タイプを決定するオブジェクトがあります;）

したがって、次のようなノードがあるとします。

そして、私はそのようなものを書くことができるようにしたいと思います:

store.dispatch({type: 'click', nodeId: 4})

クリック用。しかし、 type のノードをクリックすると、 type のruleノードをクリックする以外の効果があると思いますproperty。ポリモーフィズム (ただし<Node />、コードの重複を防ぐために 1 つの反応コンポーネントが必要です)。

スイッチ/ケースまたは独自のサブ関数を作成することでそれを達成できることはわかっていますが (アクションを関数に委譲することを意味します)、車輪を再発明したくありません。ポリモーフィズムのサポートは、私のアプリケーションだけでなく、多くのアプリケーションで役立つと思います。

では、Redux でポリモーフィズムを実現するにはどうすればよいでしょうか。

2.、
アクション バブリングに関する 2 番目の質問。たとえば、次のようなツリー構造を取得したためです。

そして、その構造をレンダリングする適切な React コンポーネントがあります (私はダム関数ベースのステートレスな React 0.14 コンポーネントを持っているので、コンポーネントのコードは今のところあまり重要ではないと思います)。とにかく<Node/>、単一の AST ノードを表すコンポーネントを取得しました。

たとえば、ユーザーが id=3 ( {type: 'property', name: 'display', id: 3},) のノードをクリックすると、アクションがノードの親 (この場合は id=2 の宣言ノードと id=1 のルール ノード) に自動的に「バブル」するようになります。

私の知る限り、Redux には「アクション バブリング」はありません。多分それはあるべきですか？それとも、私が達成したいことは他の手段で実現できるのでしょうか? (「アクション バブリング」とは、ブラウザの JavaScript イベントの「イベント バブリング」に似たものを意味します。バブリングしたいだけで、redux actionsDOM イベントをバブリングさせたくない (これはまったく別のことです)。アクションを還元したい私が「バブリング」と書いたとき、私は実装ではなく全体的な設計パターンを指しています。

そして、これらは私の2つの質問でした:)

redux の実際の例についていくつか質問があります。

1. ディスパッチを使用して ajax 呼び出しが直接行われる非同期の例とは異なり、実際の例ではミドルウェアを使用してこれに対処します。反応アプリで redux を使用する場合、どの方法が推奨されますか? なぜ？

   私の推測では、ミドルウェアは再利用可能であるため、複数の ajax 呼び出しを行う必要がある場合、異なる API パスがパラメーターとして渡される限り、1 つの汎用 ajax 呼び出しミドルウェアで十分です。しかし、ディスパッチでも同じことが言えます...

2. ミドルウェアはいつ実行されますか? ソース コードを見てドキュメントを読むと、次のように理解できますdispatch an action -> all middlewares get executed , ajax calls can be made here and the returned json data can be put inside the action object and pass it onto the reducers-> reducers get executed。私は正しいですか？

単純なreduxボイラープレート プロジェクトがあり、クラス宣言をインライン化する場合と比較して、トップ レベル (スマート) コンポーネントをインポートすると、異なる動作が発生します。

クラスを作成してもエラーは発生しませんが、クラスを別のファイルに抽出すると、次のエラーが表示されます。

ファイル全体をインライン化しようとしましたが、エラーはなくなりました

これがプロジェクトレポです（そのスーパーストライプバック）。

Redux は、単一の状態を持つ単一のストアの使用を提唱しています。ただし、react-router を使用すると、それぞれが独自の最上位ルート コンポーネントを持つ複数のページを取得できます。

複数のページを持つreact-routerアプリでreduxを接続するにはどうすればよいですか? React-router 1.0 では、props をルートに渡すことができなくなったため、ルーターをすべてのページの状態を含む最上位コンポーネントにすることは、もはや不可能であり、実現可能でもありません。

多くの場合に発生させたいグローバル ビュー (読み込み画面の表示など) がある場合、その動作に対してアクション クリエーター/アクションのペアを作成するか、関連するアクションのリデューサーを作成する方が適切ですか?移行を処理しますか？

これを簡潔に説明するのは難しいので、例をいくつか示します。どちらが優れていますか、なぜですか?

あ

B

状態管理のロジックを複製するよりも、これらの動作を 1 か所で説明する方が賢明だと思われるため、私は A を好みますが、redux コミュニティでは、アクションは必須ではなく、何が起こったか、または起こっているかを説明するべきであるという格言を聞いたことがあります。コマンド。どの場合、「ASYNC_OPERATION_START」のような用語が「SHOW_LOADING」よりも優れているという意味上の問題ですか?