問題タブ [reactjs-flux]

Flux のほとんどの例では、todo またはチャットの例を使用しています。これらすべての例では、保存しているデータセットはやや小さく、ローカルに保持されているため、ストアの計画された使用が流動的な「方法」に沿っているかどうかは正確にはわかりません.

私がストアを使用する方法は、ORM リポジトリに似ています。複数の方法でデータにアクセスし、データ サービスにデータを永続化する方法。

プロジェクト管理システムを構築しているとしましょう。おそらく、データ取得には次のような方法があります。

• getIssueById
• getIssuesByProject
• getIssuesByAssignedUser
• getIssueComments
• getIssueCommentById
• 等...

データ サービスにデータを永続化するために、次のようなメソッドも用意します。

• 問題を追加
• 更新の問題
• 問題の削除
• addIssueComment
• 等...

私がしない主なことの 1 つは、課題データをローカルに保存することです (さらに言えば、ほとんどの場合、データ ストアに関連するデータを保存します)。その問題を最後に取得してから問題のステータスが更新された可能性があるため、ほとんどのデータは最新のものであることが重要です。私のすべてのデータ取得メソッドは、おそらく常に最新のデータに対して API リクエストを行うでしょう。

これは流動的な「方法」に反していますか? このようにフラックスを使用することに問題はありますか?

次のコンポーネントがあります。

何らかの理由で、_handleButtonClick イベントがまったく発生しません。ボタンを含めるさまざまな方法を試しましたが、何らかの理由で、このボタンはイベントを発生させたくありません。ここで同様の例を見ることができますhttps://github.com/facebook/flux/blob/master/examples/flux-todomvc/js/components/Footer.react.js#L48のように見える Flux TodoMVC サンプルアプリケーションで動作しますが、上記のコードでは何らかの理由で、クリック イベントがボタンに関連付けられていません。

何か案は？

FLUX アプリケーションでは、初期化などのアクションを介して、特定のデータ セットがストアに取り込まれます。次の場合はどうしますか。

1. ストアは段階的に初期化する必要があります。(一度に 1 人ずつユーザーを追加します)。
2. ユーザーが既にストアにいる場合は、しばらく経っていない限り、ユーザーを再度フェッチしないでください。

異なるアクション クリエーターで HTTP リクエストを行うと、必要以上のリクエストが発生するようです。2 レベルのキャッシュが必要ですか? アクション HTTP API レイヤー (アクション作成者) に 1 つ、ストアに 1 つ? これは冗長に見えませんか？

「カートに追加」ボタンを作成するために、反応を少しいじっています。これが私のコードです。

私が興味を持っているのは、この ajax ハンドラーです。これらのイベントをどこに導くべきかわからないことを除いて、反応の全体的なポイントはコンポーネント間の相互運用性であると確信しています。成功した場合はカート カウント インジケーター、失敗した場合はエラー アラートなど、いくつかの異なるコンポーネントを想像できますが、これらを利用する方法が正確にはわかりません。これがフラックスのディスパッチャーの要点ですか?

Flux パターンでは、ストアがリッスンするビューに対して複数のイベントを宣言しても問題ありませんか? たとえば、listChanged、selectedListItemChanged などです。フローを中断せず、ストアからビューにいくつかの下向き矢印を追加するだけなので、(これまたは変更イベントで追加のパラメーターを渡す) 一見、正当に思えます。

具体的なレンダリング ライブラリにバインドされていない一般的なパターンを探しているため、意図的に "React" を省略しました。また、stateChanged イベントが 1 つあると、ReactJs の魔法がなければ、レンダリング プロセスが非常に複雑になります。

モーダルと通知は、本文に追加されるコンポーネントです。そのため、通常のコンポーネントとは少し異なります。私のアプリでは、それらを実装する 2 つの方法を考えることができますが、どちらが優れているかわかりません。

1. 店舗なし

このアプローチでは、create メソッドを持つ NotificationHelper クラスを作成します。その中で、新しいコンテナ ノードを作成し、それを本体に追加してから、React.render(, container); を呼び出します。

そのため、どのコンポーネントでも NotificationHelper.create() を呼び出すことができ、通知が作成されます。ライフサイクルを管理し、タイマーが切れるか誰かが閉じるボタンをクリックすると閉じる通知コンポーネント。

多くの場合、問題は XHR 応答 (成功または失敗) に応じてページに通知を表示する必要があるため、actionCreator では次のようなコードを作成します。

新しいコンポーネントをレンダリングするアクションクリエーターからこのようなものを呼び出すのが正しいかどうかはわかりません。

2. 店舗あり

もう 1 つの方法は、NotificationStore を作成し、emitChange で通知コンポーネントをレンダリングすることです。コードは次のようになります

私のApp.jsでは、コードは次のようになります

そして、NotificationContainer で、次のようなことを行います

そして最後に、アクションクリエーターは次のようになります

このアプローチの問題は、ストアの追加のオーバーヘッドです。Store はここで意味のあることを行っているわけではありません。流れに従うだけです。アクション クリエーターからストアにデータを渡し、コンポーネントがストアから同じデータを取得してレンダリングします。そのため、実際には何も得られずにフラックス サイクルを終了します。

また、この時点では通知がありませんが、アプリの開始時に NotificationContainer を初期化する必要があります。