React: componentDidReceivePropsお願いします

なぜsetup(props)ないのですか？

私自身のプロジェクトを見ると、私が同様のニーズを持っていた場所でこれを行ったことがわかります（別のプロジェクトは小道具に基づいて状態のチャンクを導出しています）、必要に応じて別の小道具のセットを渡すだけなので、余分なものを渡すだけで済みます再利用する場合、どの小道具が必要かについての知識を複製することなく：

setup(props) {
  props = props || this.props
  UserActions.load(props.id)
}

@syranide問題は、セットアップが小道具も必要とするメソッドを呼び出す必要がある場合です。これは、小道具も必要とするメソッドを呼び出す必要があります...最終的に、コンポーネント全体が小道具の周りに配管されます。

+1は、現在のパターンでアプリ内に不要な配線がたくさんあるように見えます。 問題を解決するための簡潔で標準化された方法である可能性があります。 ComponentWillReceiveProps内のthis.propsで多くの人がやけどを負っているのを見て、直感的ではないことを明確に示しています。

+1、これもイライラします。

これが問題になることはもうありません。

+1、私も小道具をたくさん回していることに気づいています。 上記の@insinと同様に、私はしばらくの間デフォルトの

setup(props = this.props) {
  doSomething(props);
}

しかし、newPropsを渡すのを忘れた場合に発生する可能性のある微妙なバグのため、アンチパターンであると判断しました。

+1

利用できない理由は、 this.propsとthis.state常にレンダリングされた値に対応しているためだと思います。 この制約を破らずに別のレンダリングをトリガーしないcomponentDidReceivePropsを実装する方法はありません。

ほとんどの場合、 componentWillReceivePropsを使用している場合、実際にはリレーのような高次のコンポーネントか、 React 0.14用に提案されたobserveフックのようなものが必要です。

+1
また、 this.propsまたはthis.stateを変更せずにcomponentDidReceivePropsを実装できます。 これらから読み取るだけの場合は、別のレンダリングをトリガーしません。 この提案された関数呼び出し内で小道具や状態に書き込んでいる場合は、自分の足を撃っていますが、ライフサイクルの他のすべてのメソッドについても同じです。

+1

shouldComponentUpdateがfalse返したときに、新しい小道具イベントに応答できるようにしたいので、私の場合はcomponentDidUpdate使用できません。

+1

+1

componentWillMountとcomponentWillUpdate @ iammerrickはどうですか

shouldComponentUpdateがfalseを返したときに、新しいpropsイベントに応答できるようにしたいので、私の場合、componentDidUpdateを使用できません。

componentWillReceivePropsますか？

+1

+1これは、DRYコードとロジックの簡素化に役立ちます。

このスレッドを開始する例を単一の関数にするために、初期設定でcomponentDidReceivePropsを呼び出すことができます。

componentDidReceiveProps() {
  UserActions.load(this.props.id);
}

考え？

componentWillReceiveProps() {
  setTimeout(()=> {
    if(this.isMounted()) {
      this.componentDidReceiveProps();
    }
  });
}
componentDidReceiveProps() {
  UserActions.load(this.props.id);
}

どう思いますか？

@YourDeveloperFriendそれは、他のライフサイクルフックと比較してどのように機能するか、およびネストされたコンポーネントのカスケードタイムアウトによるレンダリングの遅延に依存すると思います。

これらの種類のライフサイクルフックは、レンダリング前に呼び出されることが保証されているパスで同期的に呼び出される必要があります。 Reactのコードベースについては調べていませんが、タイムアウト時にレンダリングが呼び出されないと想定しています。

ほとんどの場合、最良の解決策は、事前レンダリングフックの登録に沿ったものか、レンダリングロジックがrenderを呼び出す前にcomponentDidReceivePropsを呼び出すように小道具が変更されたコンポーネントをマークすることです。

+1してください。 とても醜い。

いや、元気です。 より良い解決策があります。

+1

componentDidReceiveProps()すでに存在します： render()と呼ばれます。 ただし、レンダリングを実行する前に、何かをロード/トリガーなどする必要がある場合があります（ @iammerrickの例のように）。 これは唯一のことを意味します：あなたは何か間違ったことをします。

あなたが次のようなことをするとき

setup(id) {
    UserActions.load(id);
}

コンポーネント内または（さらに悪いことに）外部のいずれかにステートフルネスを導入します。 コンポーネントが小道具を受け取るたびにload()データが必要になるのはなぜですか（新しいことが保証されているわけではありません）。 遅延読み込みを行う場合、適切な方法はrender()メソッドでデータを要求することです。

render() {
    var actions = UserActions.load(id);
    if (actions) // render
    else // show spinner or return null, etc.
}

UserActions.load = function(id) {
    if (data) return data;
    else // request the data, emit change on success
}

@robyoder 、関数に引数を渡すのは醜いことではありません。 冗長すぎるように見えるかもしれませんが、選択したプログラミング言語では当然です。 冗長性を減らすためだけに予備のライフサイクルメソッドを追加してAPIを破棄することは、確かに醜いことです。

@ me-andre、なぜcomponentWillUpdateとcomponentWillReceiveProps両方があるのですか？

私の意見では、それはそれらが異なる目的を果たし、両方が役立つからです。 これら2つが同じではないのと同じように、 renderは、新しい小道具以外の理由で呼び出されるため、架空のcomponentDidReceivePropsと同じではありません。 さらに、以前の小道具へのアクセスは許可されていません。

以前の小道具の利点は、毎回データをロードする必要がないことです。 小道具とそれらが変更されたかどうかに基づいて条件付きにすることができます。

明らかに、「[醜さ]は見る人の目にあります」。適切なライフサイクル方法を追加することは、私にとってはるかにクリーンな解決策のように思えるからです。

多分これを見る別の方法があります...

ここでの主な目標は次のとおりです。

（1）人為的エラーを減らす-パラメータを渡すのを忘れたか、 props = props || this.propsもう一度使用する
（2）付加価値のないボイラープレートコードを減らすために-なぜ不必要に何かを書くのか
（3）使用するライフサイクル方法を決定しようとする認知的負担を軽減するために-なぜこのようなことを考える必要があるのか​​、なぜその日の気分に応じてわずかに異なるアプローチを使用し続けるのかなど

したがって、おそらくソリューションスペースは、これらの目標を達成するためにReactとReactAPI自体の両方の使用を簡素化することです。

これらの目標を念頭に置いて問題を考える場合、いくつかのライフサイクルメソッドがマージされる可能性があります。初期化と更新のどちらであるかを知りたい場合は、署名/引数を呼び出すことでわかります。 例： beforeRender(prevProps, prevState)またはupdate(prevProps, prevState) 。

個人的には、ライフサイクルメソッドが多すぎるように感じます。それらがより一貫して呼び出された場合（最初のパスと更新でprevProps / prevStateの有無にかかわらず）、コードが簡素化され、生産性が向上する可能性があります。 さらに、ライフサイクルメソッド名はかなり長く（入力するのではなくコピー/貼り付けする傾向があります）、どちらが存在するか/存在するかを思い出すのが難しいため、単純化できる/すべきだと思います。

@robyoder 、 componentWillUpdateとcomponentDidReceiveProps両方がある理由の簡単な答えは、それらの間に大きな違いがあるということです。 もちろん似ていますが、主にcomponentWillというプレフィックスが付いています。

| | 状態が変化しました| コンポーネントが更新されませんでした|
| --- | --- | --- |
| componentWillUpdate（）| はい| いいえ|
| componentWillReceiveProps（）| いいえ| はい|

お気づきかもしれませんが、一方のメソッドが呼び出され、もう一方のメソッドが呼び出されないライフサイクルポイント/条件があります。 そのため、2つの異なるライフサイクルメソッドがあります。

ただし、このトピックで説明されているcomponentDidReceiveProps()は、コンポーネントの状態や状態を表すものではなく、 componentWillReceiveProps()がアクセスできないものへのアクセスを提供しません。 わずかな構文糖衣を追加するだけで、便利または簡単に見える場合とそうでない場合があります。これは

@ me-andreあなたは私（@kmalakoff）と@robyoderに同時に応答しているかもしれません。 あるいはそうではないかもしれませんが、私はこの機会に議論を前進させます...

私が提起したのは、おそらく、上記の3つの目標を使用して現在のAPIを超えて考えることで、APIを単純化してそれらを実現する方法について新しい洞察や視点を得ることができるということでした。 もちろん、演習を終えた後、同じ場所にたどり着くかもしれません。

演習を行いましょう。

このトピックには重要なことがあるため、このトピックがフォローされて+1されていると仮定します。たとえば、 componentDidReceiveProps追加すると、APIの表面積が増えるため、お勧めできません。

表と私が提案した3つの目標を念頭に置いて、APIを単純化するためのアイデアや、このスレッドの人々にAPIを拡張しないようにするための別の方法（おそらくそれを削減/単純化するための方法）はありますか？ ）？

@kmalakoff 、あなたが話している3つのポイントは、それらに遭遇したときにAPIを使用するという点でのみAPIに関連しています。 それらは悪いデザインが原因ではありません。

あなたが話す最初の問題は、ライフサイクルメソッドが異なる議論をするということです。 まあ、それは完全に自然なことです-彼らは異なる目的を果たします。 componentWillReceivePropsは、このメソッドが追加されたときに月がいっぱいだったためではなく、コンポーネントにまだ割り当てられていない小道具を受け取るために小道具を受け取ります。 propsは、 this.propsとは異なる（可能性がある）メソッドでのみ渡されます。 これは実際にはヒントであり、問​​題ではありません。
問題＃3は、使用するコールバック/アプローチを決定するのが難しいことです。 さて、私が上で話したメソッドが同じ署名を持つまで、stateとthis.state 、 propsとthis.props両方がほとんどのメソッドで等しい（意味がない）と、予備のオプションに巻き込まれ、代替案。
問題＃2は、ボイラープレートコードに関するものです...まあ、Reactは薄いライブラリです-そのため、美しく、簡単で、厳密です。 私たちの生活を簡素化し、毎日書くコードの量を減らすラッパーを作りたいのなら、それをやってみませんか？ react依存する独自のnpmとして公開すれば、完了です。

「ライフサイクルメソッドが多すぎる」に関しては、技術的な必要がない新しいコールバックの要求を停止した場合、まだ、そしてこれからもそうなることはありません。 技術的な必要性は、複雑なコンポーネントを実装するときに、作業の途中で、醜いハックなしにそれを実行することです。 これは、「トリッキーなDOMメソッドをトリガーするには、コンポーネントがXを実行するときに呼び出されるものが必要ですが、そのようなメソッドがなく、追加できないため、setTimeoutを使用し、必要以上に早く着陸しないことを願っています」ということです。 「ああ、私は小道具= this.propsを書くのに飽きた」と言うときではありません。

後もう一つ...
適切に設計されたReactアプリケーションでは、ここで説明するほとんどのメソッドは必要ないか、ほとんど使用しません。 getInitialState 、 componentWillMount 、 componentWillUnmount 99％の確率で十分です。 比較的大規模な商用アプリである私の現在のプロジェクトでは、 componentWillReceivePropsがすべてのアプリで2回使用されています。 私はそれをまったく使用しませんが、環境（ブラウザの読み取り）は不完全です- scrollTopなどの特定の「ステートフル・イン・セルフ」のものを操作したり、将来のrenderのレイアウト計算に依存したりしますprops遷移とDOM変更の間で手動で同期する必要があります。 ただし、ほとんどの「通常の」ケースでは、 props遷移がいつ発生するかを知る必要はありません。

@ me-andre Reactでの私の経験に基づいて、APIを改善/簡素化する余地があると思います。 私だけではないので、この問題はそもそも提起され、+ 1されています。

私があなたの分析についてフィードバックを提供することによって答えるならば、それは現状に少し偏っており、現在のAPIを正当化するので、これが実際に前進するとは思わない（それが私がこれまでそれを避けた理由である）が、考えられる解決策についてフィードバックを提供させていただきます。 この問題に携わっている人々は、Reactの使用経験を通じて提起された問題に対処するための改善のアイデアと潜在的なAPIの変更を模索しています（上記で概説したように）。

コミュニティがAPIを前進させるためにイノベーションを行い、それをコアにロールバックするか、現在のAPIがそのまま完璧であるかもしれないというのは正しいかもしれませんが、これは変更がどのように見えるかを検討する絶好の機会だと思いますReactチーム。

おそらく、あなたがそのまま議論をしている理由は、私たちがライブラリのユーザーであり、現在のAPIとそれに行われた決定についての理解が浅いためです。 おそらく、自分と同じように経験と知識を持っている他のReactチームのメンバーを引き込んで、私たちが別の視点を得るかどうかを確認し、優れた解決策を考え出すか、これが最高であるというコンセンサスを得ることができますか？

@ kmalakoff 、Reactがエンジンと4つの車輪であると想像してください。 今、あなたがどこかに行きたいと思うたびに、あなたは車の残りを作ります、そしてそれは結局迷惑になり始めます。 そうでなければ、あなたは低レベルのエンジンの詳細を覚えておく必要があると不平を言い、手で前輪を回すのは正しい方法を感じません。
私がお勧めするのは、完全な車両（本格的なフレームワーク）を入手するか、必要なコンポーネントを長期にわたって再利用できるように構築することです。
このスレッドで私が見ているのは、エンジンに油圧システムと室内灯がないことを訴えるエンジンユーザーです。 私が感じているのは、これらの機能をそれらが属していない場所に追加すると、完全にがらくたになるということです。
Reactはフレームワークではありません。それは、強力なコンポーネントシステムを公開するdiffを利用したレンダリングエンジンです。 低レベルでミニマルなAPIを備えていますが、その上に文字通り何でも構築できるほど強力です。
何かを明確にする必要があると思われる場合は、遠慮なくメールで私に連絡してください。このスレッドをチュートリアルにしたくありません。

@ me-andre私たちはあなたの立場とあなたの議論の線を今よく理解していると信じています。 ありがとうございました！ APIがすでに十分に優れていることは正しいかもしれませんが、改善できる可能性もあります。

誰かがAPIを変更することを主張できますか？ 例えば。 さまざまなオプションの比較分析を提供します（componentDidReceivePropsの追加とAPIのマージ/簡素化と変更なし）

Reactチームはこの問題を監視しており、社内で話し合っています。 原則として、私は常にAPIの表面積を排除することに傾倒しているので、@ me-andreの議論に傾倒しています。 しかし、私たちのチームは時々愛情を込めてcomponentDidReceivePropsを「ミッシングライフサイクルメソッド」と呼んでおり、それを追加する可能性について真剣な議論があります。 重要なことは、悪い慣行を触媒することなく、ベストプラクティスを可能にすることです。

私たち（または少なくとも私）にとって最も役立つのは、なぜ人々がこのライフサイクル方式を望んでいるのかをしっかりと理解することです。 他のライフサイクル方法では十分にカバーされていないこのライフサイクルで何をしようとしていますか？ https://github.com/facebook/react/issues/3279#issuecomment -163875454で提案されているように、レンダリング内でcomponentDidReceivePropsなくUserActions.load(id);を実行したいのはなぜですか（私は考えることができます）理由がありますが、私はあなたの理由が何であるか興味があります）？ 小道具に基づいてデータロードを開始する以外のユースケースはありますか？

@jimfb componentDidReceivePropsはまさに私が必要としているものであり、他の方法は不適切であると私は信じていますが、私は間違っている可能性があります。 私のユースケースを喜んで説明します。

react-routerに次のようなルートがあります。

    <Route path="/profile/:username" component={ProfilePage} />

プロファイルのデータを外部ソースからフェッチする必要があります。これを適切に行うには、 componentDidMountメソッドでHTTPリクエストを行う必要があります。

残念ながら、あるプロファイルから別のプロファイルに移動するとき、React RouterはコンストラクターメソッドまたはcomponentDidMountメソッドを再度呼び出しません（もちろんこれはバグである可能性がありますが、今のところそうではないと仮定します） 。

理論上のcomponentDidReceivePropsを使用してこれを修正することを考えました。 残念ながら、それはまだ存在しておらず、 componentWillReceivePropsは私のニーズに応えられません。

これに関するポインタは大歓迎です。

私の勘は、 componentDidReceivePropsがまさに私が必要としているものだということです。

@ shea256 componentWillReceivePropsがニーズに合わない理由を詳しく説明していただけますか？

@ shea256また、コンポーネントがHTTPリクエストを行う必要があるのはなぜですか？ そのhttpリクエストには何が含まれていますか？ データの場合、データコールバックが戻ったときにコンポーネントを非同期に更新しないのはなぜですか？

@jimfb私にとって一般的なケースは、小道具の変更に応じて非同期で何かをロードする必要がある場合です。これには、ロードが行われていることを示す状態を設定してから、データがロードされたときにその状態を設定することが含まれます。

新しい小道具の取り付けと受け取りの両方で、この同じ読み込みサイクルがトリガーされるはずなので、 componentDidMountとcomponentWillReceivePropsが更新関数を呼び出す場所です。 renderは、それが新しい小道具であるかどうかに関する情報がありません。とにかく、レンダリングからのsetStateはノーノーです。

だから、私はロードを行う1つの関数を持っています。 しかし、私はに渡す必要がpropsパラメータとして、慎重に使用しないようthis.propsのために古くなっているcomponentWillReceiveProps 。 これは必然的にバグを引き起こすことになります。渡された小道具を使用することを忘れないでください。そうしないと、変更が到着したときに微妙な1つの背後にあるエラーが発生します。 また、小道具を渡す必要があるため、関連するすべてのメソッドの署名はより複雑になります。

はい、現在のAPIで実行できます。 しかし、それは、Reactが一般的に回避するのに非常に優れているものである、より不器用でエラーが発生しやすいコードを引き起こします。

@jimfb routeParam新しいユーザー名を取得する必要がありますが、 componentWillReceivePropsではまだ取得していません。

外部ソースからプロファイルデータをロードするためにHTTPリクエストを行う必要があります（データはローカルに保存されません）。

そして、renderメソッドでコンポーネントを更新できますが、少し汚れているように感じます。

constructor(props) {
  super(props)

  this.state = {
    id: this.props.routeParams.id,
    profile: {}
  }
}

componentDidMount() {
  this.getProfile(this.state.id)
}

render() {
  if (this.props.routeParams.id !== this.state.id) {
    this.getProfile(this.props.routeParams.id)
  }

  return (
    <div>
      <div className="name">
       {this.state.profile.name}
      </div>
    </div>
  )
}

@grassickは書いた：

私の一般的なケースは、小道具の変更に応じて非同期で何かをロードする必要がある場合です。これには、ロードが行われていることを示す状態を設定してから、データがロードされたときにその状態を設定することが含まれます。

はい、これはまさに私のユースケースです。

新しい小道具の取り付けと受け取りの両方で、この同じ読み込みサイクルがトリガーされるはずなので、componentDidMountとcomponentWillReceivePropsが更新関数を呼び出す場所です。

よく言われます。

@ shea256代わりにcomponentWillReceivePropsを使用してこれを行うことはできませんか？

constructor(props) {
  super(props)

  this.state = {
    id: this.props.routeParams.id,
    profile: {}
  }
}

componentDidMount() {
  this.getProfile(this.state.id)
}

componentWillReceiveProps(nextProps) {
  let { id } = nextProps.params
  if(id !== this.state.id) {
    this.getProfile(id, (profile) => {
      this.setState({ id: id, profile: profile })
    })
  }
}

render() {
  return (
    <div>
      <div className="name">
       {this.state.profile.name}
      </div>
    </div>
  )
}

@grassickは書いた：

私の一般的なケースは、小道具の変更に応じて非同期で何かをロードする必要がある場合です。これには、ロードが行われていることを示す状態を設定してから、データがロードされたときにその状態を設定することが含まれます。

@grassickは書いた：

レンダーには、それが新しい小道具であるかどうかに関する情報がありません。とにかく、レンダーからのsetStateはノーノーです。

ここで唾を吐くだけです： componentDidUpdateが（後続のレンダリングに加えて）最初のレンダリングで呼び出された場合、それはあなたのユースケースを解決しますか？ 小道具が変更されたかどうかを確認し、すべてのデータをcomponentDidUpdateにロードできますか？ また、レンダリングでは、 this.state.profileName != this.props.profileName場合、データをロードしていることがわかります。 その代替案はあなたのユースケースに十分でしょうか？

小道具に基づいてデータをロードするコンポーネントを含まない、人々が持っているユースケースはありますか？

@calmdev hm、私はあなたが正しいと信じています。 やってみます。

@jimfbかもしれませんが、 componentDidUpdateを使ってみたところ、うまくいかないと思いました。 もう一度見てみましょう。

そして、私は完全にthis.state.profileName != this.props.profileNameチェックできるように思えますが、これもハックのようですよね？ この時点で、 componentWillReceiveProps(nextProps)が機能するようになった場合は、それをお勧めします。 さて、私を悩ませているのは、 componentDidMountとの対称性の欠如です。 componentDidMount代わりにcomponentWillMountを使用できますか？

ライフサイクル全体がもっときれいになりそうな気がします。

@ shea256 、質問があります... ReactのREADMEを読んだことがありますか？
私はそれを言うのは気が進まないが、そうでなければ、あなたが慣れていないツールの新機能を要求するべきではないかもしれない。 私にとって、それも聞こえます...ばかげています。
「 componentDidMount代わりにcomponentWillMountを使用できますか？」
あなたは、それはREADMEに記載されているだとしてので、することはできませんノーcomponentWillMount 、あなたのコンポーネントがDOMに取得し、前に呼び出されるcomponentDidMountその後- 。 まあ、あなたは間違いなくあるメソッドを別のメソッドに置き換えることができます、そしてそれはあなたのコードを壊すでしょう。 ここに2つの方法がある理由は、美学ではありません（「対称性」を読んでください）。 これは、レンダリングする前に準備を行うためのメソッドと、最初のレンダリング後の最初のDOMクエリ/操作のためのメソッドが必要になる場合があるためです。 しかし、それでも平均的なReactコンポーネントにとってはエキゾチックです。 通常、DOMに手動でアクセスする必要はありません。
「そして、this.state.profileName！= this.props.profileNameを完全にチェックできるように思えますが、これもハックのようですよね？」
はい、あなたのアプローチ全体はハックです。 そして、 componentDidReceivePropsがpropsが変更されたことを保証すると誰が言ったのですか？ shouldComponentUpdateを定義しない限り、これを行うことはできません。
これがReactの仕組みです。

@ me-andre飛び込んでくれてありがとう、でもあなたは私の好みには少し研ぎ澄まされすぎています。 また、あなたが私の質問を理解したとは思わない。 私はcomponentWillMountとcomponentDidMountが何をするのかよく知っています。 @jimfbの応答を待ちます。

@ shea256 、
「また、あなたが私の質問を理解したとは思わない。」
私があなたの質問に答えるとき、私がポイントを逃したところを指摘していただけませんか？
また、あなたが何を求めているのかを明確にしていただけませんか。
また、私たちは性格や好みについて話し合うためにここにいるわけではありません。 これは個人的な話ではなく、技術サポートでもありません。 これは、知識のある領域を案内することを期待できるスタック交換Webサイトでさえありません。
私は地元の交流会や国際会議でReactについて（そしてそれだけでなく）頻繁に話しますが、適切な時期と場所で知識を共有することに非常にオープンです。 あなたはいつでも電子メールまたはスカイプを介して直接私に連絡することができます。

プロファイルデータの読み込みに関する問題について。 あなたは、機能指向のフレームワークに古典的な命令型アプローチを適用するという問題を解決しようとしています。 Reactのビューは、小道具、状態、環境の関数です。 function(state, props) { return // whatever you've computed from it } （しかし、現実の世界では物事は少し複雑になります-そうでなければ、Reactはまったく存在しません）。 0.14には純粋関数型コンポーネントがありますが、ほとんどのコンポーネントでは、このエントリ関数はrender()です。

これは、 render()から書き始め、小道具が常に最新であり、 propsが変更されたかどうか、何回、どこで変更されたかを気にしないことを意味します。 ケースは次の方法で実装できます。

// profile-view.js

var React = require('react');

module.exports = React.createClass({
    contextTypes: {
        app: React.PropTypes.object.isRequired
        // another option is var app = require('app')
        // or even var profiles = require('stores/profiles')
    },
    componentWillMount() {
        var {app} = this.context; // another option is to require('app')
        app.profiles.addListener('change', this.onStoreChange);
    },
    componentWillUnmount() {
        var {app} = this.context; // another option is to require('app')
        app.profiles.removeChangeListener('change', this.onStoreChange);
    },
    onStoreChange() {
        this.forceUpdate();
    },
    render() {
        var {app} = this.context;
        var profile = app.profiles.read(this.props.routeParams.id);
        if (profile) { // profile's been loaded
            return <div>{profile.name}</div>;
        } else { // not yet
            return <div>Loading...</div>;
        }
    }
});

// profiles-store.js
// app.profiles = new Profiles() on app initialization

var EventEmitter = require('events');
var {inherits} = require('util');

module.exports = Profiles;

function Profiles() {
    this.profiles = {};
}

inherits(Profiles, EventEmitter);

Profiles.prototype.read = function(id) {
    var profile = this.profiles[id];
    if (!profile) {
        $.get(`profiles/${id}`).then(profile => {
            this.profiles[id] = profile;
            this.emit('change');
        });
    }
    return profile;
};

ものすごく単純。
そして、あなたはcomponentDidReceiveProps必要としません。 componentWillReceivePropsや同様のフックも必要ありません。 些細なケースでそれらが必要だと感じた場合は、Reactで物事を行う方法についての理解が不足しています。 それを取得するには、リポジトリの問題セクションをゴミ箱に捨てるだけでなく、適切なリソースを使用して

@ me-andreあなたが助けようとしているだけなのに、少し対立するように出くわす可能性があるので、おそらくあなたの言語を少しトーンダウンする価値があります。 私たちは、誰もが楽しめるコミュニティを作りたいと思っています。 私たちは皆、ある時点で初心者でした。 API /デザインに関するいくつかのポイントについては正しいですが、非常に多くの人が問題を+1しているという事実は、何かが間違っていることを示しているので、人々がこれを望んでいる理由/理由を理解するように努める必要がありますライフサイクル。 おそらく問題は、コンポーネント（ドキュメント）を適切に作成する方法を十分に伝えていないこと、またはReactのAPIを変更する必要があることです-いずれにしても、ここで苦情/質問/コメントを理解する価値があります。

@ shea256 this.state.profileName != this.props.profileNameは、内部状態（コンポーネントがレンダリングしているもの）が、親がコンポーネントにレンダリングを要求しているものと一致するかどうかを確認しています。 これはほとんど「コンポーネントが更新されている」または「コンポーネントが最新である」の定義であるため、ハッキーとは見なされません。 少なくとも、「小道具が変更されたときにデータ更新リクエストを起動し、コールバックでsetstateを実行する」という考えほど、ハッキーなものはありません。

@ shea256明確にするために、この提案されたライフサイクルでは、現在のライフサイクルでは今日すでに実行できなかったことを実行できません。 それは単にそれを潜在的により便利にするだけです。 他の人が述べているように、あなたがやろうとしていることは現在のライフサイクルで可能です（あなたがあなたの目標を達成することを可能にするライフサイクルの複数の組み合わせがあります）。 あなたが「それを機能させる」ことを試みているなら、StackOverflowは議論するのに良い場所でしょう。 このgithubの問題は、開発者の人間工学に関連するcomponentDidReceivePropsの必要性を理解しようとしています。

そして、componentDidReceivePropsが小道具が変更されたことを保証すると誰があなたに言いましたか？

@ me-andreはここで正しいです。 ほとんどのライフサイクルメソッドは、実際に何かが変更されたことを保証するものではありません。 それらは、何かが変更された可能性があることを示すだけです。 このため、httpリクエストを行うなどの操作を行う場合は、常にprevious === nextかどうかを確認する必要があります。 このスレッドの多くの人々は、ライフサイクルメソッドが実行されたという理由だけで彼らの価値が変わったと仮定しているようです。

@ me-andreは書いた：

あなたは、機能指向のフレームワークに古典的な命令型アプローチを適用するという問題を解決しようとしています。

これがこの新しいライフサイクル方法を望んでいる人々の根本的な原因かもしれないと思いますが、私はまだ人々がこの方法を使用したい理由/方法を理解しようとしています。 現在のライフサイクルのセマンティクスが、人々が一般的にやりたいこととわずかに一致していない可能性は十分にあります。

すべて：「小道具の変更に応じてデータを非同期にロードする」以外に、 componentDidReceivePropsのユースケースはありますか？

cc @grassick @iammerrick

@jimfbコードを検索し、 componentWillReceivePropsを使用して、レンダリングに必要な作成コストの高いオブジェクトを作成しました。 この場合は、小道具を渡さなければならないのと同じ問題があり、コードでthis.propsを使用しないように注意してください。

@jimfbは書いた：

@ me-andreあなたが助けようとしているだけなのに、少し対立するように出くわす可能性があるので、おそらくあなたの言語を少しトーンダウンする価値があります。 私たちは、誰もが楽しめるコミュニティを作りたいと思っています。 私たちは皆、ある時点で初心者でした。 API /デザインに関するいくつかのポイントについては正しいですが、非常に多くの人が問題を+1しているという事実は、何かが間違っていることを示しているので、人々がこれを望んでいる理由/理由を理解するように努める必要がありますライフサイクル。 おそらく問題は、コンポーネント（ドキュメント）を適切に作成する方法を十分に伝えていないこと、またはReactのAPIを変更する必要があることです-いずれにしても、ここで苦情/質問/コメントを理解する価値があります。

これに言及していただきありがとうございます。 あなたが歓迎のコミュニティを持っていることを確認することは非常に重要です、そしてあなたとの私のコミュニケーションはただ楽しいものでした。

@jimfbは書いた：

@ shea256 this.state.profileName！= this.props.profileNameは、内部状態（コンポーネントがレンダリングしているもの）が、親がコンポーネントにレンダリングを要求しているものと一致するかどうかを確認しています。 これはほとんど「コンポーネントが更新されている」または「コンポーネントが最新である」の定義であるため、ハッキーとは見なされません。 少なくとも、「小道具が変更されたときにデータ更新リクエストを起動し、コールバックでsetstateを実行する」という考えほど、ハッキーなものはありません。

はい、これは合理的なようです。

@jimfbは書いた：

@ shea256明確にするために、この提案されたライフサイクルでは、現在のライフサイクルでは今日すでに実行できなかったことを実行できません。 それは単にそれを潜在的により便利にするだけです。 他の人が述べているように、あなたがやろうとしていることは現在のライフサイクルで可能です（あなたがあなたの目標を達成することを可能にするライフサイクルの複数の組み合わせがあります）。 あなたが「それを機能させる」ことを試みているなら、StackOverflowは議論するのに良い場所でしょう。 このgithubの問題は、開発者の人間工学に関連するcomponentDidReceivePropsの必要性を理解しようとしています。

私はこれに非常に同意します。 特定のユースケースを投稿して、ヘルプを受け取ることはしませんでした。 componentDidReceivePropsが役立つと思った理由についての洞察を提供するために投稿しました。

私と投稿した他の12人以上の人々は、明らかにこのようなものを使用する本能を持っていました（つまり、数百または数千以上ある可能性があります）。これは、APIがそれほど直感的ではないことを示しています。

@jimfbは書いた：

@ me-andreはここで正しいです。 ほとんどのライフサイクルメソッドは、実際に何かが変更されたことを保証するものではありません。 それらは、何かが変更された可能性があることを示すだけです。 このため、httpリクエストを行うなどの操作を行う場合は、前の===次の場合を常に確認する必要があります。 このスレッドの多くの人々は、ライフサイクルメソッドが実行されたという理由だけで彼らの価値が変わったと仮定しているようです。

私はこの仮定をしていません。 小切手を省略しましたが、現在使用しています。 ただし、最悪の場合、追加の要求がトリガーされます。

@jimfbは書いた：

これがこの新しいライフサイクル方法を望んでいる人々の根本的な原因かもしれないと思いますが、私はまだ人々がこの方法を使用したい理由/方法を理解しようとしています。 現在のライフサイクルのセマンティクスが、人々が一般的にやりたいこととわずかに一致していない可能性は十分にあります。

多分。 これについてもっと考えます。

componentDidReceivePropsは、私が持っている特定のユースケースに役立ちます。

ReactRouterとFluxアーキテクチャを使用しています。 コンポーネントがインスタンス化されると、状態をストアのアイテムに設定します。 そのストアが変更イベントを発行すると、同じ取得クエリを使用して状態を更新します。

同じルートで別のアイテムIDに移動したために小道具が変更された場合、ストアに再度クエリを実行する必要があります。そうしないと、コンポーネントがストア内の前のアイテムの状態でスタックします。

現在、 componentWillReceivePropsが呼び出されると、ルートパラメータのいずれかが変更されたかどうかを確認し、変更された場合はupdateItemStateを呼び出します。 しかし、小道具は実際にはまだ変更されていないため、今度は小道具をメソッドに渡す必要があります。

this.updateItemState( nextProps );

updateItemState( props ) {
    props = props || this.props;

    this.setState( {
        item: this.getItemState( props )
    } );
}

getItemState( props ) {
    props = props || this.props;

    return this.ItemStore.get( props.params[ this.paramName ] );
}

単になります

this.updateItemState();

updateItemState() {
    this.setState( {
        item: this.getItemState()
    } );
}

getItemState() {
    return this.ItemStore.get( this.props.params[ this.paramName ] );
}

これは妥当なユースケースだと思います。

@ akinnee-gl et al：更新に加えて最初のマウント後にcomponentDidUpdateが起動された場合、それはあなたのユースケースを解決しますか？

@ akinnee-gl、Fluxを使用している場合は、ストアから状態を設定する必要はありません。 それが絶対に不可能でない限り、あなたは一箇所で状態を維持するべきです。 フラックスに関して言えば、その場所は店そのものです。 ストアが変更を発行するときは、 forceUpdate()だけで、 render()でread()ます。

「同じルートで別のアイテムIDに移動したために小道具が変更された場合、ストアに再度クエリを実行する必要があります。そうしないと、コンポーネントがストア内の前のアイテムの状態でスタックします。」

一度もない。

見てみましょう：ストアから特定のアイテムをレンダリングする必要があり、レンダリングするアイテムをpropsから決定します。 それが要件である場合は、単語と同じ方法でコードで表現する必要があります。

    var item = this.props.store.read(this.props.id);
    return <div>{item.name}</div>;

これはあなたのコンポーネントであり、それ以上のものではありません。
Fluxでこれを再生するために、ストアのバインド/バインド解除用の再利用可能なコンポーネントを作成できます。

<FluxWrapper store={store} component={Component} id={this.props.routeParams.id} />

var FluxWrapper = React.createClass({
    componentWillMount() {
        this.props.store.addListener('change', this.onStoreChange);
    },
    componentWillUnmount() {
        this.props.store.removeListener('change', this.onStoreChange);
    },
    onStoreChange() {
        this.forceUpdate();
    },
    render() {
        var Component = this.props.component;
        return <Component {...this.props} />;
    }
});

var Component = React.createClass({
    render() {
        var item = this.props.store.read(this.props.id);
        return <div>{item.name}</div>;
    }
});

Reactを適切に使用すると、コンポーネントがどれほど小さくなるかを確認してください。

ただし、ストアが重く、 render()ごとにread()だけではできない場合は、キャッシュミドルウェアが必要です。 これは、再利用可能なコンポーネント（ FluxWrapperと同様）、または元のread()メソッドをシャドウアウトする中間プロキシストアのいずれかです。 プロキシストアは簡単でかっこいいです。親ストアの変更が重要でない場合や重要でない場合は、読み取りをキャッシュするだけでなく、変更を抑制することもできます。
これを作曲といいます。 コンポジションはスケーリングするため、継承や拡張機能などよりもコンポジションを優先する必要があります。
1つのコンポーネントを使用しても解決が難しい問題が発生したら、既存のコンポーネントを複雑にするのではなく、2つ以上のコンポーネントを使用することを検討してください。

@jimfb 、私の口調に関して：私は英語を母国語としないし、定期的に話す練習もしていないので、間違った単語を選ぶことがあります-感情的に聞こえるのが感じられないだけです。

興味深いアプローチ。 私はそれを心に留めておきます。 Reactの公式ドキュメントはすべて、レンダリング関数を純粋に保つように言っています（つまり、レンダリングメソッドの小道具と状態にのみアクセスする必要があります）。 すべてのFluxの例は、ストアからの設定状態を示しています。

@jimfb componentDidUpdateの問題は、小道具の変更以外の理由で呼び出されることです。 また、コンポーネントがすでに更新されるまで待ってから、setStateを呼び出して再度更新する必要があります。 かなり非効率的なようです。

@ akinnee-gl componentWillReceivePropsは、小道具の変更以外の理由で呼び出されることもあるため（https://github.com/facebook/react/issues/3279#issuecomment-164713518を参照）、確認する必要があります。とにかく小道具が実際に変更された場合（選択したライフサイクルに関係なく）。 また、実際に非同期データを実行している場合は、コールバックが発生する前に次のイベントループを待機することになります。したがって、関数がの直前/直後に呼び出されても問題ないと思います。レンダリング機能ですね。

@jimfb実際、小道具が参照しているアイテムがすでにストアにある場合は、再度レンダリングする必要はありません。 まだストアにない場合は、ロード画面を表示することをお勧めします。 したがって、2回レンダリングしても意味がありません。 でもあなたの言っていることがわかります。

@ me-andreレンダリング中にストアから読み取るだけのアプローチが本当に好きです。 それはコードを単純化するようです。 しかし、そうすることで効率がいくらか失われるのではないかと心配しています。 shouldComponentUpdateを介して更新を制御する機能が失われ、前述のFluxWrapperコンポーネントを追加する必要があります。 それについて何か考えはありますか？

私は議論を監視してきましたが、3番目のオプションを再検討したいと思います：（1）APIはそのままで素晴らしい、（2）componentDidReceivePropsが必要、（3）もっと単純なAPIがあるかもしれません。

私はこの問題を、議論を（1）と（2）のソリューション空間に限定するのではなく、APIのより深い変更をブレインストーミングすることによって、この問題によって提起された根本的なニーズを解決できるかどうかを確認する機会と見なしています。

簡略化されたAPIは、次の原則に基づくことができます。

（A）コード構造を簡素化/定型文を減らす
（B）小道具（入力）を状態（内部）から分離しておく

（A）の主な理由は、私が付加価値のない定型文を書いていることに気付いたからです。 例：

componentWillMount() { this.actuallyCheckThePropsAndMaybeDoSomething(); }
componentWillReceiveProps(nextProps) { this.actuallyCheckThePropsAndMaybeDoSomething(nextProps); }

actuallyCheckThePropsAndMaybeDoSomething(props) {
  props = props || this.props;

  let relatedProps1 = _.pick(props, KEYS1);
  if (!shallowEqual(this.relatedProps1, relatedProps1) { // changed
   this.relatedProps1 = relatedProps1;

   // do something
  }

  let relatedProps2 = _.pick(props, KEYS2);
  if (!shallowEqual(this.relatedProps1, relatedProps2) { // changed
   this.relatedProps2 = relatedProps2;

   // do something else
  }
}

私は実際にはむしろ次のことを行い、初めて対変更された別個のコードパスを持たないことを望みます：

propsUpdated(prevProps) {
  if (!shallowEqual(_.pick(prevProps || {}, KEYS1), _.pick(this.props, KEYS1)) { // changed
   // do something
  }

  if (!shallowEqual(_.pick(prevProps || {}, KEYS2), _.pick(this.props, KEYS2)) { // changed
   // do something
  }
}

（B）に関しては、componentDidUpdateの主な問題は、前述のように、プロパティの変更による状態を設定すると、props（入力）と（内部）状態の両方で呼び出されるため、メソッド呼び出しを繰り返すことができることです。 これらのコードパスは、小道具が外部から供給され、状態が内部で設定されるため、分離されている方が良いようです。 componentDidUpdateを使用して定型文を減らすupdated(prevProps, prevState) （ライフサイクルメソッドが少ないと命名を短くできるため、componentDidUpdateの簡略化された名前）の4番目の可能性を試しましたが、冗長な2番目の可能性に少し不満があります。更新呼び出しと、ロジックは実際には完全に独立しているようです。

設計原則から始めることに基づいて（もっとあると確信しています！）、 propsUpdatedとstateUpdated沿った何かが、この議論の潜在的な3番目のオプションになるのではないかと思います。 ？

@kmalakoff小道具が変更されたかどうかを常に確認する必要があります。これは、小道具が変更された/変更されなかったことを明確に伝えることができないためです（Javascriptには値型がなく、可変性があるため）。

その点で、おそらく、shouldComponentUpdateを呼び出して、propsDidChangeなどを呼び出す必要があるかどうかを判断できます。 ただし、別の問題。

@jimfbは、参照している言語の制限と、それが一般的なAPIの簡素化にどのように関連しているかを正確に

彼は、 this.props === nextPropsが2つの別個のオブジェクトである場合とそうでない場合があるため、

{ a: 1 } === { a: 1 }は、2つの別個のオブジェクトであるため、falseになりますが、

var a = { a: 1 };
var b = a;
a === b

これらは実際には両方とも同じオブジェクトへの参照であるため、trueが生成されます。

各プロパティが等しいかどうかを再帰的にチェックすることはできますが、それはかなり遅くなる可能性があります。 そのため、 shouldComponentUpdateを実装するのは私たち次第です。

@kmalakoffこのスレッドをhttps ： //gist.github.com/jimfb/9ef9b46741efbb949744

TLDR：@ akinnee-glは彼の説明で正確に正しいです（ありがとう！）。 小道具として渡されたコールバック関数を再帰的にチェックする方法がないため、とにかく再帰的チェックを常に実行できるとは限らないというマイナーな修正があります（必要な場合でも、パフォーマンスは問題ではありませんでした）。

：Pですが、このスレッドをトピックに留めておきましょう。

あなたがた両方に感謝します！ うーん、APIを単純化することがこの問題を解決するためのオプションではない理由についてはまだ完全には明確ではありません。 要旨にコメントを追加します...

より幅広いソリューションに参加したい方は、ぜひご参加ください。

@jimfb @calmdev私はあなたの提案を試しましたが、 componentDidReceivePropsが実際には何も新しいものを追加せず、追加関数として追加すべきではない理由を完全に理解しました。 私は以前にあなたの言葉を信頼していましたが、今ではなぜそうなるのかが直感的に理解できます。

私がこのことに気付いた経緯を説明するために、最新のコードを共有したいと思います。 おそらくこれは他の人にも役立つでしょう。

私のプロフィールページコンポーネントを見てください：

class ProfilePage extends Component {
  static propTypes = {
    fetchCurrentProfile: PropTypes.func.isRequired,
    currentProfile: PropTypes.object.isRequired
  }

  constructor(props) {
    super(props)
    this.state = { currentProfile: {} }
  }

  componentHasNewRouteParams(routeParams) {
    this.props.fetchCurrentProfile(routeParams.id)
  }

  componentWillMount() {
    this.componentHasNewRouteParams(this.props.routeParams)
  }

  componentWillReceiveProps(nextProps) {
    if (nextProps.routeParams.id !== this.props.routeParams.id) {
      this.componentHasNewRouteParams(nextProps.routeParams)
    }
    this.setState({
      currentProfile: nextProps.currentProfile
    })
  }

  render() {
    var profile = this.state.currentProfile
    return (
      <div>
        <h1>{ profile.name ? profile.name : null }</h1>
      </div>
    )
  }
}

コンポーネントがマウントされると、プロファイルデータがないため、外部ソースからプロファイルをロードする必要があります。

つまり...外部ソースからデータをフェッチするfetchCurrentProfile関数（ componentHasNewIdPropラップされている）を呼び出してから、更新アクションをReduxにディスパッチします。 レデューサーはこのアクションを受け取り、アプリケーションの状態を更新します。次に、アプリケーションの状態がProfilePageコンポーネントの小道具を更新します。

これで、小道具が更新されたため、 componentWillReceiveProps関数が呼び出されます。 ただし、小道具変更イベントのコンテキストがわからないため、どの小道具（ある場合）が変更されたかを把握する必要があります。 IDが同じであることがわかるので、 fetchCurrentProfile再度呼び出す必要はありません。 その後、我々は更新state.currentProfileコンポーネントが新しいプロファイルデータを再描画するために知っている（はい、私は小道具でこれを行うことができますが、私はここに行きたくないのはこのための別の理由があります）だから。 現時点では、状態を更新する前にprops.currentProfileが変更されているかどうかを確認できますが、これはコストのかかる操作ではないため、確認してもかまいません。

次に...あるプロファイルから別のプロファイルに移動するとします。 リンクをクリックすると、ルーターがルート変更をトリガーします。 これで新しいルートパラメータができ、 componentWillReceiveProps関数がトリガーされます。 idが変更されたことがわかったので、もう一度fetchCurrentProfileを呼び出します（ componentHasNewIdProp経由）。

新しいフェッチが戻ってreduxアクションをディスパッチすると、 currentProfileプロップが再度更新され、状態が更新され、コンポーネントが新しいビューで再レンダリングされます。

この例は、コンポーネントがマウントされるときと、コンポーネントが新しい小道具を受け取るときに、どのように異なる動作が必要かを示しています。 また、後者の場合に小道具の変更をチェックする方法と、特定の小道具の変更時にのみ特定の関数を呼び出す方法についても説明します。

振り返ってみると、本質的に私が欲しかったのは、 routeParams変更されたときにのみ更新される関数

ただし、ここで役立つ可能性があるのは、ライフサイクルや実際の例などに関するドキュメントです。

助けてくれてありがとう。 ここで何か問題があった場合はお知らせください。 これが将来このスレッドに出くわした人に役立つことを願っています。

@ shea256あなたの例は、新しいAPIの観点なしに必要なことを達成できるという点で、新しいAPIを必要としない合理的なケースのようです。

https://gist.github.com/jimfb/9ef9b46741efbb949744でより多くの考えを概説しましたが、それでもAPIを合理化してコードの記述を減らすことができるはずだと感じています...

APIを使用して同じ機能を記述できるが、定型文が少ないと想像してみてください。

class ProfilePage extends Component {
  static propTypes = {
    fetchCurrentProfile: PropTypes.func.isRequired,
    currentProfile: PropTypes.object.isRequired
  }
  state = {currentProfile: {}}; // not material to example (babel-stage-1)

  // called both on init and update
  willReceiveProps(nextProps) {
    if (!this.props || (this.props.routeParams.id !== nextProps.routeParams.id)
      nextProps.fetchCurrentProfile(nextProps.routeParams.id)
  }

  render() {
    var profile = this.props.currentProfile;
    return (
      <div>
        <h1>{ profile.name ? profile.name : null }</h1>
      </div>
    )
  }
}

私が検討したいと思っているのは、APIの表面積を減らして、コードパスとボイラープレートの数を減らすことです。 別の視点から見ると新しい道が開かれるかもしれないのに、何かを追加するという最初の要求に議論が固定されているのではないかと思います。

これは1つのオプションにすぎません（理想的には、this.propsを使用できるprop関連のメソッドは1つしかないため、私の好みはreceivedProps（prevProps）です）が、重要な部分は、初期化のためのコードパスが1つしかないことです。さまざまなAPIシグネチャを使用して現在使用しているさまざまなコードパスではなく、コンポーネントと小道具の変更。 人々がより良いことに同意する解決策は何でも。

ボイラープレートを減らすことは、この問題が達成できることを望んでいます（私のニーズ/問題を明確にするために！）そして、そのソリューションがどのように見えるかについてもう少し広くブレインストーミングしたいと思います（APIを削除し、 ES6が広く利用可能になり、コンポーネントが前進しているように見えるようになったため、ライフサイクルメソッドが大幅に短縮され、メソッド名が短縮されました。

@ akinnee-gl、いくつかの理由から、アプリケーションを多くの小さなコンポーネントで構成する方が、いくつかの重いコンポーネントよりもはるかに優れています。

1. このアプローチは「単一責任の原則」と関連しています
2. どのコンポーネントが何をするのかがはっきりとわかります
3. ラッピングすることで、機能を簡単に構成し、コンポーネントを拡張できます
4. メソッドとプロパティが衝突しない
5. 1つのコンポーネントが1つの機能をカプセル化するため、機能を拡張する方が簡単です。

各レンダリングでストアからの読み取りが非効率的である可能性があるという通知に関して、キャッシュ用のミドルウェアコンポーネントを実装する方法の基本的なアイデアを示す要点を作成しました： https ：

私は、APIの改善につながる可能性のある原則/目標について別のパスを取りました（うまくいけば、この問題で提案されているように、受け取った小道具メソッドに基づいています）：

（A）コード構造を簡素化/定型文を減らす
（B）小道具（入力）を状態（内部）から分離しておく
（C）コンポーネントのレンダリングを制御するメソッドを許可する
（D）コンポーネントのサブクラス化の仮定に基づいてメソッドの命名を簡素化する
（E）初期化と変更の両方でpropsメソッドの数を1つに減らします
（F）propsメソッドには、最新の値を持つthis.propsが必要です。

要旨では、それらのいくつかについて説明があります。

@kmalakoff要点に従って、これらの問題の範囲を拡大しないでください。 この問題はすでに十分に複雑であり、会話を完全なAPIに分割する-再設計は扱いにくいものになるでしょう。 これらの問題について引き続き検討することを歓迎しますが、このスレッドをトピックに留めておいてください。

@kmalakoffあなたが言及しているポイントの多くは、他の問題のトピックです。 たとえば、（D）はhttps://github.com/reactjs/react-future/issues/40#issuecomment-142442124およびhttps://github.com/reactjs/react-future/issues/40#issuecomment-によって回答されます。 153440651。 それらはその議論をするのに適切なスレッドです。 より一般的/全体的な設計/ APIの議論を探している場合、正しい媒体はおそらくhttps://discuss.reactjs.org/です。

@jimfbこれを要点に移すように提案した後、私はこれについていくつか考えましたが、実際にはこの分析ラインがトピックから外れているとは思わない...受け取った小道具に関するこの問題に興味がある理由は、受け取った小道具のライフサイクル方法により、ボイラープレートを減らすことができます。

私の言うことを聞いてください...ボイラープレートを減らすことは、この問題のライフサイクル方法が私のために解決できる問題です。

現在のAPIはボイラープレートを私たちが望む以上に奨励しているため、人々がこのライフサイクルメソッドに興味を持っている理由の重要な部分でもあると思います。

そうは言っても、APIの改善を切り離して、たとえば、この問題の小道具に関連するAPIの改善に関するソリューションスペースの調査にのみ焦点を当てることができれば幸いです。

@kmalakoffスレッドのトピックは、タイトルと最初の投稿によって定義されます。 タイトルはcomponentDidReceiveProps Pleaseではなくlots of general ways to reduce boilerplateです。 このスレッドは、特に非常に具体的なライフサイクル方法の導入を通じてボイラープレートを削減することについてです。 他の問題ですでに議論されている追加のトピック（すべての機能の名前変更など）を導入することなく、その議論だけでもすでに十分に微妙な違いがあります。

あなたのポイントは貴重です。議論をすることをお勧めします。githubスレッドを目前のトピックに集中させたいので、別のスレッドに移動してください。 そうでなければ、議論は追跡/管理するのが難しすぎます。 あなたが提起したほとんどのトピックにはスレッドが存在します。

@jimfbなぜ人々はcomponentDidReceiveProps求めているのですか？ 私がそれに興味を持っている理由は、小道具に関連する定型文を

あなたは問題とユースケースを求めてきました、そして私はこれを私にとっての問題として述べ、上記のユースケース（@ shea256に応答）を示しました。この問題。

私は、一般的なAPIの問題/改善と意志に範囲を拡大することを延期することに同意しました。 約束します！ ：ウィンク：

参考：前に述べたように、この問題に関する思考実験を開始した理由は、議論の焦点が少し狭すぎるように見えたため（たとえば、現在のAPIで必要なすべてをすでに実行できる）、背後にある根本的な動機を特定したためです。問題。 ご存知のように、問題の最善の解決策に向けて繰り返すために、一歩下がってから焦点を合わせ、別の角度から見て、仮定を再検討し、要求の背後にある根本的な理由を調査する必要がある場合があります。 うまくいけば、私はこれに注意を引くのを助けました、そして私の参加はこの問題を私たちの満足に解決するのを助けるでしょう！ （もちろん、React APIが進化してより使いやすくなり、他の場所でもその議論が続くことを願っています...リンクをありがとう）

@kmalakoff 、

@ me-andreは、この問題がAPIの改善につながらない場合、絶対にオプションです。

この問題は、APIを改善するためにAPIに変更を加えたいという願望に関する議論を促進するために提起されました。 クライアントコードの代替案を明確に検討する必要がありますが、APIを変更する必要があるという強い主張がなされた場合、この種の回避策は不要です。 反論するためには、改善されたAPIがどうあるべきかについてもケースを作成し、現在のAPIに対して評価してそれらを評価する必要があります。

たとえば、カスタムスーパークラスを定義せずに現在のAPIを使用して、定型文を減らすことができることを実証する場合（たとえば、APIを誤って使用している、または現在のAPIに使用できる機能がある場合）ボイラープレートの同様のレベルの削減など）、または改善が不可能な理由を証明する（たとえば、API改善オプションでサポートできなかった主要なユースケースがあるため、一般的な解決策が存在しない）など。 APIがそのままで十分な場合。

APIで、基本的および一般的な制御フローパターンのカスタムスーパークラスを作成する必要がある場合、APIを改善する必要があるという議論が強まります。

好奇心が強い-マウントする前にcomponentWillReceivePropsがトリガーされない理由は何ですか？ あなたがそれについて考えるならば、それが初期化されるとき、コンポーネントは実際に小道具を受け取っています。 新しい小道具を受け取っていないだけです。

新しい小道具を受け取ったときだけ（最初の小道具を受け取ったときではなく）何かをトリガーしたいユースケースは何ですか？

私はここで明白な何かを見逃している可能性がありますが、さまざまな関係者の視点を調整しようとしているだけです。

いずれにせよ、場合によってはcomponentWillReceiveNewPropsが重要である場合でも、入ってくる小道具のチェックを実行することで、変更されたcomponentWillReceivePropsそれをシミュレートできます。

@kmalakoff componentWillReceivePropsが最初にトリガーされた場合、それはAPI簡素化の基準を満たしますか？

componentWillReceivePropsがマウント時にトリガーされないのは、人々がcomponentDidReceiveProps要求している理由ではありません。 this.propsにアクセスするためのすべてのメソッドを作成したため、人々はcomponentDidReceivePropsを求めています。 componentWillReceivePropsが呼び出されると、nextPropsが渡されますが、 this.propsはまだ変更されていません。つまり、 componentWillReceivePropsに応答して呼び出されるすべてのメソッドにnextPropsを渡す必要があります。そのままにするのではなく、 componentWillReceiveProps 。 最終的には、大量のprops = props || this.propsと、呼び出すすべての関数に大量のpropsを渡すことになります。

@ shea256良い点。 初期化と変更のコードパスが異なることは、小道具ボイラープレートの根本的な原因の1つです。 もう1つの根本的な原因は、@ akinnee-glが指摘するような小道具を処理するためのさまざまな署名があることです。

これが、プロペラボイラープレートをさらに減らすためのさらに優れたソリューションが実際に存在する可能性があるため、検討中のソリューションスペースを拡張しようとしている理由です（たとえば、initを呼び出す）。

私たちはさらに進むことができることを願っています：

新しいフックの前

componentWillMount() {
  this.setup(this.props.id);
}

componentWillReceiveProps(next) {
  this.setup(next.id);
}

setup(id) {
  UserActions.load(id);
}

新しいフックの後（改訂）

componentDidReceiveProps(prevProps) {
  UserActions.load(this.props.id);
}

または、UserActions.loadが現在ロードされているIDを確認できない場合：

componentDidReceiveProps(prevProps) {
  if (!prevProps || (prevProps.id !== this.props.id))
    UserActions.load(this.props.id);
}

@kmalakoff 、私が話しているのは、APIの改善が今すぐに絶対に利用できるということです。コンポーネントの独自のファクトリを作成して、（ユースケースサンプルとともに）私たちと共有することができます。 これにより、提案と理論的根拠が100倍明確になります。 すべてのライフサイクルポイントにはすでに適切なコールバックがあるため、任意のライフサイクルポイント/コンポーネントの状態で新しいメソッドを導入できます。 イベントエミッターをコンポーネントにミックスインして、状態変更のために複数のハンドラーをアタッチできるようにすることもできます。

@ shea256 、最初のレンダリングの前にcomponentWillReceivePropsがトリガーされない理由のひとつは、その時点でthis.propsのようなものがないことです。 componentWillReceiveProps一般的に行うことは、 this.props[propName]とnewProps[propName]比較することです。 最初のレンダリングの前にメソッドをトリガーすると、 this.props存在も確認する必要があります。 さらに、コンポーネント全体は、最初のレンダリングの前にpropsを受け取った時点では完全に初期化されておらず、 stateすらありません。

@kmalakoff 、 setupや同様のハックを必要としない方法でReactコンポーネントを整理する方法を示すコードサンプルを2回投稿しました。 コードを調整してReactと統合するのではなく、Reactコンポーネントの動作を変更しようと努力している理由を教えてください。 私のサンプルがあなたのユースケースに不適切な場所を指摘するだけでいいのですが。

@ akinnee-gl、更新時にthis.propsにアクセスするための新しいメソッドを導入しない理由は、そのようなメソッドがあるためです-それはrender()と呼ばれます。 shouldComponentUpdate()チェック後に呼び出されることもあります。これは通常、 this.props !== newPropsや_.isEqual(this.props, newProps)などを実行する場所です。
一部のセットアップに別のメソッドが必要だと思われる場合は、Reactコンポーネントをサブクラス化して、次のrender()メソッドを定義しないでください。

this.setup(this.props);
return this._render();

それがReactエコシステムで物事をどのように単純化するかはわかりませんが、それはあなたが要求し続けるものです。

@ me-andreこの問題の前提は、現在のAPIで目的を達成できないことでも、クライアントコードで現在のAPIを回避できないことでもありません。 この問題の前提は、現在のReact APIが最適ではなく、改善する必要があるということです。 たとえば、最適なAPIがどのように見えるか（上記で試したように）の原則を考え出した場合、現在のReact APIは、多くの領域で最適ではない/不十分であるため、中レベルの範囲でスコアリングされます。

残念ながら、クライアントコードでReact APIを回避する方法を提供しても、問題の根本原因に対処できず、根本的な問題に対処することから議論がシフトし、ReactAPIを改善するための潜在的な解決策に関する議論につながることはありません。

要するに、私はすでにたくさんのReactアプリを本番環境に置いているので、私のために働いている回避策を持っているので、ベストプラクティスはブログ投稿に最適かもしれませんが、この問題の議論のラインとしてそれらを使用すると、この問題の真の目的に関する真の議論：React APIを改善する方法（この問題では、小道具のユースケースと定型文に限定されます）。

React 1.0は、真ん中ではなく、上を目指す必要があります。 メジャーバージョンの増加は下位互換性を損なう可能性があるため、0.xバージョンを使用してきたこれらすべての年から学んだことに基づいて可能な限り最高のAPIを探しましょう。

（参考：人々は現在のAPIについて教えられるためにここに来ていないので、あなたが望んでいるほどあなたの例に関与していないかもしれませんが、彼らはAPIの改善を探している/望んでいるからです。善意であると認識される可能性がありますが、わずかにずれています）

人々は現在のAPIについて教えられるためにここに来ていないので、あなたが望んでいるほどあなたの例に関与していないかもしれないと思いますが、彼らはAPIの改善を探している/望んでいるからです

さて、あなたはAPI改善提案を持っていますが、それからあなたは「Reactのベストプラクティス」からかけ離れたコードを示しています。 いくつかのことは最悪の慣行に非常によく似ているようです。 次に、「それが変更の理由です」と言います。 はい、それが変更の理由ですが、Reactコードベースにはありません。
コードを再編成してReactでうまく機能するようにする方法を示しますが、適切な使用法のショーケースを無視して、主張し続けます。 それは建設的な議論ではないようです。

残念ながら、クライアントコードでReact APIを回避する方法を提供しても、問題の根本的な原因に対処できません。

低レベルのAPIを高レベルのAPIでラップする場合、これは回避策ではありませんが、一般的な方法です。 多くの優れたフレームワークがその考えに従います。
私が言い続けているのは、既存の醜いAPIを、使用して共有したいものでラップすることです。 使用例と説明とともに、なぜそれが良くなったのかは信じられないでしょう。
繰り返しますが、私はあなたがそれをしない理由がわかりません。 あなたが話していることが一般的な問題である場合、それは多くの人々にとって大きな助けになるでしょう。

私は本番環境にたくさんのReactアプリを持っているので、ベストプラクティスはブログ投稿に最適かもしれませんが、この号の議論のラインとしてそれらを使用すると、実際の議論から私たちを遠ざけることになります

APIを設計/設計するときによく行うことは、問題の予測、ユースケースについての仮説などです。人々が仮説を立てる理由は、理想を求めて現実の世界から自分自身を抽象化しようとするからではありません。 経験不足です。「事前に」経験を積むことはできません。

あなたはその経験があり、実際の問題を見てきました、そしてあなたが共有できるいくつかの回避策があると言います。 それこそが、この議論を「現実的」かつ「効果的」に変えることができるものです。 React自体は、実際の問題と課題に基づいて構築されています。そのため、「Hello Worldを3行で記述する方法」だけでなく、実際のアーキテクチャの問題も解決します。

@ me-andre私はあなたの言うことを聞き、あなたの議論の線は明確です。

私の議論の中心は、現在のReact APIを使用した集合的な経験に基づいてより良い原則を確立し、いくつかの基本的な方法でAPIを変更する可能性のある非独断的なソリューションを含めるために議論を開く場合、私たちはできるし、すべきであるということです。 React APIを改善して、現在よりもさらに優れたものにする機会をつかみます。 改善の余地があるときは、私たちの栄光に甘んじてはいけません！

小道具に関する現在のReactAPIをどのように評価しますか？ （文字の成績を使用するとしましょう：FからA +）、なぜ、そしてそれがA +未満の場合、それを改善するために何をしますか？

@ me-andreランキングと分析を準備する機会がありましたか？ 現在のAPIの長所、短所、機会について、あなたが信じていることを聞きたいと思います。

+1

+1お願いします

回避策はありますか？ ComponentDidReceivePropsが必要です

私は1年以上前にこの問題を作成し、それ以来毎日Reactを使用しています。 APIを増やすことを正当化するcomponentDidReceivePropsのユースケースはもうないと思います。

@AlexCppns何をしようとしているのですか？

@iammerrick 、実際には大丈夫です

関連するディスカッション： https ：

私はこれに数回遭遇しました、そして私がやったことは次のとおりでした：

componentWillReceiveProps(nextProps) {
  if (this.props.foo !== nextProps.foo) this.needsUpdate = true;
}
componentDidUpdate() {
  if (this.needsUpdate) {
    this.needsUpdate = false;
    // update the dom
  }
}

悪くないです。

@brigand 、フラグは必要ありません- componentDidUpdate()内の小道具を比較できます：

componentDidUpdate(prevProps) {
    let needsUpdate = prevProps.foo !== this.props.foo;
    // ...whatever
}

さらに、ソリューションはshouldComponentUpdate()によって簡単に破られる可能性があり、再レンダリングが妨げられる可能性があります。

かっこいい、ありがとう！

@jimfb以下の同期ユースケースがあると思います。 componetDidReceivePropsはこれにぴったりだったと思います。

  componentDidMount() {
    this._selectAll()
  }

  componentDidUpdate(prevProps) {
    let shouldUpdateSelected = (prevProps.recordTypeFilter !== this.props.recordTypeFilter) ||
      (prevProps.statusFilter !== this.props.statusFilter) ||
      (prevProps.list !== this.props.list)

    if (shouldUpdateSelected) { this._selectAll() }
  }

  _selectAll() {
    this.setState({ selectedIds: this._getFilteredOrders().map((order) => ( order.id )) })
  }

  _getFilteredOrders() {
    let filteredOrders = this.props.list

    // recordTypeFilter
    let recordTypeFilter = this.props.recordTypeFilter
    filteredOrders = _.filter(filteredOrders, (order) => {
        // somelogic
    })

    // statusFilter
    let statusFilter = this.props.statusFilter
    filteredOrders = _.filter(filteredOrders, (order) => {
        // somelogic
    })

    return filteredOrders
  }

@chanakasan 、あなたの例にはrender()メソッドがあり
次に、コードはいくつかのカスタムビジネスロジックに接続されており、読みやすくありません。 他の人にコピー＆ペーストを投げるだけでなく、説明することを躊躇しないでください。
しかし、私はあなたの例を読みました、そして以下の考えを共有したいと思います：

1. これはcomponentDidUpdateではなく、 componentWillReceivePropsの使用例です。 componentWillReceivePropsに切り替えると、同じロジックを維持しながら、コンポーネントの再レンダリングが2倍少なくなります。 このディスカッションを離れてから1年経った今でも、DOMの変更に対応することを除いて、 componentDidUpdateユースケースはありません。
2. ただし、 this.state.selectedIdsは実際には状態ではないため、フックをまったく回避し、すべてのロジックをrender()メソッドに移動する/ステートレスコンポーネントに移行する方がはるかに優れています。 それは純粋に小道具から計算されます。

こんにちは@ me-andre、返信に時間を割いていただきありがとうございます。 このページのディスカッションを読みました。参加していただきありがとうございます。

はい、 componentDidReceivePropsは必要ありませんが、それがないと物事は不思議に思えます。
componentWillReceivePropsを使用すると、 your component would re-render twice as lessと言われました。 それはまだ私には謎です。

私はあなたが以前に提案した2つのことを考えて試しましたが、失敗しました。

1. _selectAll()から呼び出された_getFilteredOrders()関数にはnewPropsが必要なため、componentWillReceivePropsは機能しません。
2. selectedIdsを状態に保存せずに導出する方法は考えられませんでした。

ユースケースから完全な例を作成しました。 なるべくわかりやすくしました。

よろしければ、ご覧になり、正しい方向に向けてください。 これを正しく理解できたら、この例をブログ投稿で共有して、他の人にも役立てます。

@chanakasan 、さあ、これは本番コードのように見えます。 私はそれをすべて読んで、あなたのプロジェクトを無料で手伝うつもりはありません。

しかし、私はあなたに正しい方向を示すことができます：

1. componentWillReceiveProps()とcomponentDidUpdate()両方が、前の小道具と次の小道具にアクセスできます。 それは公式のReactドキュメントからはっきりとわかります。
2. コードの完全なコピーペーストから、ユーザーが切り替えることができる選択されたIDを格納するためにstateを使用することが明らかになりました。 その場合、状態を使用することは問題ありませんが、それでもcomponentWillReceiveProps()は2倍少ない再レンダリングをトリガーします。 （とにかくcomponentWillReceiveProps()後にレンダリングが行われるため、 setState()は次のレンダリングの状態を更新するだけです）。
3. ドキュメントをご覧ください。 あなたの時間を節約し、他の人を尊重します。

@ me-andreドキュメントでこの行を使用してcomponentWillReceivePropsについてのあなたのポイントを理解していると思います：

this.setState（）を呼び出すだけでは、componentWillReceiveProps（）は呼び出されません。

ただし、 componentWillReceivePropsを使用する場合の注意点は、nextPropsを関数に渡す必要があることです。

私はあなたのアドバイスに従おうとします。 ありがとうございます。

ところで、私の制作プロジェクトを無料で手伝ってくれるのは私の意図ではありませんでした:)。 これは、私のユースケースに関する空白を埋める前の短い例からのより完全な例です。

これをshouldComponentUpdateと組み合わせて使用​​するとどうなりますか？
コンポーネントの状態を更新したり、再レンダリングしたりしたくない場合は、
ただし、小道具を受け取った後、this.propsを使用して、手動のスクリプト作業を行う必要があります。

私の回避策は、目的の関数を実行する前に、this.propsを新しいpropsに設定することです。

ComponentDidMountまたはそのためのフックがあると本当に便利です。 どうして？ なぜなら、Reactのライフサイクルに依存しない他の計算を行う必要がある場合があるからです。

例：サイズ変更される可能性のある親コンポーネントがあります。 子コンポーネントは、マップのサイズ変更を担当する関数を持つOpenLayerマップをレンダリングする責任があります。 ただし、子が親から小道具を取得し、Reactライフサイクル内で他の計算をコミットした後に発生する必要があります。