React: ComponentDidMount内の新しいコンテキストAPIにアクセスする方法はありますか？

これを機能させようとしている例を追加します： //codesandbox.io/s/l20yn296w7

編集： https：//github.com/reactjs/rfcs/blob/master/text/0002-new-version-of-context.md#class-based-apiのガイドラインに従ってください

これは、新しいAPIで実現できる方法です。

class BaseMapElement extends React.Component {
  componentDidMount() {
    console.log(this.props.context);
  }

  render() {
    return null;
  }
}

const MapElement = () => (
  <Context.Consumer>
    {context =>
      <BaseMapElement context={context} />
    }
  </Context.Consumer>
)

では、 componentDidMount介してアクセスする唯一の方法は、小道具にリダイレクトすることですか？

編集： componentDidMount

小道具に再構築する高次コンポーネントは良いパターンですが、通常は追加のコンポーネントが必要ない場合は、次のようにコンポーネントインスタンスにコンテキスト値を格納します。 this.contextValue = value次にアクセスします。ライフサイクルフック。 少し醜いですが、最適化としてより良い、その場限りのパターンをオプトアウトしているので、一般的には大丈夫だと思います

私は同じジレンマに直面しています。
ライフサイクルメソッドでコンテキストにアクセスしたり、コンテキストを呼び出したりする簡単な方法があるはずです。
ものを初期化したり、データをチェックしてフェッチしたり、アンマウント時にクリーンアップしたりする必要があるかもしれません。
人々は現在、おそらく壊れている状況でそれを行っています。
はい、コンポーネントを別のコンポーネントでラップすることで解決できます。 しかし、解決策というよりは回避策のように感じます。

次のようにコンポーネントインスタンスにコンテキスト値を格納します：this.contextValue = value次に、ライフサイクルフックでそれにアクセスします

これは非同期モードでは安全ではないと確信しています。 これをしないでください。 cc @acdlite

はい、コンポーネントを別のコンポーネントでラップすることで解決できます。 しかし、解決策というよりは回避策のように感じます。

私はそれに同意します。 componentDidMountとcomponentWillUnmountを介してネイティブにアクセスし、初期化/クリーンアップできるようにすると便利です。

一般に、インスタンス変数を巧妙に使用して通常のデータフローをだますと、非同期で問題が発生します。 しないでください。 インスタンス変数はタイマーなどの特定のことを行う唯一の方法であるため、今日は少し混乱しています。 非同期をリリースする前に、より明確な推奨事項を公開します。そしていつの日か、インスタンスにあまり依存しない新しいコンポーネントAPIを入手する予定です。

tl; dr：小道具の間接参照を使用します。 そして、余分なコンポーネントについてはあまり心配しないでください。

これは非同期モードでは安全ではないと確信しています。 これをしないでください。

これはどのように（そしてどのように）安全ではないでしょうか？ 非同期モードについてのこのすべての話では、「安全でない」とはどういう意味かははっきりしていません。 それは、行動が不合理で予測不可能なブギーマンのように感じ始めています。これは、単純で理解しやすいデータフローモデルで一般的に好まれているシステムで、人々を多くの保証で満たすことはありません。 コンポーネントが再び魔法のオブジェクトである0.13以前の土地に戻ったような気がします。

「別のコンポーネントを追加するだけ」と言うのも簡単ですが、それはしばしば面倒であり、独自のカテゴリのバグと課題をもたらします。 私は、人々が「安全」であるために、reactAPIを介して抽象化を発明しなければならないような気がし始めません。

申し訳ありません^上記がイライラ/怒りに聞こえる場合、私はそのトーンを意図していませんでした！ phhhhoooneで

それは怒っているように聞こえましたが、私はあなたの主張を理解し、それがどのように/なぜ安全でないのかについてあなたの質問を共有します

行動が不合理で予測不可能なブギーマンのように感じ始めています

申し訳ありませんが、私たちは1か月以上、具体的な提案を含むガイダンスに取り組んでいます。 それらを収集してブログ投稿として公開する時間を与えてください。 また、実際のアルファを使用せずに議論することも困難です。これも私たちが懸命に取り組んできたものです。

したがって、何も言わないか、うまく機能しないことについて事前に警告する必要があります。 私たちは警告の側で誤りを犯しますが、私たちはあなたにとってそれをより困難にしているように見えることがわかります。 コードが出て、それで遊ぶことができれば、私たちが何を意味するのかがわかり、それがより理にかなっていると確信しています。

これはどのように（そしてどのように）安全ではないでしょうか？

私の話を見る機会はありましたか？ なぜこれを行っているの

あなたが話を見たと仮定して、これはこの特定のケースについてのより具体的な説明です。 デモで示したようにレンダリングを「一時停止」できるようにするには、Reactがいつでも、場合によってはさまざまな小道具を使用してrender()を呼び出すことができる必要があります。 たとえば、 this.propsとthis.stateを新しい画面（ロード中）の小道具に設定する場合は、 render呼び出しますが、古いthis.propsまた、現在のバージョンのツリーでのインタラクションに応答してレンダリングする場合はthis.state （たとえば、新しい画面の読み込み中に何かを押す場合）。

非同期では、経験則は次のとおりです。 componentDidMount 、 componentDidUpdate 、 componentWillUnmountなどのライフサイクルとrefコールバックのみが、対応する小道具と状態を使用して、明確に定義された時点で実行されます。画面に表示されているものに。 幸いなことに、この図にうまく適合しないライフサイクルは他にもいくつかあり、それらのより良い代替案を紹介しています（ getDerivedPropsFromState 、 getSnapshotBeforeUpdate ）。 これは段階的な移行になります。 繰り返しになりますが、それはすべてブログ投稿に含まれる予定です。

今、この問題の根本に。 非同期モードでは、 Reactはrenderメソッドをいつどの順序で呼び出すかについて保証しません。 これは、Reactがそもそも保証することのなかったものです。たまたま、毎回同じ順序でした。 フィールドをrender保存してから、ライフサイクルで読み取ることは「安全」ではありません。Reactがrenderと呼ばれるときに、さまざまな小道具（中断されたツリーなど）でフィールドを保存する可能性があるためです。まだ準備ができていません）。

ライフサイクルメソッドでコンテキストにアクセスしたり、コンテキストを呼び出したりする簡単な方法があるはずです。
はい、コンポーネントを別のコンポーネントでラップすることで解決できます。 しかし、解決策というよりは回避策のように感じます。

余分なラッパーのように感じること新しいコンテキストを高速化する理由です。 ツリーに明示的なラッパーノードがない場合、更新が必要なコンポーネントをすばやく「見つける」ことはできません。

ライフサイクルでコンテキストにアクセスする必要がある場合は、それを小道具として使用してください。

class Button extends React.Component {
  componentDidMount() {
    alert(this.props.theme);
  }

  render() {
    const { theme, children } = this.props;
    return (
      <button className={theme ? 'dark' : 'light'}>
        {children}
      </button>
    );
  }
}

export default React.forwardRef((props, ref) => (
  <ThemeContext.Consumer>
    {theme => <Button {...props} theme={theme} ref={ref} />}
  </ThemeContext.Consumer>
));

これは、 contextTypes定義とほぼ同じ行数です。

はい、コンポーネントを別のコンポーネントでラップすることで解決できます。 しかし、解決策というよりは回避策のように感じます。

子関数/レンダリングプロップアプローチは新しいコンテキストの_公式API_であるとダンが言ったことを2番目にしたかったので、それを使用して、Reactに高速であることを心配させてください。 （そうなる！）

これはどのように（そしてどのように）安全ではないでしょうか？

ドラフトのStrictModeドキュメントは、インスタンスの変更（これは単なる別のタイプの副作用です）が非同期モードで危険である理由のいくつかにも触れています。

ここで提案されているガイドラインに従った実験的なブランチがあります。 誰かがそれが理にかなっているかどうかを確認するために見ることができますか？ https://github.com/commodityvectors/react-mapbox-gl/pull/11

私はこのライブラリに精通していないので、人々がそのコンポーネントでrefを利用したことがあるかどうかはわかりませんが、利用した場合、そのPRのwithContextミックスインは新しいforwardRef API 。

意味がある。 参照していただきありがとうございます。 とりあえずこの問題を解決します。

私は同じことを達成できるかどうかを確認しようとしていたので、この問題に遭遇しました。

したがって、これらすべてから収集できることから、 Context.Consumerを使用するコンポーネントでは、子レンダリング関数の外部でAPIにアクセスすることはできません。 私はこれを少し簡単にするために働くかもしれない何かを思いついた（これが何らかの理由で良い習慣でないならば、いくつかのフィードバックを本当に感謝するだろう）：

const MapElement = (props) => (
  <Context.Consumer>
    {context =>
      <RunOnLifecycle
        runOnMount={() => { /*use context*/ }}
        runOnUnMount={() => { /*use context*/ }}
        runOnUpdate={(prevProps) => { /*use context - compare prevProps with props */ }}
        { ...props }
      />
    }
  </Context.Consumer>
)

そして、そのヘルパーコンポーネント<RunOnLifecycle/> ：

export interface IPropsRunOnLifecycle {
  runOnMount?: () => void;
  runOnUpdate?: (prevProps: object) => void;
  runOnUnMount?: () => void;
  children?: JSX.Element | ReactNode;
  [prop: string]: any;
}

export class RunOnLifecycle extends React.Component<IPropsRunOnLifecycle> {
  componentDidUpdate(prevProps, prevState, snapshot) {
    if (this.props.runOnUpdate != null) {
      this.props.runOnUpdate(prevProps);
    }
  }

  componentDidMount() {
    if (this.props.runOnMount != null) {
      this.props.runOnMount();
    }
  }

  componentWillUnmount() {
    if (this.props.runOnUnMount != null) {
      this.props.runOnUnMount();
    }
  }

  render() { return this.props.children || null; }
}

これが将来の頭痛の種になるのではないかと考えています。 多少のハックではありますが、それでもかなり標準的なReactのように感じます。

そのアプローチを悪い考えにするかもしれないいくつかの微妙な違いがあります。 たとえば、 MapElementがrunOnMountコールバックが実行されたときに

😄代わりに、これにHOCアプローチを使用することをお勧めします：
https://reactjs.org/docs/context.html#sumption -context-with-a-hoc

この種のことにHOCを使用することの唯一の本当の欠点は、 forwardRef APIによって軽減されています。
https://reactjs.org/docs/react-api.html#reactforwardref

私たちは、reactドキュメントや人々がここで言ったことのようなアプローチを取りました。 これまでのところうまく機能しています。

https://github.com/commodityvectors/react-mapbox-gl/blob/master/src/Map.js#L63

そのアプローチを悪い考えにするかもしれないいくつかの微妙な違いがあります。 たとえば、MapElementが参照を使用するクラスコンポーネントである場合、runOnMountコールバックが実行されたときに参照はまだ設定されていません。

フィードバック@bvaughnをありがとう。 現時点では、コンテキストツリー内にマウントされているものに応じて、UIに物事を追加/削除する一種の状態プロキシコンポーネントとして純粋に使用しています。 ポータルのようなものですが、Reactコンポーネントツリー内にあります。 したがって、実際に子をレンダリングしたり、参照を処理したりすることはまったくありません。

refと相互作用する何かをする必要がある場合は覚えておいてください。

こんにちは、みなさん、

ライフサイクルメソッドのコンテキストデータが必要です。 そのため、最初のいくつかのコメントを確認した後、HOCアプローチに従い、コンテキストデータを小道具として渡しました。
すべてが期待どおりに機能しています。 しかし今、私はコンポーネントの単体テストケースを書きたいのですが、それができません。

このシナリオのテストケースを作成する方法を誰かに教えていただければ幸いです。

私は酵素、酵素アダプター反応16、およびジェストを使用していますが、使用に問題があります。

@AmnArora

私が働いている会社では、次のことを行っています（これはコンセンサスではない可能性があります）。「裸の」コンポーネントもエクスポートしてから、テストにインポートし、手動で小道具に合格します。

例えば

// MyComponent.js
export class MyComponent extends Component { /* ... */ }
export default HOC()(MyComponent)

// MyComponent.spec.js
import { MyComponent } from '...'

// OtherComponents.js
import MyComponent from '...'

また、この議論に加えて、同じ問題が発生し、複数のコンテキストを消費するこのhttps://www.npmjs.com/package/react-context-consumer-hocを作成しました。

すべてが期待どおりに機能しています。 しかし今、私はコンポーネントの単体テストケースを書きたいのですが、それができません。

@AmnAroraなぜユニットテストを書くことができないのですか？ 何を試しましたか？ どのようなエラーが発生していますか？

@pgarciacamouまず、迅速な返信に感謝します。 さて、ウェブ上で何も見つからず、ここにクエリを投稿した後。 私はあなたが言ったのと同じ解決策を思いついた。

テストケースは現在機能していますが、これは回避策のようです。 https://www.npmjs.com/package/react-context-consumer-hocを見て、チームと話し合い

ありがとう。 ：100：

@bvaughn以前、状態管理にreduxを使用していたとき、コンポーネントを浅くコピーし、dive（）メソッドとinstance（）メソッドを使用してコンポーネントのインスタンスを取得しました。

ただし、コンテキストAPIを使用する場合、これらのメソッドはいずれも使用できませんでした。

そして、これらの方法のいずれも使用していなかったとき、次のエラーが発生していました： _タグ12の不明なノード_

ガッチャ。

これらは両方とも、使用しているEnzymeのバージョンが新しいコンテキストAPIを適切にサポートしていないという問題のように聞こえます。 それは残念です。

reduxとunistore （多くのコード汚染/余分な可動部分imo）に大きな嫌悪感を覚え、ネストされたコンポーネントが単一のグローバル状態にアクセスできるようにする次のセットアップにつながりました。 グローバル状態であってはならない他のすべて（つまり、テキスト入力値、トグル値）は、ネストされた各コンポーネントのローカル状態内に格納されます。

https://github.com/davalapar/session-context

こんにちは、

この問題は解決されましたか？

3つのコンポーネントがあるシナリオがあります。 クリエーター、ディスプレイ、セル。
Cellには、CreatorとDisplayの両方で使用されるレンダリングロジックがあります。

現在、アイテムが作成されているか、表示する必要がある場合は、ステータスを渡す必要があります。 さまざまな場所でセルを使用したので、ステータスを小道具として個別に渡す必要があります。 そのため、ステータスにコンテキストを使用したかったのですが、問題は、ディスプレイコンポーネントがマウントされている場合にのみコンテキストを変更したいということです。 これはReactの現在のバージョンです。 （私はReact 16.7を使用しています）

componentDidMount Context.Consumer値にアクセスする方法を示す上記のコメントが

React 16.6では、クラスに新しいcontextType APIが追加され、 componentDidMount新しいコンテキストを簡単に読み取ることができることに注意してください。

https://reactjs.org/docs/context.html#classcontexttype

ええ、コンポーネントで単一のコンテキストを使用するだけでよい場合は、 contextTypeが便利なオプションです。

React 16.6では、クラスに新しいcontextType APIが追加され、 componentDidMount新しいコンテキストを簡単に読み取ることができることに注意してください。

そうではありません。 単一のコンテキストタイプで十分な場合でも、Class.contextTypeは継承を中断します。 HOCについても同じことが言えます。

コンポーネント間でコードを再利用するために、継承よりもコンポジションを推奨することについて、ドキュメントでかなり明確にしています。 それを超えて、私はあなたが言っていることを本当に理解していません。

contextType APIは、間違いなくcomponentDidMountコンテキスト値に簡単にアクセスできるようにします（これがこのスレッドの目的です）。

継承よりもコンポジションを推奨することについて、ドキュメントでかなり明確にしています...

広すぎる...

私が今苦労しているのは、実装をサポートするために必要な一連の共通機能を備えたコンポーネントのファミリーがあるということです。 コンテキストビットを除いて、すべてが継承によって完全にモデル化されています。

このような状況でのみコンテキストを混乱させるように思われることを考えると、コンテキストAPIはかなりイライラします。

...これがこのスレッドの内容です...

はい、このコメントは少し話題から外れています。

Context ClassでcontextTypeを変更すると、reduxストアが壊れます：/

React 16.6は、componentDidMountで新しいコンテキストを簡単に読み取ることができるクラス用の新しいcontextTypeAPIを追加したことに注意してください。

ええ、コンポーネントで単一のコンテキストを使用するだけでよい場合は、contextTypeが便利なオプションです。

MyCoolComponent.contextTypeに割り当てる前にコンテキストを作成する方法はありませんか？

私が読んだのは、今のところ、次のことができるコンポーネントが必要な場合です。

a）複数のコンテキストを消費する
b） render以外のメソッドでそれらのコンテキストからのものを使用する

これは、ラッパーがコンテキストを消費し、子に小道具を渡すという説明されたパターンに固執していることを意味します

理想的な状況は、このようなものを書いて、両方の世界を最大限に活用できることだと思います（つまり、クラス全体で複数のコンテキストを利用できます）。

MyCoolComponent.contextType =  composeContexts(OneContext, TwoContext, RedContext, BlueContext)

これを行う方法はありますか？

これはrenderメソッドでは機能しますが、他のメソッドでは機能しません。

ちょっと、そこ。
クラスコンポーネントのコンストラクターで新しいコンテキストAPIを使用する可能性はありますか？

プロジェクトをv15.xからv16.xに移行しています。タスクの1つは、新しいコンテキストAPIを使用することです。
私たちのプロジェクトでは、css-modules + isomorphic-style-loaderを使用します。後者は、コンポーネントのスタイルシートをDOMに挿入するためのいくつかのAPIを公開します。

V15では、これらのAPIを古いコンテキストAPIに配置し、各コンポーネントが次のような方法で取得できるようにします。

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

V15では、これをcomponentWillMountに配置できます。 これにより、レンダリング前にコンポーネントのスタイルが正しくなります。

ただし、V16では、componentWillMountは安全ではないとマークされており、将来的には非推奨になります。
したがって、当面の考えは、context.insertCss呼び出しをコンポーネントのコンストラクターに入れることです。

しかし、文書から見ると、

contextTypesがコンポーネント内で定義されている場合、次のライフサイクルメソッドは追加のパラメーターであるコンテキストオブジェクトを受け取ります。

コンストラクター（小道具、コンテキスト）

この使用法（2番目のパラメーターとしてコンテキストを使用）も非推奨になります。

MyComp.contextType = StyleContextを割り当てて、新しいコンテキストAPIを試しました
それでも、this.contextがコンストラクターで未定義であることがわかりました。

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

コンストラクターでコンテキストを使用する方法に関する実用的なガイドはありますか？

何かアドバイス？

ちょっと、そこ。
クラスコンポーネントのコンストラクターで新しいコンテキストAPIを使用する可能性はありますか？

プロジェクトをv15.xからv16.xに移行しています。タスクの1つは、新しいコンテキストAPIを使用することです。
私たちのプロジェクトでは、css-modules + isomorphic-style-loaderを使用します。後者は、コンポーネントのスタイルシートをDOMに挿入するためのいくつかのAPIを公開します。

V15では、これらのAPIを古いコンテキストAPIに配置し、各コンポーネントが次のような方法で取得できるようにします。

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

V15では、これをcomponentWillMountに配置できます。 これにより、レンダリング前にコンポーネントのスタイルが正しくなります。

ただし、V16では、componentWillMountは安全ではないとマークされており、将来的には非推奨になります。
したがって、当面の考えは、context.insertCss呼び出しをコンポーネントのコンストラクターに入れることです。

しかし、文書から見ると、

contextTypesがコンポーネント内で定義されている場合、次のライフサイクルメソッドは追加のパラメーターであるコンテキストオブジェクトを受け取ります。

コンストラクター（小道具、コンテキスト）

この使用法（2番目のパラメーターとしてコンテキストを使用）も非推奨になります。

MyComp.contextType = StyleContextを割り当てて、新しいコンテキストAPIを試しました
それでも、this.contextがコンストラクターで未定義であることがわかりました。

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

コンストラクターでコンテキストを使用する方法に関する実用的なガイドはありますか？

何かアドバイス？

contextTypeを使用する代わりに、このようにすることができます

class MyComponent extends React.Component {
   render(){
       const {
         //props including context props
       } = this.props;
       return(<View />);
   }
};

const withContext = () => (
  <MyContext.Consumer>
    { (contextProps) => (<MyComponent {...contextProps}/>)}
  </MyContext.Consumer>
);

export default withContext;

私のようにレンダリング関数の外でそれを使用するのに苦労している人は、サブコンポーネントで以下を使用してください。

useContext（）

例えば：

const context = useContext(yourContext)

MainComponent.Subcomponent = () => {
 const context = useContext(context)

  useEffect(()=> {
    console.log(context)
  })
}