問題タブ [redux]

私の Flux アプリはリストの場所を表示します。ユーザーが場所をクリックすると、「アクティブ」になります。一度にアクティブな場所は 1 つだけです。

場所の状態は、場所自体のプロパティである必要がありますか (例: location.active)、またはグローバルな状態の一部である必要がありactiveLocationIdますか?

Reduxフレームワークはレデューサーを使用して、アクションに応じてアプリの状態を変更します。

重要な要件は、レデューサーが既存の状態オブジェクトを変更できないことです。新しいオブジェクトを生成する必要があります。

悪い例:

良い例:

これはImmutable.jsの適切な使用例です。

反応時間の長いプロセスは、react+redux アプリのどこで「ライブ」する必要がありますか?

簡単な例として、websocket を介してメッセージを送受信するクラスを考えてみましょう。

このクラスのライフサイクルはどのように管理する必要がありますか?

私の最初の本能は、それを維持することstoreです:

しかし、少し奇妙であることは別として、が関数にWebsocketStreamerアクセスする方法がなくdispatch()、ホット リロードが中断されます。

別の潜在的な解決策は、それをどこかのグローバルに保持することです。

しかし、これには明らかなテスト容易性への影響があり、ホット リロードも中断します。

では、長時間実行されるプロセスは、react + redux アプリのどこに置くべきでしょうか?

注: この単純な例は、ストアとアクション プロバイダーだけで構築できることがわかりました。しかし、長寿命のプロセスが存在する状況で、そのプロセスがどこに存在するべきかを具体的に知りたいです。

地図アプリを開発しています。これは、次の 2 つのコンポーネントで構成されています。

• 現在のユーザーの場所を表示するコンポーネント。と
• 住所の候補がある住所検索コンポーネント。

これらのコンポーネントは、次の状態ドメインに依存しています。

ユーザーが住所候補リストから住所を選択すると、イベント ハンドラーが呼び出されますonSelectAddress。onSelectAddress2 つの状態変化をトリガーする必要があります。

• userLocation新しい場所に設定します。と
• 場所の選択プロンプトを閉じるよう通知する

これを設計する正しい方法は何ですか？

• スマート コンポーネントが 2 つのアクションを次々にディスパッチする必要がありUSER_LOCATION_CHANGEますADDRESS_SEARCH_HIDE。また
• スマート コンポーネントは、USER_CHANGE_LOCATION2 つの異なるレデューサーによって処理される単一のアクション (例: ) をディスパッチする必要がありますか?

最近Reduxを発見しました。それはすべてよさそうだ。Redux over Flux を使用することの欠点、落とし穴、または妥協点はありますか? ありがとう

私の州

次の形式のアイテムの配列があります。

[{ left: 0 }, { left: 10 }, { left: 20 }]

{ left: 30 }この配列に項目を追加できます。

[{ left: 0 }, { left: 10 }, { left: 20 }, { left: 30 }]

{ left: 20 }この配列に重複する項目を追加できます。

[{ left: 0 }, { left: 10 }, { left: 20 }, { left: 20 }, { left: 30 }]

私の見解

これらのアイテムを平面上の位置 x にレンダリングする必要があります。ここで、x は左のプロパティです。

[{ left: 0 }, { left: 10 }, { left: 20 }]レンダリング|item1 item2 item3|

[{ left: 0 }, { left: 10 }, { left: 20 }, { left: 30 }]レンダリング|item1 item2 item3 item4 item5|

重複がある場合は、要素を左また​​は右にシフトして、この重複を解決する必要があります。そう

[{ left: 0 }, { left: 10 }, { left: 20 }, { left: 20 }, { left: 30 }]レンダリング|item1 item2 item3 item4 item5|

したがって、それらは重複してはなりません。

新しいアイテムを 1 つずつ追加できます。新しいアイテムは、10 の倍数の left プロパティを持つことができます。

オーバーラップの場合、アイテムは右にシフトしてオーバーラップを解決する必要があります。

これにより、複数のアイテムが右にシフトする可能性があります。

例：

[{ left: 0 }, { left: 10 }, { left: 20 }, { left: 20 }, { left: 30 }, { left: 40 }]

これを解決するには、左のプロパティ 30 と 40 で両方の項目をシフトする必要があります。

[{ left: 0 }, { left: 10 }, { left: 20 }, { left: 30 }, { left: 40 }, { left: 50 }]

アイテムの移動は、アニメーション化/トゥイーンする必要があります。React および Flux アーキテクチャでこの要件を適用するにはどうすればよいですか?

A.モデルの左側のプロパティを微調整し、トゥイーンを使用してビューの変更を反映することにより、ストア内の重複を解決します。- React コンポーネントでトゥイーンへの変更を反映するにはどうすればよいですか? - オーバーラップを解決するにはどうすればよいですか?

React ベースの SPA をサーバー側でレンダリングしたいと思います (最近はそうではありません)。したがって、React をreact-router、redux 、およびisomorphic starterkitのようなビルド レイヤーと組み合わせたいと考えています。

すべてを結合するhapi Universal reduxがありますが、フローを整理する方法に苦労しています。私のデータは、REST API の複数のエンドポイントから来ています。コンポーネントが異なればデータのニーズも異なり、クライアントにジャスト イン タイムでデータをロードする必要があります。サーバーでは、特定のルート (コンポーネントのセット) のすべてのデータを取得し、必要なコンポーネントを文字列にレンダリングする必要があります。

私の最初のアプローチでは、redux のミドルウェアを使用して非同期アクションを作成しました。これは、データをロードし、promise を返し、SOME_DATA_ARRIVEDpromise が解決されたときにアクションをトリガーします。次に、レデューサーがストアを更新し、コンポーネントが再レンダリングされます。すべて問題ありません。原則として、これは機能します。しかし、ルーティングが始まると、流れがぎこちなくなることに気付きました。

多数のデータ レコードを一覧表示する一部のコンポーネントには、レコードをフィルター処理するための複数のリンクがあります。フィルタリングされたすべてのデータ セットは、 のような独自の URL を介して利用できる必要があります/filter-by/:filter。そのため、さまざまなコンポーネントを使用<Link to={...}>して、クリック時に URL を変更し、ルーターをトリガーします。ルーターは、現在の URL によって表される状態に従ってストアを更新する必要があります。これにより、関連するコンポーネントが再レンダリングされます。

それを達成するのは容易ではありません。最初にアクションをトリガーしようとcomponentWillUpdateしました。これにより、データが非同期に読み込まれ、ストアにデータが入力され、コンポーネントの再レンダリング サイクルがもう 1 回発生しました。ただし、これはサーバーでは機能しません。3 つのライフサイクル メソッドしかサポートされていないためです。

だから私はこれを整理する正しい方法を探しています。ユーザーの観点からアプリの状態を変更するアプリとのユーザー インタラクションは、URL を更新する必要があります。IMOこれにより、ルーターは何らかの方法で必要なデータをロードし、ストアを更新し、調整プロセスを開始する必要があります。

だからinteraction -> URL change -> data fetching -> store update -> re-render。

initial state要求された URL からロードするデータを決定し、その状態をstore生成して reduxの生成に渡すことができるため、このアプローチはサーバーでも機能するはずです。しかし、私はそれを適切に行う方法を見つけていません。したがって、私には次のような疑問が生じます。

1. まだ理解していない/知らないことがあるため、私のアプローチは間違っていますか?
2. redux の REST API からロードされたデータを保持するのは正しいstoreですか?
3. stateコンポーネントをredux に保持し、store他のコンポーネントを自分で管理するのは少し厄介ではありstateませんか?
4. 持っているという考えはinteraction -> URL change -> data fetching -> store update -> re-render単に間違っていますか？

私はあらゆる種類の提案を受け付けています。