これは非常に良い質問です。 それを上げてくれてありがとう！

これは、ツリーの再計算を手動でプルーニング/最適化する場合です。 計算に関連するコンテキスト変数へのアクセスを要求する必要があるように思われます。 必要に応じて、完全なコンテキスト（または完全なコンテキスト）のハッシュを渡すなど、他の凝ったことを行うことも検討できます。

@ sebmarkbage-考え？

ええ、問題は、中間のコンポーネントが、遠くの子供がどのようなコンテキストを必要とするかを知らないことです。 どのcontextTypesを宣言して、 shouldComponentUpdateを正しく実装できるかを知る方法はありません。

途中で偽のshouldComponentUpdateによってブロックされることなく、コンテキストの伝播が別のツリートラバーサルで発生する可能性があるのでしょうか。

基本的に、親のコンテキストが変更されると、どれほど離れていても、このコンテキストを受け取るすべての子孫をダーティとしてマークする必要があります。 祖先のコンテキストの変更は、このコンテキストをオプトインする子孫の状態の変更と同じ効果を持つはずです。親の発言に関係なく、新しいcontextを受け取る必要があります。

@gaearonその場合、すべてを再レンダリングする必要があると思います。そのため、 shouldComponentUpdateはサブツリーを枝刈りする効果がありません。 そうしないと、コンテキストが要素ツリーと矛盾した状態になります。

@andreypopp

中間コンポーネントのshouldComponentUpdateは、新しい状態を受け取るかどうかに影響しないのと同じように、子孫が新しいコンテキストを受け取るかどうかに影響しないはずだと思います。

http://jsbin.com/geseduneso/2/edit?js、output

（この場合、両方の数値が増加します）

矛盾はどこにありますか？

言い換えると、私は思いますcontextコンテキストの所有者は、その結果その中に「ストア」のようなものがあった場合とまったく同じ動作するはずですgetChildContext()で書き込まれますcomponentWillUpdate 、そして、 contextTypesでそのコンテキストからキーを宣言したすべての子孫コンテキストコンシューマーは、あたかもその「ストア」にサブスクライブして自分の状態を更新したかのように、そのコンテキストを受け取る必要があります。

実際の実装を意味するわけではありませんが、このモデルが、中央にshouldComponentUpdateがあるFluxアプリよりも一貫性がないことを示したいと思います。 コンテキストは「サイドウェイストレージ」のように機能する必要がありますが、スコープはサブツリーです。

編集：親が変更される可能性があるため、これは機能しません

私はIRCでGlenjaminと話をしましたが、彼はコンテキストを変更すること自体が悪い考えかもしれないと確信しました。 ルートの更新によって暗黙的に異なる子の更新が発生した場合、何かが更新された理由を推論することができなくなります。

しかし、私が見る唯一の合理的な解決策は、コンテキストの変更を完全に禁止することです。 つまり、 getChildContext()をgetInitialState()と同様にします。これは、コンポーネントがマウントされる前に1回だけ呼び出されます。

これにより、コンテキストについて考えるのが非常に簡単になります。 コンテキストが更新されないため、 shouldComponentUpdateから3番目のパラメーターを削除できます。

コンテキスト所有者からの更新が_必要_な場合（たとえば、react-routerがActiveState mixin cc @mjacksonで使用するためにactiveRoutesをトップダウンで渡すことを望んでいる場合）、 { addChangeListener, removeChangeListener, getActiveRoutes }を渡すことを妨げるものは何もありません。 context 。 子孫は変更をサブスクライブしてstate入れることができるようになりました。

これは合理的な解決策ですか？

答えるべき重要な質問は次のとおりです。

どのシナリオで、 propsを介してデータを渡すか、コンポーネントが独自のsetState呼び出すようにイベントをトリガーするよりも、 contextを介して_data_を渡す方が望ましいです。

私はオブジェクト参照を渡すためにコンテキストを使用してきました。私はそれらのオブジェクトに書き込むだけで、読み取ることはないからです。 例えば。 this.context.triggerAction("something")

コンテキストのユースケースは、潜在的に大きなサブツリー全体に適用できるが、より一般的なコンテナーノードを通過させたくないパラメーターの場合です。 例として、カラーテーマがあります。このテーマでは、多数のノードが、背景色が白か黒かを確認するためにリッスンする場合があります。 それらをパラメータとしてどこにでも渡したくないでしょう。

getChildContext（）をgetInitialState（）のように動作させても、実際には問題は解決しません。これは、特定のコンテキスト値を提供する親ノードを、別のコンテキスト値を提供する別の親ノードにいつでも置き換えることができるためです。 影響を受けるサブツリーの場合、これはコンテキスト変数の値を変更することと区別がつきません。

ユーザーが変更リスナーを接続することを回避する解決策を見つけることができると思います。

@andreypoppは正しいかもしれないと思います。 または、少なくとも、shouldComponentUpdateがコンテキスト内の何かが変更されたかどうかを知る方法を提供する必要があります。これにより、コンテキスト変数が変更された場合に常にtrueを返すように決定できます。

今日の後半に@sebmarkbageとチャットして、彼の考えを確認します。

getChildContext（）をgetInitialState（）のように動作させても、実際には問題は解決しません。これは、特定のコンテキスト値を提供する親ノードを、別のコンテキスト値を提供する別の親ノードにいつでも置き換えることができるためです。 影響を受けるサブツリーの場合、これはコンテキスト変数の値を変更することと区別がつきません。

痛い。 あなたは完全に正しいです、私はこれを考慮していません。

@jsfb考え直してみると、あなたのコメントがよくわかりません。 親ノードを置き換えると、とにかく子サブツリー全体が再マウントされますね。

現在、はい、再マウントされますが、それは部分的に実装の詳細です。 ノードの状態を失うことなくサブツリーの親を変更することを想像できます（そして、その実装と影響について説明してきました）。

@sebmarkbageと私はチャットし、次の結論に達しました。

• shouldComponentUpdateは複雑なエスケープハッチであり、その実装には、コンポーネントの下で何が起こっているかをしっかりと理解する必要があります。 このため、使用されているプロパティとその使用方法をすでに知っている必要があるため、使用されているコンテキスト変数を知っていると想定するのは不合理ではありません。
• この変更は、おそらく状況を以前よりもそれほど悪化させるものではなく、古い「所有者」関係を使用するよりも改善されています。 したがって、この問題はまだ議論する価値がありますが、おそらく非ブロッキングです。
• コンテキストは現時点では複雑な機能/実験であり、公式にサポート/文書化する前に、おそらくさらに検討する必要があります。 詳細については、このトピックについて繰り返し説明します。

@sebmarkbage 、何か見逃したことがあれば教えてください！

でも良い議論です！ すべてのフィードバックをありがとう！

これについて議論するために時間を割いていただきありがとうございます！

どのプロパティが使用されているか、およびそれらがどのように使用されているかをすでに知っている必要があるため、どのコンテキスト変数が使用されているかを知っていると想定するのは不合理ではありません。

トップレベルのFeedコンポーネントがPureRenderMixinを使用してshouldComponentUpdate実装し、余分な更新を回避する場合、 Feedがその中のどこかでそれを知っているという意味ではありません。はCellであり、ルーターのコンテキストに応じてLinkが含まれています。

フレームワーク（最も人気のあるReactルーティングフレームワークなど）がコンテキストを使用している場合、これはさらに悪化し、あなたはそれに気づかないかもしれません。 どこかで、誰か最適化されたトップレベルのコンポーネントので、アクティブリンク状態を変更し、文字通り、彼らが対応する宣言しなければならなかった_no idea_持っていたしませんアプリケーションがあるcontextTypes _even get_メソッドにnextContext自分でshouldComponentUpdate 。

コンポーネントが_すべての可能な子孫_を認識する方法はありません。 基本的に、コンテキスト依存コンポーネントをPureRenderMixin対応コンポーネント内のどこかに移動すると、壊れますが、非常に微妙です。 したがって、コンテキストを使用する場合、この無関係なコンポーネントの微妙な破損を回避する唯一の方法は、 Reactが言っていることに反する実装しないことです。

@swannodetteのOmなど、Reactの上にあるいくつかのフレームワークは、 PureRenderMixin -ish shouldComponentUpdate _default_を作成しますが、そのようにそれらを切り取るのは奇妙です。 つまり、すべてのコンポーネントでコンテキストを壊すshouldComponentUpdateを意味します。

これがあなたの仕事を妨げていないことには同意しますが、文脈を使用する場合、現在の状況が満足のいくものであることに同意することはできません。 現在、コンテキストを使用してshouldComponentUpdateを実装するのは_難しい_だけではありません。各コンポーネントがそのchildrenが何であるかを常に認識していると仮定しない限り、まったく不可能です。

人気のあるライブラリはすでにコンテキストに大きく依存しています。 サポートされている機能ではないことは理解していますが、私の意見では、 shouldComponentUpdateで機能させるには、少なくとも_可能_である必要があります。または、無効にして、ライブラリで使用しないように強制する必要があります。微妙に壊れています。

これは、導入されたコンテキストで最初から知られています。 特別なケースを見つけるためにそれらを反復できるようにするために、実験的な機能として文書化されていないサポートされていない機能を持つことができる必要があります。 たとえば、コンテキストがなかった場合、所有者ベースではなくコンテナベースに変更する必要があることはわかりませんでした。 微妙な破損は、文書化されていない機能を使用する契約の一部です。

親ツリーのどこかに新しいコンテキストがある場合は、 shouldComponentUpdateバイパスする必要があると思います。 shouldUpdateChildContextまたは、サブツリー全体を調整する必要があるかどうかを決定する何かを使用する可能性があります。

@sebmarkbage

コンテキストが頻繁に変更されることはほとんどないため、これは機能すると思います。
この場合、 shouldComponentUpdateは3番目のパラメーターを必要としませんね。

正解です、それはいつもちょっと役に立たなかったです。

親ツリーのどこかに新しいコンテキストがある場合は、shouldComponentUpdateをバイパスする必要があると思います。

これは非常に理にかなっています。 親のコンテキスト変更は、サブツリーの偽のshouldComponentUpdateをオーバーライドする必要があります。

しかし、それは疑問を投げかけます：コンテキストがいつ変化するかをどうやって知るのですか？ 州と小道具には、 setStateとrender / setPropsます。 renderが呼び出されるたびに、現在のコンテキストのコピーをどこかに保持し、 getChildContextの結果と比較する必要があるようです。

ストア参照を管理する方法としてコンテキストを使用しています。 必要なストアを明示的に定義できるので、これが好きです。
1）コンポーネントをテストする必要があるストアだけでサンプルデータをモックアウトでき、より大きなフレームワークをインスタンス化する必要がなくなります。
2）サーバー側レンダリング用の既知のデータを含む単純な読み取り専用ストアを渡します。これにより、アプリケーションコードの大部分が使用されないため、サーバー側のケースが単純化されます。

だから、例を見て、

私の実装では、ストアデータはゲッターを介してのみアクセスされます。 私の要素はストアデータをキャッシュしません。 私は真実の単一のバージョンが欲しいです。 単純な非同期の例として、私のrender（）は通常次のようなものになります

var peopleStore = this.context.peopleStore;
var person = peopleStore.get(this.props.personId);
return <div>person.fullName</div>;

コンポーネントはリスナーをストアに接続します。 粒度についてはまだ完全には決めていません。 すべてのストアにonChangeイベントがあります。 しかし、私は他に2つのことを決めていません。
1）個々のプロパティ変更のリスナー
2）店舗に店舗を含める必要がある場合

この例では、「people」が「fb users」の場合、それは大規模で複雑な非同期ストアです。 PersonStoreのストア構造を再利用する必要がありますか？ 1つは一般的なコレクション（getFriends、getPersonなど）用ですが、個々の個人のPersonストアタイプの多くの一意のインスタンスです。

したがって、私の例では、コンポーネントはコンテキストパラメータとしてPeopleストアを必要とします。 次に、personIdプロパティを使用して、特定のPersonストアを識別してサブスクライブします。

ここで、いくつかの動的な変更を紹介します。 現在ログインしているユーザーがログアウトし、他の誰かがログインしたとします。実際のアプリケーションでページをリダイレクト/更新する可能性があるという事実を無視すると、この要素はどのように更新されますか？ また、この要素がまだページ上にあり、破壊されただけではないと仮定しましょう。

アプリケーションロジックが最初に既存のPeopleストアを削除/破棄することを期待します。 そのために、私のコンポーネントは更新のリッスンを停止する必要があります。 このために、ReactClassAPIをお勧めします。 例えば、

onContextChange（prev、new）

次に、要素は2つのpeopleStoreインスタンスを比較できます。 公開データを無視して、新しいPeopleStoreがnullであると仮定しましょう。 要素は前のストアからサブスクライブを解除し、render（）をトリガーします。 レンダリングでは、「ユーザー不明」タイプのメッセージが表示されます。

ユーザーが別のユーザーとしてログインすると、新しいストアが作成され、要素が再接続され、render（）が新しいデータを処理します。

舞台裏では、「this.render（）」を同期できませんでした。 私のデザイン/例のいずれかがまったく意味をなさないようにするには、render（）呼び出しをフレームワークによって収集し、一緒にバッチ処理する必要があります。

小道具とは異なり、ストアを聞くことは、レンダリングを管理するというReactの中核的な役割の範囲外です。 そのため、shouldComponentUpdate（）にコンテキストの変更を含めるべきではないと思います。 そして、コンテキスト値（新しいストアオブジェクト）の変更を含む私の例にもかかわらず、ストアは高レベルの性質で不変になるとは思いません。 典型的なフラックスアプリケーションの設計は、サブスクライバーモデル、非同期のコールバックなどで動作すると思います。ベースストアオブジェクトは通常、アプリケーションの存続期間中存続します。

これにはかなりの関心があります。 （上記の参照を参照してください。）

はい@gaearon 。

ローカリゼーションデータをコンテキストで渡し、ユーザーが実行時に言語を変更できるようにし、すべてのコンポーネントが更新された翻訳、通貨、日付形式で再レンダリングできるようにしたい...私が理解している限り、これは今のところ難しい。

も参照してください
https://github.com/yahoo/react-intl/issues/58
https://github.com/facebook/react/issues/3038

@slorberカスタムPureRenderMixinも採用しましたが、 @ gaearonが言うように（または3番目のパラメーターが消える場合）、中央でより厳密なshouldComponentUpdateすると明らかに壊れることがあります。 ただし、いつでも小道具に頼ることができます。 この問題がどのように進化するか見てみましょう:)

@gpblはそれをチェックします：
https://github.com/facebook/react/issues/3038#issuecomment -76449195

コンテキストが変更された場合にアプリ全体を上から再レンダリングしたい場合は、同じイベントループティックでノードをアンマウントおよび再マウントでき、ちらつき効果は発生しないようです（常に）。 これは、ユーザーの言語の変更に対処するための完璧な回避策です。

@slorber unmountComponentAtNodeを呼び出すと、すべてのローカル状態が失われるため、ユーザーエクスペリエンスが低下します。

コンテキストを公式の機能として宣言する時が来たと思います。 ルーターとReactIntl​​がコンテキストを使用するため、コンテキストを使用しないことはほとんどの人にとってオプションではありません。

@cody et al、明確にするために：コンテキストはまだ変更される可能性があります。 まだ実験中ですが、最終的なAPIを決定するまでは避けることをお勧めします。 使用はご自身の責任で行ってください。 それは役に立ちますか：おそらく。 準備はできていますか：いいえ。

@codyこれは、ローカル状態をhttps：/ /github.com/stample/atom-react

親ツリーのどこかに新しいコンテキストがある場合は、shouldComponentUpdateをバイパスする必要があると思います。 潜在的に、shouldUpdateChildContextまたはサブツリー全体を調整する必要があるかどうかを決定する何かを使用します。

はい、 shouldUpdateChildContextはそれを素晴らしく対称的にします。

これが0.14になる可能性はありますか？

優れたAPIを設計して実装する場合。 :)

実際に変更されたコンテキストキーをリッスンしている子だけが実際に更新されていることを確認する方法を含める必要があります。 すべての代わりに。

私たちのフルタイムのコアチームだけがそれを行う時間があるとは考えられません。 :(

2015年4月9日には、13:32で、ダン・アブラモフ監督の[email protected]は書きました：

これが0.14になる可能性はありますか？

—
このメールに直接返信するか、GitHubで表示してください。

確かに、見てみます！

申し訳ありませんが、私はまだこれに取り組み始める時間が見つかりません。 保留中のReactDnD 1.0リリースの後、私はconfの準備で忙しいので、すぐにこれに取り組むことができる可能性はほとんどありません。 :-(

@gaearonこれをすぐに見る予定はありますか？ これはコンテキストを完全に使用可能にする最後のピースの1つであるように思われるので、私はこれに飛び込むことに興味があります。 （私が見逃している何か他のものかもしれませんか？）

私が疑問に思っていたのは、次の記述が正しいかどうかです。

コンポーネントの子コンテキストは、_常に_その状態の小道具とコンテキストの縮小である必要があります

これにより、既知のライフサイクル内でデータを確実に流すことができます。 これは、「コンポーネントのレンダリングは常に状態と小道具の縮小である」というステートメントに似ています。

これは私が現在それを想像している方法です-私が完全にコースから外れているかどうかを確認するのは良いことです！：

shouldUpdateChildContextは、サブツリーを新しいコンテキストで更新する必要があるかどうかを決定します。 ライフサイクルのこの部分は、コンポーネントの状態の小道具またはコンテキストの変更によってトリガーされます。

shouldComponentUpdateは3つのパラメーターが残っているため、上記のサブツリーのコンポーネントは、実際に何かを更新する必要があるかどうかを判断できます（注：ここでfalseを返すことは、サブツリーをさらに流れるコンテキストには影響しません）

ここで私が疑問に思っているもう1つのことは、別の新しいライフサイクルメソッドcomponentWillReceiveContextがあるべきかどうかです。 - componentWillReceivePropsと同じ時間に呼び出されますが、コンテキストデータフロー内です。 ここでは、これらの両方のメソッドを「同時に」呼び出すことができます。

@Chrisui

ジャンプしてください！ 私は今、他のもので忙しすぎます。

これにより、既知のライフサイクル内でデータを確実に流すことができます。

また、0.14で実装される場合とされない場合があるobserveフックがあることにも注意してください。 つまり、 data / observed /と呼ばれるものが何であれ派生する場合としない場合があります。 しかし、それはおそらく今のところあなたの仕事とは無関係です。

私のフォークでこれの非常に最初のドラフトを手に入れました、そしてあなたはそれがexamples/context/index.htmlで走っているのを見ることができます

単純な「コンテキストの親」/「コンテキストの子」の関係を設定しました。 「コンテキストの親」は、子コンテキストを変更する可能性のある（つまり、 childContextTypes実装する）コンポーネントであり、「コンテキストの子」は、コンテキストに依存する、または子コンテキストを変更する可能性のある（つまり、 contextTypes実装する）コンポーネントです。 childContextTypes ）。 この関係は、コンポーネントが現在マウントされているときに設定されます。

コンポーネントの更新ライフサイクルが機能するようになると、次の2つのケースが発生します。

1. コンポーネントが更新を行わないと言った場合（つまり、 shouldComponentUpdate() === false ）、子コンテキストをshouldUpdateChildContext更新する必要があるかどうかを確認します。 これがtrue （デフォルト）の場合、このコンポーネントに直接の「コンテキストの子」がある場合、子コンポーネントを更新ライフサイクルに移行します。 これは、コンテキストツリーの最後に到達するか、 shouldUpdateChildContext() === false遭遇するまで続きます。
2. コンポーネントが更新を行うと言った場合、何も違いはありません。 この場合、コンテキストデータのサイドチャネリングはなく、コンポーネントがケース＃1に再びヒットするまで、通常のフローを続行します。

間違いなく私はいくつかの重要なものを見逃しているので、誰かが簡単に見てくれるならそれは素晴らしいことです。 コンテキストのアーキテクチャに関するコメントと、Reactコードベースに適合するコードの実際の記述を歓迎します。 :)

簡単な疑似例として、次のことを考慮してください。

<Root num={1}>  // Gives context {num: this.props.num}
  <Mid>         // Ignores any context and shouldComponentUpdate() === false
    <Child>     // Requires context {num: propTypes.number}

最初のレンダリング（マウント）では、すべてが期待どおりです。 （実装の詳細：親子関係はRootとChild間に作成されます）

Rootを更新して、 num小道具の値を2

<Root num={2} />

MidはshouldComponentUpdate()メソッドも実装します。これはrender()メソッドがcontext.numを気にせず、他に何も変更されていないため、 falseを返します-では、なぜ更新する必要があるのでしょうか。

これは、古い場合、ツリーの下の更新から抜け出したため、 Childコンポーネントが新しいコンテキストを認識しない場所です。

これらの変更により、 MidでshouldUpdateChildContext()メソッドをチェックします。これにより、（例ではデフォルトのアクションが実行されるように）単純な等価性チェックを実行して、コンテキスト値にかわった。 注： shouldUpdateChildContext()の署名は、現在shouldComponentUpdate()と同じです。

shouldUpdateChildContext()がtrue （デフォルト）の場合、関係が以前に設定されていれば、最も近い「コンテキストの子」（この例ではChildのみ）を更新します。 。 これにより、そのコンポーネントが更新ライフサイクルに組み込まれます（以前に見た説明とは異なり、これは3番目のパラメーターとして_new_コンテキストを使用して通常どおりshouldComponentUpdate()を呼び出します。これにより、コンポーネントは必要なときにきめ細かく制御できます。更新）。

うまくいけば、それはプロセスを十分に説明しています！

@Chrisuiかっこいい、これでいくつかの進歩を見るのは素晴らしい！ また、サニティチェックの基本機能に多数の単体テストを追加する必要があります。 最低でも：

• 親shouldComponentUpdate()がfalseを返した場合でも、子の更新を確認します。
• 親shouldUpdateChildContext()がfalseを返した場合でも、子の更新を確認します。
• コンポーネントshouldUpdateChildContext()がfalseを返した場合、子が更新されないことを確認します。

さらに、これらがサポートされている機能である場合は、次のことを確認する必要があります。

• 祖父母が提供されたコンテキストを変更した場合にshouldUpdateChildContext()が呼び出されないことを確認しますが、直接の親はそのコンテキストをオーバーライドし、変更しません。
• コンポーネントが変更されたコンテキスト変数から読み取らない場合、 shouldUpdateChildContext()が呼び出されないことを確認します。
• 小道具が変更され、コンテキスト変数が変更された場合、2回更新/レンダリングしないことを確認します。

cc：APIの設計/アイデアに関するフィードバックについては@sebmarkbage 。

@Chrisuiこれまでのところ素晴らしいですね。この作業をしていただきありがとうございます。

@jimfbは間違いなくいくつかのユニットテストを開始します-何か遊んで、その前にそれがどのように機能するかを確認したかっただけです！

2番目のケースに関しては、これらは私が避けた領域であり、より単純な設計を支持しています。 たとえば、どの特定のコンテキストキーが変更されているかを確認し、これらのみを更新することをお勧めします。 これにより、現在、親子関係が複雑になりすぎて、他のデータがReactをどのように流れるかとの対称性が低くなる可能性があると思います。 たとえば（私は非常に素朴でこれを見落としているかもしれません）、変更する小道具を内部で比較せず、2つの別々のデータソース（つまり、現在の小道具と次の小道具）が更新を引き起こすか、単に更新するかをユーザーが明示的に定義することを任せます無視されます。

人々がそれが実行されるべきであると強く感じているならば、この特定の詳細についてもう少し議論を見るのは良いことです。

これの簡単な実装については、これを進めたい場合は、ツリーを更新してcontextTypesと比較し、有効なものを見つけるときに、コンポーネントのchildContextTypesをマージし続けると思います。ターゲットを更新します。 あるいは、マウント時に少し魔法をかけて、コンテキストの子キーが一致する子と最も近い親の間にのみ親子関係を作成できるかもしれません。 後者の場合、不可能ではないにしても、後で更新順序を管理するのが難しくなると思います。

簡単にハックして、これをモックアウトしてみます！

実際、機能の特定のコンテキストキー比較部分に関する私の後者の提案に関しては、すでに使用されているマウント順序バッチロジックでソートされたものと同じものに従うだけでは、更新順序を維持するのはそれほど難しいことではないかもしれません！

@Chrisui @sebmarkbageしたがって、私の懸念は（明らかなことを忘れたり見逃したりしない限り）、コンテキストプロバイダーが再レンダリングするたびに、提供されたコンテキスト変数に依存するすべての（場合によっては数百の）子コンポーネントが発生することです。コンテキスト変数が変更されていない場合でも、再レンダリングします。 私の直感では、新しい値が利用可能であるという何らかの兆候があった場合にのみ、コンテキストの再伝播をトリガーする必要があります（新しい値が古い値と3倍にならない、またはフラグ/通知など）。

実際、この実装はサブスクリプションシステムのように見え始めています。 contextは事実上スコープグローバルであるため、おそらく正しい解決策は、コンポーネントにコンテキスト変数を横方向にサブスクライブすることを要求することです。これにより、グローバルへの他のすべてのサブスクリプションに使用するのと同じメカニズムをコンテキストに利用できます。データ。 https://github.com/facebook/react/issues/3398、https：//github.com/facebook/react/issues/3858 、およびhttps://github.com/facebook/react/pull/3920を参照してください。関連情報。

@sebmarkbageを突く。 私の最近の考えは、APIの表面積を回避するために、この問題を解決するために横向きのデータ読み込みソリューションを使用することに賛成だと思います。 あなたの考えを聞いてみたいです。

@jimfb何百ものコンポーネントを再レンダリングすることについては正しいですが、状態の変更をトリガーし、一括更新が発生しないようにshouldComponentUpdateを実装する必要がある場合、今と何が違うかはわかりません。

そのコンテキストはサイドデータの特定のストリームのように見えるだけですが、私は同意します。 それらの提案が文脈のカスケード効果をもたらすことができるならば、私は今のように文脈で実際に発展する理由がないと思います。 他の人の考えを見てみましょう！

興味深いことに、ドラフトに機能を追加して、コンポーネント間に一致するコンテキスト/子コンテキストキーがある場合にのみ親子関係を作成し（冗長なツリートラバーサルを防止）、コンテキストが実際に変更されていない場合に更新を防止するだけで、いつものようにPureRenderMixin。

@Chrisui違いは、子コンポーネント内の単一のshouldComponentUpdateがツリーの巨大な枝を切り取ることができるのに対し、コンテキストでは、再レンダリングされるすべての場所を見つけて修正するのがはるかに難しいことだと思います。 ベイルアウトしても、コンテキスト変数に依存する子は再レンダリングされます。

ええ、私は他の人が横向きのデータ読み込みソリューションを使用することについてどう思うか知りたいです。

コンテキストは、横方向のデータ読み込みとほぼ直交していると思います

理想的には、横向きのデータストアのハンドルをグローバルではないコンポーネントに渡す方法が必要です。これが主にコンテキストの使用方法です。

ただし、このようにDIのコンテキストを使用すると、アプリケーションの過程でコンテキストが変更される可能性が低くなります。

2015年5月26日には、午後09時10分で、ジムの[email protected]は書きました：

@Chrisui違いは、子コンポーネント内の単一のshouldComponentUpdateがツリーの巨大な枝を切り取ることができるのに対し、コンテキストでは、再レンダリングされるすべての場所を見つけて修正するのがはるかに難しいことだと思います。 ベイルアウトしても、コンテキスト変数に依存する子は再レンダリングされます。

ええ、私は他の人が横向きのデータ読み込みソリューションを使用することについてどう思うか知りたいです。

—
このメールに直接返信するか、GitHubで表示してください。

コンテキストの使用に関する現在のアドバイス（「しない」を超えて）はすべて適用されるようです。頻繁に変更されるものは、かなり高い再レンダリングコストが発生します。 提案された非常に的を絞った方法でそのコストを増やしても、必ずしも人々がそれを使用することについて考える方法を変えるわけではありません。 さらに、木の枝を切り落としたい場合でも、かなり簡単です。

class Mid extends Component {
  shouldComponentUpdate() { return false; }
  shouldUpdateChildContext() { return false; }
  ...
}

現状のコンテキストが比較的単純であることに満足しています+ shouldUpdateChildContext。 基盤となるメカニズムを他のグローバルサブスクリプションと一致するように変更しても、使いやすさが大幅に低下することはないでしょう。

@jimfb
@eplawlessが指摘しているように、shouldUpdateChildContextを使用して、更新されるツリーの巨大なブランチをブロックできます。

コンテキストAPI（提案された変更を含む）は、今すぐ実装し、後でサポートされる可能性のあるサイドデータロード反応を使用するように内部を変更できるほど単純だと思います。

別の提案：shouldUpdateChildContext（）をデフォルトでfalseに設定して、この新しい動作をデフォルトで防止し、オプトインにすることもできます。

反復とテストのために何かを公開するために（同じ方法で、コンテキスト機能は常に-したがって文書化されていません）、0.14のこのAPI提案を追求する必要がありますか？ （ゲートキーパーから話を聞くのは良いことです！）

私はあなたのためにPRを開きました： https ：

PRはマスターに比べて簡単に確認でき、問題よりも優先されるため、PRに関するフィードバックをすばやく受け取る可能性が高くなります。

私はもともとshouldUpdateChildContextについて間違っていたと思います。 本当に必要ですか？ スラッシュについて申し訳ありません。

shouldComponentUpdateは、何かが変わったかどうかを判断するのは子供の責任となる戦略のようです。 たとえば、出力を決定するために提供したすべてのデータを使用するとは限りません。 親として、あなたはそれを知りません。 おそらくそれで十分です。

また、親子接続を小道具などの固定されたプロパティのセットに制限したい場合もあると思います。 つまり、特定の子がコンテキストの一部のみを使用する場合、1つのソースから複数の異なるコンテキストを提供することはできません。 1：1のマッピングが存在する可能性があります。 さらに、私は常にコンテキストバブルを消費する子供に直接伝えることを躊躇していましたが、正当なユースケースは一般に、すべての人にブロードキャストするだけでなく、2つのコンポーネント間の「ワームホール」です（これはアンチパターンです）。

もう少し考えて、PRについて詳しくコメントします...

@sebmarkbage shouldUpdateChildContextどちらの方向にも行くことができます。 私の好みは常にAPIの表面を最小化することです。 いつでも最初のAPIから除外することができます（コンテキストはジャンプして、コンテキスト変数を読み取るコンポーネントで再レンダリングを開始するだけです）。 追加のエスケープハッチが必要な場合は、後で追加します。

@mjacksonが指摘したように、より大きな問題は、コンテキスト変数がいつ変更されたかがわからないことだと思います。 i18n ContextProviderが再レンダリングされるたびに、すべてのfbt / i18nテキストノードを本当に再レンダリングしたいですか？ 「心配しないでください。何も変わっていません。ページ上のすべてのテキスト要素をわざわざ再レンダリングしないでください」という言い方はまだ提供していません。

私はあなたの最後の段落について少し混乱しています。 詳細を教えていただけますか？ 以下がコンテキストのアンチパターンであることを示唆していないと思います。i18nコンポーネントは、ユーザーの優先言語/タイムゾーン/フォーマットなど、すべてのi18n対応の子コンポーネントに「ブロードキャスト」します。

PRについてコメントしましたが、ここで再現する必要があります。

@sebmarkbage @Chrisui @jimfb

Re： shouldUpdateChildContext 、これは便利な追加だと思います。 デフォルトでは、 shouldComponentUpdateはtrueを返します。これにより、何かが変更されたかどうかを判断するのは子の責任になります。 shouldComponentUpdate実装するということは、親がよく知っている場合にその責任を取り除くことを意味します。 同じことがshouldUpdateChildContextにも当てはまり、最適化として子から責任を取り除くためだけに存在します。

Re：サブツリー全体にブロードキャストするのではなく、2つの有効なパターンがあると思います。 ＃2517で提案したように、ワームホールは完全に理にかなっています。 このパターンを使用して、さまざまなサブシステム（フォーカスや音声など）内のアイテムをグループ化します。 さらに、コンテキストを使用してi18n情報をアプリケーションのセクション全体（おそらく全体）に渡し、それを使用するものすべてを強制的に再レン​​ダリングしたいと思います。 この種のブロードキャストパターンは、ワームホールパターンと比較しておそらく比較的まれですが、それでも有効であると思います。

現在、同じソースのフォーカスグループとボイスグループにミックスインを使用していることがあります。 制限の必要性は理解していますが、1：1マッピングを強制しないための有効なユースケースがあると思います。

実際、「ワームホール」パターンはアンチパターンだと思っていましたが、放送は予想通りのパターンでした。 コンテキストは、変数のコンシューマーが多数ある場合にのみ興味深いものです（つまり、propを明示的に渡すと、実質的にすべてのコンポーネントに追加されるため、定型文が多くなります）。それ以外の場合は、明示的に渡す方がよいでしょう。小道具。 しかし、 @ sebmarkbageは反対のことを言っているようです（そして彼は通常このことについて正しいです）ので、今私は混乱していて、彼から説明を得たいと思います。

@sebmarkbage @eplawless有効だと思うワームホールパターンの例は何ですか？ 親は何を提供しているのか、それは子供によってどのように使用されているのか、なぜそれは子供の小道具になれないのかなど。

<Table>
  <Cell />
  <Cell />
  <FancyCell />
</Table>

class FancyCell {
  render() {
    return <SomeWhatFancyCell>Some content</SomeWhatFancyCell>;
  }
}

class SomeWhatFancyCell {
  render() {
    return <Cell>{this.props.children}</Cell>;
  }
}

borderWidthを取得し、 borderLeft/Top/Right/Bottom形式でテーブルのすべてのセルに渡します。

1つの巧妙な方法は、 borderWidthを<Table />に渡し、それを分割してコンテキストを通過させることです。

これは、セルにレンダリングされる可能性のあるものが、隠しチャネルを介してテーブルなどの概念的な親と通信する方法を提供します。 これはすでにDOM要素が相互に行うことであり、Reactでレイアウトを行うために必要になる可能性があります。

「コンテキスト」の概念に焦点を合わせすぎないでください。 現在の概念は理想的ではありません。 たぶん理想は、2つの異なる概念や他のチャネルのようなものですか？

もっともらしい代替API：

class Table {
  render() {
    var w = this.props.borderWidth;
    var borderStyle = { left: w, right: w, top: w, bottom: w };
    return <context key={someSymbol} value={borderStyle}>{this.props.children}</context>
  }
}
class Cell {
  static contextKey = someSymbol;
  render() {
    var borderStyle = this.context;
    ...
  }
}

ここで唾を吐くだけです。

唾を吐き続ける...

別の構文を使用できます...

<Table borderStyleChannelKey="myKey">
  <Cell borderStyle={myKey} />
  <Cell borderStyle={myKey} />
  <FancyCell borderStyle={myKey} />
</Table>

これで、通信チャネルを明示的にし、名前の競合などの可能性をすべて回避しました。（https://github.com/reactjs/react-future/pull/28）

シンボルにも名前の競合はありませんが、コストをかけて通信チャネルを作成しました。 複数のレベルの間接化を通過しました。 背景色など、別のチャネルを変更または追加する必要がある場合は、文書化された契約（テーブル内のセル）が同じであっても、すべてを更新する必要があります。

ところで、Reactの本質はすでに隠されたコミュニケーションチャネルです：状態。 各子を明示的に通過するわけではありません。

'borderStyle'ではなく 'styleinfo'または 'celldata'と呼び、オブジェクトにします。 次に、フィールド/情報を追加するために、APIコントラクトをTableとCell間で変更する必要はありません。

私のバリアントとあなたのバリアントの唯一の違いは、（私のバリアントでは）子が実際に値を「読み取る」唯一の方法は、親から小道具として明示的に渡されることです。 機能的には、最新の提案はhttps://github.com/reactjs/react-future/pull/28からの私の提案と文字通り同じです

明確にするために、私はあなたの最新の提案が本当に好きです...だから私は文句を言うつもりはありません...しかしそれは微妙に異なる問題を解決します。 それはあなたが3月に私に言ったことです、そして私は最終的にあなたが正しいという結論に達しました（例えば、放送の問題）。 ブロードキャストの問題を解決しなくても問題がない場合（コンテキストが何らかの価値を提供すると確信した方法です）、ぜひ、このようなことをしましょう！

キー名が常に所有者によって決定されない限り、任意のシンボルには名前の競合があります。その場合、所有者はとにかくキー名を子に伝える必要があるため、所有者に表示することもできます（そうでない場合はどうすればよいですか？子供はどこを見ればいいのか知っていますか？） 所有者を強制的に関与させることにより、ハードコードされたキーの代わりにシンボルを使用するようにコンポーネントに自然に奨励します。

共通モジュールなどのチャネルを介して調整する必要があるグローバルシンボル（大文字のS）を意味します。 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol

私が新しく提案したAPIの良いところは、キーが制御フローやプログラム分析と混同される「オブジェクトプロパティ」キーではないことです。 私の提案では、状態を強化するキーと同じように、ファーストクラスの動的な値があります。

ああ、ic、 @ sebmarkbageは再び派手な新しいjavascriptを引き出しています:)。 私は知っているべきだった。 彼は今日TC39会議に出席しています。

はい、その通りです。 これは、名前の競合を回避するのに非常に効果的であり、ブロードキャストの問題を解決します。 あなたは私を売りました。 私はそれが好きです！

今日はオフィスにいたらいいのに！ 直接会うのはとても魅力的な会話だったと思います！

個人的には、彼がいなかったことを嬉しく思います。これにより、私たち全員もループに陥ります;-)。

私はSymbolのものが本当に好きです。 潜在的にエイリアンのツリー全体での文字列キーへのコンテキストの過度の依存は、常にいくつかの悪い雰囲気を持っていました。

たとえば、2つのライブラリが3番目のライブラリの親子ワームホールに依存していて、たまたまその独立したコピーを使用している場合、それらのコピーが衝突したり、相互に表示されたりすることはありません。 確かに想像するのは奇妙なシナリオですが、より一貫しているようです。

公平を期すために、シンボルは現在のオブジェクトで動作することがすでに可能です。 Symbolsを使用している場合でも、おそらくnpmトップレベルモジュール名などの潜在的にグローバルな名前空間を介したモジュールが必要になります（ただし、相対的なものであることが望ましいです）。

現在のAPIでは、単純な文字列名を使用するのが非常に自然になっているだけです。 また、ランタイムセマンティクスを特定のプロパティ識別子と統合し、クロージャーコンパイラの詳細モードなどを推論するのをより困難にします。 また、VMの最適化をねじ込みます。

@sebmarkbage UUID（別名Symbols）を使用することもできますが、新しい提案では実行時にキーを決定できます。つまり、親が小道具を介してキーに影響を与える可能性があります（わかりません）。 そうは言っても、jsxスコープ内で値を使用できるようにしないと、それがどれほど役立つかはわかりません。それについてさらに考える必要がありますが、（おそらく）いくつかのクールな柔軟性が追加されます。

「ワームホール」のアナロジーについてはよくわかりません。放送シナリオとi18nの例は、提案されたPRが解決しようとしている問題に遭遇したものです。

また、 https： //github.com/facebook/react/issues/2517#issuecomment -106597895がどのように役立つかについても完全にはわかりません。これは、意味的にはgetChildContextおよびcontextTypesと同等のようです。

shouldUpdateChildContext PRについて私が気に入っているのは、コンテキストの変更を伝播するために、任意の深さですべての子を列挙する必要がないことです。

AIUI元々の問題は、 shouldComponentUpdateがcontext渡されても、コンテキストの性質上、「ブロードキャスト」と「レシーバ」の間のコンポーネントがコンテキストを知らなかったためにfalseを返す可能性があることでした。それを通過していました。

この問題を回避する2つの方法は、ツリー内のコンポーネントの上のコンテキストからどのコンポーネントが読み取られているかを追跡するか、ツリーの下にコンテキストの変更を伝播するための追加のメカニズムを用意することです。

フォームコンポーネントで親ベースのコンテキストを少し使用した後、この件について2セントを提供したいと思います。 フォーム（「ストア」インスタンスとして機能）がコンテキストを介してlisten()メソッドを渡す、並列のフラックスのようなメカニズムの作成につながる、コンテキストに応じた親と子の間の適切な更新メカニズムの欠如。 Fieldコンポーネントがマウント時に登録されます。 フォームは、下に伝播する変更をトリガーします。 それはすべて非常に流動的で問題なく動作しますが、Reactコンポーネントの構成可能性モデルを

HoCでコンポーネントをラップする一般的な戦略は、（小道具のように）更新チャネルの中央ではなく、更新チャネルの_外側_に新しいラップするコンポーネントを配置するため、ここでは機能しません。 プロペラシステムの大きな利点は、流れがトップダウンであり、間に挟まれたものによって遮断される可能性があることです。 更新システムのようなフラックスを使用する場合、ラッピングコンポーネントもフォームをリッスンする必要がありますが、ラッピングコンポーネントと元の（ラピー）コンポーネントの両方がフォームをリッスンするという問題が発生します。 HoCが「引き継ぎ」、データを元のコンポーネントに渡します。

コンテキストは、特定のコンテキストとビジネスを持たないコンポーネントからある程度「保護」する必要があることは明らかですが、コンポーネントが必要な場合は、データストリームに簡単にジャンプできる必要があります。 フォームコンポーネントの特定のケースでは、 Formほとんどの子は、渡されるコンテキストから分離され、 Fieldコンポーネントのみがそれを受け取る必要があります。 ただし、消費者がFieldをHoCでラップしたい場合（デフォルトを設定したり、動作を調整したりするため）、それを行う簡単な方法があるはずです。

つまり、コンテキストAPIは、中間（承認済み）コンポーネントがそのコンテキストのレデューサーとして機能できるようにする必要があります。これは、コンポーネントが小道具を子に渡すときに、小道具をリデュース/マップできるのと同じ方法です。 違いは、小道具は「パブリック」スチームであるのに対し、コンテキストはプライベート、オプトイン、ストリームであるということです

私はreact-side-contextでサブスクリプションベースのコンテキストのアイデアを少し試しました。

内部的には、コンテキストブロードキャスターは{ subscribe(key, cb), getValue(key) }インターフェイスを子供に公開しbroadcast({ [key]: newValue, ...otherKeys })介してコンテキストキーへの変更を発行します。

@broadcasts([...keys])および@observes([...keys])クラスデコレータはこのAPIをReactコンポーネントに結び付け、 contextを使用してコンポーネントツリーを介してコンテキストツリーを伝播し、 setStateを使用して更新をキューに入れます。コンテキスト変更への応答。

ボイラープレートを少し使用すると、現在のshouldUpdateChildContextプロポーザルと同等のAPIをセットアップできます。

名前の衝突を避けるために、コンテキストツリーは一意であるため、コンテキスト内のキーをブロードキャストまたは監視するには、コンテキストへの参照が必要です。

動的な値を渡すためにコンテキストを使用したことはなく、参照を変更しないだけです。 ここにそのおもちゃの例がいくつかありますが、本番アプリで動的な値を渡すために使用した人はいますか？ 私はしばしば、実際のユースケースがより啓発的であると感じます。

たとえば、I18nの場合、キーと値のペアを直接渡す人はいますか？ それとも、コンポーネントが値を取得して監視できるオブジェクトへの不変の参照を渡すだけですか？

ある種のバブルアップイベントディスパッチをコンテキストで実装することに一度興味がありましたが、正確には何を意味するのか忘れましたが、親が子供からのイベントを傍受してコンテキストを追加できるようにして、子供が持っていないようにすることでしたそれらがグローバルな文脈のどこに適合するかについての知識を持っていること。

ここに2セントを追加するには、 StaticContainer壊さないような方法でここに修正を実装した方がよいと思います。

StaticContainer引き続き機能し、 propsとcontext両方で、親からのすべての更新をブロックするのが最も理にかなっていると思います。

IMOがこれを処理する最善の方法は、コンテキストが関係する場合は常にshouldComponentUpdate完全に無視するのではなく、 shouldComponentUpdateが子によって使用されるコンテキストへの変更を潜在的に検出できるようにすることです。

@ jedwards1211私のユースケースは、I18nProviderコンポーネント内の翻訳メッセージをフェッチしてから、（gettextメソッドを使用して）Jedインスタンスを渡すことです。

メッセージが受信される前に、gettextメソッドは空の文字列を返し、UIを楽観的にレンダリングできるようにします。 I18nProviderがメッセージを受信すると、翻訳可能な文字列を含む部分のみがDOMで更新され、すべてが再レンダリングされることを期待します。

文字列を抽出できるように、ビューコンポーネントで実際にgettext()呼び出しを行う必要があります（この場合はxgettextを使用）。

Reactifluxで使ってこれを少し蹴ります。 shouldComponentUpdate 「スーパーfalse 」の概念があれば便利です。

一般的に、それはそのコンテキストの更新は、過去に伝播すべき思えますがshouldComponentUpdate返すfalse （あるいは少なくとも、これはほとんどのユースケースをシンプルになるだろうが）、私はまた、例えばとの特別なケースがあると思います<StaticContainer>親を必要とする場合と同様に、外への遷移のサブツリー凍結などの目的のために、その子孫にすべての更新をブロックすることができるようにする<StaticContainer> 。

たとえば、 https：//github.com/rackt/react-router/pull/2454を検討して

shouldComponentUpdate falseを返す動作は、コンテキストの更新をブロックするべきではないことに同意しますが、 <StaticContainer>を維持するには、ある種のSUPER_FALSEセンチネルが必要です。 <StaticContainer>現状のままで動作します。

@taion

トランジションアウトルートコンポーネントのアクティブ状態をリンクする更新を簡単に防ぐことはできません。

私は混乱しています、望ましいユースケースは何ですか？ 一般に、 shouldComponentUpdateは、UIの変更につながる更新をブロックするために使用しないでください。 これは、不必要な調整作業を回避できるようにするための最適化メカニズムとして純粋に意図されたヒントです。

@jimfbただし、Relayでそれを正確に行うために、つまり、新しいデータのロード中に更新をブロックするために、すでに<StaticContainer>を使用しています。

ユーザーがリンクをクリックして、新しいルートがロード/スワップアウトされるようにトリガーするというユースケースがあると思います。 これが行われている間、アイデアは古いルート上のすべての相互作用/更新をブロックすることです。これは、新しいルートのロードが完了するとスワップアウトされます。

これは現在、新しいルーターの状態が読み込まれている間、常にfalseでshouldComponentUpdate falseを返すことで実現されているようです。

@taionリレーの人たちと話をして、そこで何が起こっているのかを理解します。 それについて明確な答えが得られるまで、その手法を独自のコードに適用することはお勧めしません。

cc @sebmarkbage

@jimfb

おそらくあなたがそれをするのは簡単です（：

新しいデータのロードをトリガーするとき、デフォルトでは、新しいデータの準備ができるまで古いデータをレンダリングし続けたいという考えが私の理解です。

返すことによって、 falseからshouldComponentUpdate 、リレールートコンテナ/レンダラーは、直前にあったものは何でもレンダリングを維持する簡単な方法があります。

インタラクション自体をブロックしているのではなく、一時的な状態でアップストリームデータをフェッチする更新をブロックしています。

@taionええ、私はそれが何をしているのか理解していますが、それが私たちがサポートしたいパターンであることに懐疑的です。 私はセバスチャンとリレーの人々と話をしますが、答えは「ええ、それはハックでした、それをしないでください」になるだろうと思います。

通常、その動作を実現する方法は、古い値を状態にし（新しい値が表示/到着するまで）、古い値を状態からレンダリングすることです。

@jimfb

このパターンは、不変のデータなどでのみ可能です。 （クローン化できない）ステートフルオブジェクトがある場合、このパターンに従うことができない場合があります。 リレーにはこの問題がないのではないかと思いますが、ReactRouterの現在の実装にはこの問題があります。

一般的な非同期データライブラリの場合、これはかなり一般的で便利なパターンのようです。

@taionあなたが検討しているアプローチは、特に可変データがある場合、私にはさらにエラーが発生しやすいようです。 データが変更可能である場合、子がランダムに更新されることがある競合状態になり（イベントハンドラー、コンテキストの変更、強制更新などのため）、コードが非常に予測不能になります。 何人かの人々と同期して、これを理解させてください。 そのディスカッションの結果を投稿していない場合は、数日以内にpingを送信してください。

StaticContainerのユースケースは、そのパターンで対処する必要があるものではないと思います。 別の機能の副作用から効果を得ようとするのは不安定な方法のように聞こえます。 実際に要求されているものを明示的にサポートする方がはるかに良いでしょう。

この場合、一部の低レベルのReactライブラリは、アンマウントをインターセプトし、Reactツリーのコンポーネントから生じるDOMを切り離し、接続を切断し、アンマウントのライフサイクルを終了するまで延期する方法を望んでいるようです。

これは、明示的なインターフェイスでサポートする必要がある低レベルの機能だと思います。 リンクを切断するコンポーネントのアンマウントまたはアンマウントをインターセプトする何らかの方法により、呼び出し元はしばらくの間、基になるコンテキストを混乱させ、呼び出されたときにアンマウントのライブサイクルフローを再開する関数を返します。

Reactから切断されたDOMノードを特定の場所に保持する必要があることをReactに明示的に通知するために、このAPIが使用できる特別な形式のフラグメントまたはプレースホルダーが必要になる場合があります。

それは、超特別な内部ノードなしではありえません。 しかし、再び、noscriptとしてレンダリングされ（nullリターンの典型的なreactハックなど）、そのnextSiblingがその場所に保持されるべきDOMノードであることを宣言する特別な低レベルタイプのreactノードのアイデアしかし、そうでなければReactによって無視されるのは、他のさまざまなバグの修正に役立つ可能性のある非常に興味深いノードタイプです。

@taionわかりました、リレーチームの1人と、他の2人のReactの人と話をしました。 これは良いパターンではないことに私たちは皆同意しています。 しないでください。 更新を待っている間に状態を使用してデータを保存することが公式の解決策です。そのユースケースに適したAPI /推奨事項が見つかるまでは。

私はそれに対処することができます-とにかくこのパターンの使用から離れることができるように、Reactルーター側でいくつかのことをクリーンアップしたと思います。

ありがとう！

また、もう1つ質問を追加したいと思います。 私はこのようなものを持っています。

var BlogPosts = React.createClass({
  getChildContext: function() {
    return {
      currentBlogPost: this.props.currentBlogPost,
      currentUser: this.props.currentUser
    };
  },

  childContextTypes: {
    currentBlogPost: React.PropTypes.object,
    currentUser: React.PropTypes.object
  },

  render: function() {
    return <BlogPosts blogPosts={this.props.blogPosts}/>
  }
});

function select(state) {
  const { blogPosts, currentUser, currentBlogId } = state;
  console.log( state.blogs[currentBlogId]); 
  // first time the above is undefined and then blogs get populated and I have the object;
  return { blogPosts, currentUser, currentBlogPost: state.blogs[currentBlogId] };
};

export default connect(select)(BlogPosts);

現在、BlogPostsコンポーネントには、blogPosts [index] .typeがテキスト、画像、または音声のいずれであるかに応じて、BlogPostText、BlogPostImage、PodCastがあります。

私がこのように所有者をチェックしたコンポーネントの1つで、

var BlogPostText = React.createClass({
  canDeleteMemory: function(post, blog, user) {
    return user && (blog.userId == user.id || post.userId == user.id)
  },
  render: function() {
    let isOwner = this.canDeleteMemory(this.context.currentBlogPost, post, this.context.currentUser);
    return isOwner ? <a>Delete</a> : null;
  }
});

ブログが定義されていないため、blog.userIdで常にエラーが発生します...したがって、このように条件を変更しますlet isOwner = this.context.currentBlogPost && this.canDeleteMemory(this.context.currentBlogPost, post, this.context.currentUser);
しかし、削除アイコンは表示されません...しかし、BlogPostTextコンポーネントをredux selectでラップしてthis.props.currentBlogPostを使用すると、contextTypeを使用する代わりに、正常に機能します。

したがって、コンテキストの変更は再レンダリングなどをトリガーしません...または私はそれを間違って使用していますか？

@ aghosh47コンテキストの変更は再レンダリングをトリガーすると思いますが、エッジケースを見逃した可能性があります。 問題を示す簡単なjsfiddleを作成できれば、調査に役立ちます。

また、githubの問題を可能な限り話題にしておきたいので、新しい問題に投稿してください。

@jimfbわかりました。コードを再確認し、何かが足りないかどうかを確認し、解決できない場合は新しいスレッドを作成します

@jimfb子孫を再マウントせずに親を変更することについての議論はどこにありますか？ 私はそのようなことを予期していなかったので、予期しない動作の変更が導入された場合、Reactの将来のバージョンでアプリが発生する可能性があるのではないかと心配しています。 だから私はその議論について常に情報を得たい

私が偶然見つけたコンテキストのもう1つのユースケースは、コンポーネントが複数の遷移グループの下にある場合です。 たとえば、最初にマウントするのではなく、すべての祖先遷移グループが実際に表示/入力されたときに入力にフォーカスできるようにしたいと思います。 コンテキストを介して渡されたメソッドを介して表示/入力された祖先のコールバックを登録するのが最も便利な方法です。

@ jedwards1211正直なところ、どこで議論されたのか覚えていません。 それが対面での議論であった可能性は十分にありますが、オンラインで多くの親を取り戻す議論があり、おそらくそこで見つかるでしょう。

ping @ aghosh47

ハハハ

@jimfbまあ、問題は解決されました...コードにエラーがあり、コードを書いた人はcatchを使用して

したがって、親の小道具が変更された場合、子のcontextTypeは反映されます...ありがとう。

それらのグローバルを格納する1つのオブジェクトにウィンドウを使用することの本当に何が問題になっていますか？

@cauburtinこれは、作成されたすべてのコンポーネントが同じグローバル状態を共有するサーバー側では実際には機能しません。 コンテキストは、単一のツリーにレンダリングされたすべてのコンポーネントに対してグローバルですが、ツリー自体に対してローカルです。 グローバルな状態とは異なり、他の木に漏れることはありません。

ちなみに、この質問は問題とは何の関係もありませんね。 ：ウィンク：

@fatfiszユースケースはよくわかりません。クライアントでのみウィンドウプロパティを指すrequire（ 'foo'）を使用することもできます。

ところで、私のアプリでは、コンテキストが不明確に見え、ほとんどすべてのコンポーネントが私の場合はそれを使用しているため、すべてのコンポーネントの小道具でオブジェクトを渡すことになりました

ありがとう

何が問題なのですか：

// context.js
module.exports  = { // sorry for using commonjs, since most of you use import/export I guess
  // some shared variables, initialized and used by components
};

次にrequire（ './ context.js'）; コンテキスト変数とメソッドにアクセスする必要があるすべてのファイル

カプセル化はおそらく尊重されていませんが、まあ..

（@gaeron）

@cauburtinコンテキストは、次の理由で役立ちます。

1）モジュールのエクスポートとは異なり、変更して再レンダリングをトリガーできます
2）親がオーバーライドできます。これは最も便利な機能です。
3）シングルトンである必要はありません。これは、データを分離するサーバーレンダリングに役立ちます。

2）と3）に同意しました
1）まだそれを行う必要はありませんが、コンテキスト内でreactインスタンスを渡すこともできます（これは悪い習慣だとよく耳にしますが、おそらくそう思うかもしれませんが、ドキュメントにも記載されています：思い出してください必要に応じて、Reactコンポーネント全体を小道具に渡すこともできます（この場合、小道具は代わりにこのシングルトンコンテキストにすることができます）。私にとって、Reactはビュー、イベントリスナー、および（トップ/ルート）リモートコントロールです。この共有コンテキストは、リモートコントロールへの共有アクセスになります。サブコンポーネントは、小道具が変更されたときに更新でき、場合によってはそのグローバルコンテキストにアクセスして使用できます（特にこの場合、シングルトンのファンではありません。 '受け渡しを再利用できます。小道具の方法でインスタンスに反応します。それが役立つ場合、この「受け渡し」は、共通の親クラスまたは構成によって多かれ少なかれ自動化/非表示にできます）

これをうまく書いていると、シングルトンコンテキストのアイデアが悪いことに気づきます:)

紛らわしいのは、Reactドキュメントはコンテキストを使用するようにあまり招待しないことです。実際にはオプションの小道具のようなもので、要求したときに取得しますか？

私はreactnativeを使用してAndroidにDrawerを実装し、ドロワーメニューコードとドロワーコンテンツコード用に異なるファイルを作成しようとしています。 これを行うために、私は別のreactコンポーネントを作成しました。 これらのファイルですべての作業を行うことができますが、コンポーネントファイルでドロワーの一部の操作を実行するにはドロワー参照が必要です。 これが私のコードです。openDrawer（）のようなドロワーメソッドを使用するために、ドロワーの参照を他のコンポーネントファイルに渡すにはどうすればよいですか。

'use strict';

    var React = require('react-native');
    var { View,
          StyleSheet,
          TouchableHighlight,
          } = React;

    var DrawerLayout = require('react-native-drawer-layout');
    var DrawerScreen = require('./DrawerScreen');
    var DrawerMenu = require('./DrawerMenu');

    var DrawerLayoutExample = React.createClass({

      render: function() {
        var navigationView = (
          <View >
               <DrawerMenu/>
          </View>
        );

        return (
          <DrawerLayout
            onDrawerSlide={(e) => this.setState({drawerSlideOutput: JSON.stringify(e.nativeEvent)})}
            onDrawerStateChanged={(e) => this.setState({drawerStateChangedOutput: JSON.stringify(e)})}
            drawerWidth={200}
            ref={(drawer) => { return this.drawer = drawer  }}
            keyboardDismissMode="on-drag"
            renderNavigationView={() => navigationView}>
            <View style={styles.container}>
 // Here is content component for drawer, need to refer drawer reference
            <DrawerScreen ></DrawerScreen>
            </View>
          </DrawerLayout>
        );
      }
    });

    var styles = StyleSheet.create({
      container: {
        alignItems: 'center',
        justifyContent: 'center',
        flex: 1,
        flexDirection: 'column',
      },
     });

    module.exports = DrawerLayoutExample;

DrawerScreen.js

'use strict';
var React = require('react-native');
var {
  AppRegistry,
  StyleSheet,
  Text,
  View,
  Dimensions,
  Image,
  TouchableHighlight,
  TextInput,
} = React;

var deviceWidth = Dimensions.get('window').width;

var DrawerScreen = React.createClass({


  render: function() {
    return (

        <View style={styles.container}>

          <Text style={styles.welcome}>Content!</Text>

          <TouchableHighlight onPress={() => this.state.openDrawer()}>
            <Text>Open drawer</Text>
          </TouchableHighlight>
          <TextInput style={styles.inputField} />
        </View>
    );
  },

});

var styles = StyleSheet.create({
   container: {
      alignItems: 'center',
      justifyContent: 'center',
      flex: 1,
          flexDirection: 'column',
    },
    inputField: {
      backgroundColor: '#F2F2F2',
      height: 40,
    },
});

現在、私はreduxを使用してメディアクエリをサブスクライブおよび保存しているため、コンポーネントは電話などで異なるレンダリングを決定できます。

つまり、純粋なコンポーネントにはストアへのサブスクリプションが必要であり、Reduxのサブスクライブモデルは言うまでもなく、そのような匂いは私には間違っています。

この場合、コンテキストはそれを保存するのにはるかに良い場所だと思いますが、この問題により私はそれを使用できません。

@wmertensこれはcomponentDidMountで実行する必要があるものですよね？

@cauburtinは

サイズ変更の場合は、componentDidMountでリッスンできます。言語の場合は、すべてを再レンダリングします。

次のようなクールなものがある場合は、すべてのサイズ変更ロジックを繰り返さない方がいいです。
apo全体をリッスンしてサーバー側で動作するreduxactioncreator
あまりにも…
state.response.isPhone / isPrerender / screenwidthなどがあります。サーバー上で、
ユーザーエージェントに基づいて発送します。 きちんとした。

金、2016年4月29日には、16:52シリルAuburtin [email protected]
書きました：

サイズ変更については、componentDidMountで聞くことができます。言語については、
すべてを再レンダリングする

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/facebook/react/issues/2517#issuecomment -215742327

うわー。
（モバイルで入力、簡潔さを言い訳）

しかし、ええ、ツリーの一番上にある単純なkey = {lang}で十分です。
言語。 ただし、アニメーションのあるサイトにはあまり適していません。

2016年4月29日金曜日、午後6時7分Wout Mertenswout。 [email protected]は書いた：

次のようなクールなものがある場合は、すべてのサイズ変更ロジックを繰り返さない方がいいです。
apo全体をリッスンしてサーバー側で動作するreduxactioncreator
あまりにも…
state.response.isPhone / isPrerender / screenwidthなどがあります。
サーバー、ユーザーエージェントに基づいてディスパッチします。 きちんとした。

金、2016年4月29日には、16:52シリルAuburtin [email protected]
書きました：

サイズ変更については、componentDidMountで聞くことができます。言語については、
すべてを再レンダリングする

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/facebook/react/issues/2517#issuecomment -215742327

うわー。
（モバイルで入力、簡潔さを言い訳）

うわー。
（モバイルで入力、簡潔さを言い訳）

私はあなたのようでしたが、サイズ変更イベントリスナーは実際には安価であり、同じタイプのリスナーがたくさんあることは悪いことではないと思います

いいえ、安いのは間違いありません。ずっと簡単なだけです。
サイズ変更ハンドラーを管理するよりもthis.context.isPhoneを記述します。

18:38シリルAuburtinで金、2016年4月29日には[email protected]
書きました：

私はあなたのようでしたが、サイズ変更イベントリスナーは実際には安いです、私はしません
同じタイプのリスナーがたくさんいるのは悪いことだと思います

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/facebook/react/issues/2517#issuecomment -215797819

うわー。
（モバイルで入力、簡潔さを言い訳）

問題は、react-reduxが=== ReactElementを返し、renderメソッドから「更新なし」であることを通知することです。 ただし、実際には、このショートカットは、コンテキストが===である場合にのみヒットし、コンポーネントから制御することはできません。 しかし、なぜこれがこのように行われるのか完全にはわかりません。 おそらく、react-reduxの人たちへの質問です。

Reduxの操作については、 https：//github.com/reactjs/react-router/issues/470およびPRでの継続的な議論を参照して

ある時点で、 https：//github.com/reactjs/react-router/issues/3484を実際に解決して、他のライブラリがこれを簡単に使用できるようにしますが、当初の考えよりも困難です。

react-routerで現在使用されているソリューションについての注意。 それは機能しますが、イライラするハックです。 コンテキストをインプレースで変更するか、ユーザーがコンテキストオブジェクト間の参照IDを維持する必要があります。

どちらも素晴らしいことではありませんが、本当の問題は、コンポーネント階層の周りのワームホールコンテキストがデータフローのReactコンポーネントモデルの最も優れたビットの1つを壊すことです。つまり、中間（権限を持つ）のすべてがコンテキストを調整できるということです。 。 「帯域外」コンポーネントを介してコンテキストを渡すことにより、コンテキストを子にマッピングするために別のメカニズムを使用する必要があります。そうでない場合もあります。 確かにそれは_一般的な_ユースケースではありませんが、とにかくコンテキストの使用法のすべてを説明しています

2つのアプローチの間では、少なくとも_ある程度_一般的ですが...今のところできる最善のことだと思います😛

はいinded：P、それはまだ最適ではなく、コンテキストが一般的に機能する方法を修正するための良い代替品ではないことに注意してください

@jquense真ん中のコンポーネントは、 contextTypesを宣言して上からコンテキストオブジェクトをリッスンし、 childContextTypes / getChildContext()を宣言してそのコンテキストの変更されたコピーを提供することができませんでしたその子孫？

@DarylCantrellコンポーネントは、要求するコンテキストの各部分にオプトインする必要があります。 contextTypesを宣言して、コンテキスト全体をコンポーネントにホールセールで渡す方法はありません。

いずれにせよ、私のポイントは、コンテキストのビットを調整することは可能であり、コンテキストの優れた機能であり、この問題の回避策によって壊れているということです

@ 1000hzもちろんですが、彼は「コンテキストの一部を調整する」ことについて話していました。 そのシナリオでは、「全体」のコンテキストを取得する必要はなく、オーバーライドする予定の部分だけを取得する必要があります。

@DarylCantrellおっと、私はあなたの意図を読み間違えました。

この問題のプルリクエストを送信しました：＃7213

（プルリクエストから）
コンテキストを使用して、ロケールとルーティング情報を伝達しています。 私の問題は、コンテキストが変更されると、一部の純粋コンポーネントがサブツリーのレンダリングを停止することです（純粋コンポーネントは状態と小道具のみをチェックするため）。 これは、問題＃2517によると、多くの人にとって問題です。

中間コンポーネントのコンテキストをマスキングしない方がマスキングよりも優れており、定義されたcontextTypesは検証にのみ使用され、フィルタリングには使用されないと私は考えました。 これはpropTypesの動作と似ており、指定されたプロパティは検証されますが、指定されていないプロパティは引き続きコンポーネントで使用できます。 この更新を反映するようにテストを更新しました。

コンテキストに関心のないコンポーネントは通常、コンテキスト引数を使用しないため、コンテキストをマスクしなくても、既存のコンポーネントが破損することはありません。ただし、そのコンポーネントがコンテキストパラメータが未定義であることを明示的にチェックしている場合を除きます。 ただし、これにより、洗練された純粋コンポーネント、たとえば、shouldComponentUpdateの状態、小道具、コンテキストを比較するContextAwarePureComponentの機会が生まれ、コンテキストが更新されて純粋コンポーネントが再レンダリングされるようになります。

私は現在、ラジウムといくつかのreact-bootstrapコンポーネントを使用して、このパッチで開発を実行していますが、問題は発生しませんでした

こんにちは@bvella 、私はあなたがこのプルリクエストを意味したと思います：7212ではなく＃7213。

@DarylCantrellそうです、ありがとう

https://github.com/facebook/react/pull/7213 / https://github.com/facebook/react/pull/7225は良いものであり、適応させる必要があると思います

私の理解では、コンテキストはグローバル変数のようなものであるため、使用を制限する必要があります。
ただし、これは、ユーザーがグローバル変数にアクセスする前に宣言を行う必要があるという意味ではありません。
グローバル変数は、宣言するかどうかに関係なく、常にアクセス可能である必要があります。

contextType宣言は、propTypesと同様に、検証目的でのみ機能する必要があります

繰り返しになりますが、ご迷惑をおかけしますので、ご了承ください。
（私はreact Relayを使用しており、すべてのコンテキストオブジェクトを非表示にします）

私はhttps://github.com/facebook/react/pull/7225#issuecomment-276618328にコメントし、コンテキストはすべてを更新するだけでよく、 sCUはそのコンポーネントを再レンダリングする必要があるかどうかを判断するためだけに役立つと主張しました; その子は関係なく検証されます。

この方法でコンテキストの更新を行うとコストがかかりますが、ツリー全体を強制的にレンダリングするよりもコストがかかりません。これは、現在、コンテキストの更新を取得してすべてのコンポーネントに適用する唯一の方法です。 コンテキストはそれほど変化しないはずです。 急速に変化するアップデート（例：Redux）にはより良いオプションがあります。

純粋成分

https://60devs.com/pure-component-in-react.html

https://hackernoon.com/react-purecomponent-considered-harmful-8155b5c1d4bc

現在、解決策はありますか？

このスレッドからわかるように、既存のソリューションはかなり根本的に壊れています。
すべてのアプリを遅くせずに現在のAPIを修正することはできません（これは避けたいです:-)。

したがって、同じユースケースを処理するが、それらの設計上の欠陥がない新しいAPIを提案します。 計画では、APIを並べて存在させ、後でユーザーが移行したときに古いAPIを段階的に廃止する予定です。

ディスカッションをチェックしてください： https ：

@acdliteは、新しいコンテキストAPI（ https://github.com/facebook/react/pull/11818）を使用してPRを開始しました

これは閉鎖的と見なすことができると思います。 新しいAPIにはこの問題はありません。 古いAPIは修正できません。主要なライブラリが新しいAPIにアップグレードされた後、ある時点で非推奨になります。

新しいAPIが利用可能になり、次のマイナーなReact16.xリリースの1つで文書化されます。

@gaearonこれを頻繁に聞くかどうかは