あなたは反応についてどれくらい知っていますか？反応に関する注意点のまとめ

この記事では、コンテナコンポーネントやコンポーネントのプロパティ、setStateの非同期など、reactに関して知っておくべきことを中心に説明しています。一緒にこの記事も読んでみましょう

コンテナコンポーネントとプレゼンテーションコンポーネント

コンポーネントを書くときReact を使用する場合、コンポーネントをコンテナ コンポーネントとプレゼンテーション コンポーネントに意識的に分割する必要があります。そうすることで、コンポーネントを作成するときにこのコンポーネントが何を担当すべきかをより明確にすることができます。

コンテナ コンポーネントは、ネットワーク リクエストの送信、リクエスト データの処理、処理されたデータをサブコンポーネントの Prop に渡して使用するなど、ビジネス プロセス ロジックの処理を担当します。同時に、コンテナ コンポーネントはソース データのメソッドを提供し、それを Props の形式でサブコンポーネントに渡します。サブコンポーネントの状態変化によってソース データが変更されると、サブコンポーネントはこれらの変更を同期します。コンテナコンポーネントによって提供されるメソッドを呼び出します。

プレゼンテーションコンポーネントは、コンポーネントの外観、つまりコンポーネントがどのようにレンダリングされるかを決定し、強い結束力を持ちます。プレゼンテーション コンポーネントは、レンダリングに使用されるコンポーネント プロパティ (Props) がどのように取得されるかを気にしません。必要なのは、これらの Props を使用してコンポーネントをレンダリングする方法だけです。プロパティを取得する方法はコンテナ コンポーネントの責任です。プレゼンテーション コンポーネントの状態の変更をソース データと同期する必要がある場合、コンテナ コンポーネント内のメソッドを呼び出す必要があります。このメソッドは通常、Props を通じてプレゼンテーション コンポーネントに渡されます。

たとえば、Todo プロジェクトには Todo コンポーネントと TodoList コンポーネントがあり、Todo コンポーネントはサーバーから ToDo リストを取得した後に に渡されます。表示用の TodoList。 TodoList に新しい ToDo 項目を作成した後、TodoList の Props を介して Todo コンポーネントに Todo 項目を保存するメソッドを呼び出し、新しい ToDo 項目をサーバーと同期する必要があります。

コンテナ コンポーネントとプレゼンテーション コンポーネントは相互にネストでき、コンテナ コンポーネントには複数のプレゼンテーション コンポーネントを含めることができ、他のコンテナ コンポーネントにはコンテナ コンポーネントと他のプレゼンテーション コンポーネントを含めることもできます。この種の分業により、コンポーネントのレンダリングに直接関係しないロジックを集中化してコンテナ コンポーネントが担当し、プレゼンテーション コンポーネントはコンポーネントのレンダリング ロジックのみに焦点を当てることができるため、プレゼンテーション コンポーネントの再利用が容易になります。非常に単純なページの場合、通常は 1 つのコンテナ コンポーネントで十分ですが、責任のあるページの場合は、すべてのビジネス ロジックが 1 つのコンテナ コンポーネントで処理されると、同時にコンポーネントが非常に複雑になります。このコンポーネントによって取得されたソース データは、使用される最終表示コンポーネントに到達する前に、コンポーネント Props の多くのレイヤーを通過する必要がある場合があります。

Props、State、およびコンポーネントの共通プロパティ

Props と State の概念は非常に明確です。コンポーネントの共通プロパティは、コンポーネント内の this の下に直接マウントされているプロパティを指します。実際、Props と State は、this.props と this.state を通じて直接取得できるため、コンポーネントの 2 つの共通プロパティでもあります。それでは、どのようなシナリオで Props、State、およびコンポーネントのその他の共通プロパティを使用する必要があるのでしょうか?

Props と State は両方ともコンポーネントのレンダリングに使用されます。つまり、コンポーネントが最終的にどのように見えるかは、コンポーネントの Props と State によって決まります。 Props と State を変更すると、コンポーネントの render メソッドがトリガーされます。しかし、両者には違いがあります。 Props は親コンポーネントから渡される読み取り専用データですが、State はコンポーネント自体によって維持される状態であり、変更可能です。状態は、Props の変更に基づいて変化する可能性があります。コンポーネントに他のプロパティが必要で、このプロパティがコンポーネントのレンダリングとは関係がない (つまり、render メソッドで使用されない) 場合、このプロパティは、コンポーネントの状態。

たとえば、コンポーネントにタイマーが必要で、コンポーネントの状態を数秒ごとに変更する場合は、componentWillUnmount のときにタイマーをクリアする this.timer プロパティを定義できます。 (さらに詳しく知りたい場合は、PHP 中国語 Web サイトReact Reference Manual の列にアクセスして学習してください)

setState の非同期性

React 公式 Web サイトには、this.state と this.props の更新が非同期である可能性があることが記載されており、Reactパフォーマンス上の理由から、複数の setState 呼び出しは 1 つの State 更新にマージされます。したがって、次の状態を計算するために this.props と this.state の値に依存しないでください。公式 Web サイトからコード例を引用します:

// Wrong
this.setState({
  counter: this.state.counter + this.props.increment,
});

これを行う必要がある場合は、関数をパラメータとして受け取る別の setState メソッドを使用できます。この関数の最初のパラメータは前の状態、2 番目のパラメータは最新の状態です。現在受け取った小道具。以下に示すように:

// Correctthis.setState(function(prevState, props) {
  return {
    counter: prevState.counter + props.increment
  };
});

在调用setState之后，也不能立即使用this.state获取最新状态，因为这时的state很可能还没有被更新，要想保证获取到的state是最新的state，可以在componentDidUpdate中获取this.state。也可以使用带用回调函数参数版本的setStatesetState(stateChange, [callback])，回调函数中的this.state会保证是最新的state。

componentWillReceiveProps

当组件的属性可能发生变化时，这个方法会被调用。这里说可能，是因为父组件render方法每次被调用时，子组件的这个方法都会被调用（子组件第一次初始化时除外），但并不一定每次子组件的属性都会发生变化。如果组件的State需要根据Props的变化而变化，那么这个方法就是最适合这个这个逻辑的地方。例如当Props变化时，组件的State需要重置，就可以在这个方法中调用this.setState()来重置状态。需要注意，在这个方法中调用this.setState()并不会重新触发componentWillReceiveProps的调用，也不会导致render方法被触发两次。一般情况下，接收到新Props会触发一次render，调用this.setState也会触发一次render，但在componentWillReceiveProps中调用this.setState，React会把原本需要的两次render，合并成一次。

shouldComponentUpdate

这个方法常作为优化React性能使用。当shouldComponentUpdate返回false时，组件本次的render方法不会被触发。可以通过在这个方法中比较前后两次state或者props，根据实际业务场景决定是否需要触发render方法。

React提供了一个React.PureComponent组件，这个组件重写了shouldComponentUpdate，会对前后两次的state和props进行浅比较，如何不一致，才会返回true，触发后续的render方法。这里的浅比较指，只会对state和props的第一级属性进行比较（使用!==），这满足一般的使用场景。如果你的组件继承了React.PureComponent，但在setState时，传入的state是直接修改的原有state对象，就会因为依然满足浅比较的条件，而不会重新触发render方法，导致最终DOM和state不一致。例如state={books: ['A','B']}，在setState时，使用this.setState({name: this.state.books.push('C')})直接修改books对象，这样虽然books内容发生了修改，但因为对象引用并没有变化，所以依然满足浅比较条件，不会触发render方法。

一般情况下，让shouldComponentUpdate返回默认的true是不会有太大问题的。虽然这样可能导致一些不必要的render方法被调用，但render方法直接操作的是虚拟DOM，只要虚拟DOM没有发生变化，并不会导致实体DOM的修改。而JS慢是慢在实体DOM的修改上。只要你的render方法不是很复杂，多调用几次render方法并不会带来多大的性能开销。

render

父组件每次render方法被调用，或者组件自己每次调用setState方法，都会触发组件的render方法（前提是shouldComponentUpdate使用默认行为，总是返回true）。那么组件每次render，是不是都会导致实体DOM的重新创建呢？答案是，不是！

React之所以比直接操作DOM的JS库快，原因是React在实体DOM之上，抽象出一层虚拟DOM，render方法执行后，得到的是虚拟DOM，React 会把组将当前的虚拟DOM结构和前一次的虚拟DOM结构做比较，只有存在差异性，React才会把差异的内容同步到实体DOM上。如果两次render后的虚拟DOM结构保持一致，并不会触发实体DOM的修改。

React速度快的原因，还有一个是它出色的Diff算法。标准的比较两棵树的Diff算法的时间复杂是 O(n3) 。而React基于非常符合实际场景的两个假设，就将Diff算法的时间复杂度降到了接近O(n)。这两个假设是：

<li>

如果两个组件或元素类型不同，那么他们就是完全不同的树，不需要再比较他们的子节点。例如，<Article>和<Comment>将产生是两个完全的树状结构；<p>children</p>和<p>children</p>也是两个完全不同的树。这种情况下，组件会被完全重建，旧的DOM节点被销毁，组件经历componentWillUnmount()，然后重新创建一棵新树， 组件经历 componentWillMount() 和 componentDidMount()。

<li>

可以为组件或元素设置key属性，key用来标识这个组件或元素。key不需要全局唯一，只需要在兄弟组件或兄弟元素间保证唯一性就可以。key常用到集合（List）元素中。例如：

<ul><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

当在第一个位置插入一条记录Book C 时，

<ul><li key=&#39;c&#39;>Book C</li><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

由于有key的标识，React知道此时新增了一条记录，会创建一个新的<li>元素，并把它插入到列表中的第一个位置。如果没有设置key，React并不知道是新增了一条记录，还是原来的两条记录完全替换成新的三条记录，或者其他更加复杂的修改场景。React需要自上而下的比较每一条记录，这样每次比较节点都不同，所以需要修改两次节点，然后再新增一个节点，效率明显要差很多。

这里同时揭露了另一个问题，不要使用元素在集合中的索引值作为key，因为一旦集合中元素顺序发生改变，就可能导致大量的key失效，进而引起大量的修改操作。

如何发送网络请求

当我们需要从服务器获取数据时，我们应该在组件的哪一个生命周期方法中发送网络请求呢？React官网上提到，可以在componentDidMount中发送网络请求，这也是一般情况下的最佳实践。有些人也会把发送网络请求放在componentWillMount中，并且认为这个方法先于componentDidMount调用，所以可以更快地获取数据。个人认为，这种使用方法一般也是没有问题的，但在一些场景下会出现问题，比如需要在服务器端渲染时，componentWillMount会被调用两次，一次是在Server端，一次是在Client端。可参考这篇文章。

本篇文章到这就结束了（想看更多就到PHP中文网React使用手册栏目中学习），有问题的可以在下方留言提问。

以上があなたは反応についてどれくらい知っていますか？反応に関する注意点のまとめの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。