1

私が読んだパターンから、コンポーネントはストアにサブスクライブするコンポーネントの値の変更をトリガーするストアに渡すアクションにデータを渡します。私の質問は、これらのトリガーされた更新に通知の形で「反応」する方法ですか? (つまり、正常に保存された通知)

つまり、サブスクライブしているオブジェクトに何らかのフラグ属性がある場合にのみ表示されるこの通知コンポーネントのレンダリングにロジックを追加する必要がありますか? その後、しばらくすると自分自身を削除します。これは間違っているように聞こえます。

アップデート

Hannes Johansson のおかげで、パターンをよりよく把握できたと思います。私が取り組んでいるのは次のとおりです。

  1. コンポーネントは、アクションを介してストアにデータを渡します

  2. Store は API と対話し、更新されたモデルがコンポーネントに通知されるようになったことを示すフラグをモデルに追加します。

    createItem: function (item) {
    $.ajax({
        url: '/items', 
        method: 'POST',
        data: item,
        success: function (item) {
            CurrentBrandActions.addCampaign(item);
            this.item = item;
            item.newlyCreated = true;
            this.trigger(item);
        }.bind(this)
    })
}

  3. コンポーネントはフラグを見て、「通知子コンポーネント」をレンダリングします

    var newlyCreated = this.state.item.newlyCreated === true;
if (newlyCreated) {
  newlyCreated = <ItemCreatedNotification item={this.state.item} />
} else {
  newlyCreated = '';
}
return (
  <form onSubmit={this.createItem} className="form">
    {newlyCreated}

  4. このイベントに基づいて、アプリを新しい場所に移動する必要があります。これは、a) 通知の子コンポーネント、b) 親コンポーネント、c) ストアである必要がありますか?

フラックス API パターンに関するColin Megill の話によると、API の相互作用はアクションで発生するはずですが、逆流は実際にはそれを許可しません。

更新 2

  1. コンポーネントは、呼び出されたアクションにデータを渡しますcreateItemRequest

  2. Action には、実際に API 呼び出しを行う preEmit フックがあります。はcreateItemRequestストアに続き、ストアは送信の状態を反映するようにモデルを変更できます。これは、コンポーネントに表示されます (おそらくスピナーを表示します)。このアクションは、API の結果に応じて、他の 2 つのイベントを発生させる役割も果たします。

    ItemActions.createItemRequest.preEmit = function (data) {
    $.ajax({
        url: '/items', 
        method: 'POST',
        data: data,
        success: function (item) {
            ItemActions.itemCreatedSuccess(item);
        },
        error: function (error) {
            ItemActions.itemCreatedError(error);
        }
    });
}
4

1 に答える 1

3

これにはさまざまなアプローチがあります。たとえば、Refluxでは、各アクションが実際には「ディスパッチャ」であるため、必要に応じてアクションを直接リッスンするのは非常に簡単です。

ただし、一般的な純粋主義者の Flux の原則は、ディスパッチャーにストアを登録するだけで、コンポーネントはストアの更新のみをリッスンするというものです。そして、ストアは何かが変更されたことを通知するイベントをトリガーするだけで、ペイロードを提供しません。次に、ストアの状態を読み取り、それをレンダリングする方法を決定するのは、コンポーネント次第です。

1つのアプローチは、あなたが説明するもので、ストア内のアイテムにフラグを立てて更新が発生したことを通知しますが、ストアのみを意味するため、コンポーネント自体が格納されたアイテムのフラグを更新すると、フラックスの原則に違反します状態を変化させ、他のソースからではなく、アクションに応答してのみ。したがって、その場合、「Flux のこと」はおそらく、新しく追加されたアイテムが記録されたことを通知する別のイベントをトリガーして、そのアクションに応答してストアがフラグをリセットできるようにすることです。

私が考えることができる別のアプローチは、ストアの更新が通知されたときにコンポーネントの状態を比較することです。次に、フラグをコンポーネントのみに保持するか、新しく追加されたアイテムを状態の別のリストに保持して、それらを個別にレンダリングします。

Flux のコア原則に従いたい場合は、コンポーネントがストアの状態を直接変更してはならないということを除いて、ここには厳格なルールはありません。これにより、Flux の主な目標である、一方向のデータ フローとデータに関する単一の信頼できるソースが可能になります。

于 2015-07-22T06:14:00.807 に答える