Cet article parle principalement de choses que vous devez savoir sur react, telles que les composants du conteneur et les propriétés des composants, l'asynchronie setState, etc. Jetons un coup d'œil ensemble à cet article Article Bar
Lors de l'écriture de composants à l'aide de React, nous devons consciemment combiner les composants. Divisés en composants conteneur et composants présentation, cela nous aide à être plus clair sur ce dont ce composant devrait être responsable lors de l'écriture de composants.
Le composant conteneur est responsable du traitement de la logique des processus métier, tels que l'envoi de requêtes réseau, le traitement des données de requête et la transmission des données traitées aux accessoires des sous-composants pour utilisation. Dans le même temps, le composant conteneur fournit des méthodes de données source et les transmet aux sous-composants sous forme d'accessoires. Lorsque les changements d'état du sous-composant entraînent des modifications dans les données source, le sous-composant synchronise ces modifications en. appeler les méthodes fournies par le composant conteneur.
Les composants présentatifs sont responsables de l'apparence du composant, c'est-à-dire de la façon dont le composant est rendu, et ont une forte cohésion. Le composant de présentation ne se soucie pas de la manière dont les propriétés du composant (Props) utilisées dans le rendu sont obtenues. Il a seulement besoin de savoir comment le composant doit être rendu avec ces Props. La manière d’obtenir les propriétés relève de la responsabilité du composant conteneur. Lorsque les changements dans l'état d'un composant de présentation doivent être synchronisés avec les données source, une méthode dans le composant conteneur doit être appelée. Cette méthode est généralement transmise au composant de présentation via Props.
Par exemple, un projet Todo a un composant Todo et un composant TodoList. Le composant Todo est un composant conteneur qui est chargé d'obtenir la liste de tâches du serveur. il est transmis à TodoList pour display . Après avoir créé un nouvel élément de tâche dans TodoList, vous devez appeler la méthode d'enregistrement de l'élément de tâche dans le composant Todo via les accessoires de TodoList pour synchroniser le nouvel élément de tâche avec le serveur.
Les composants de conteneur et les composants de présentation peuvent être imbriqués les uns dans les autres. Un composant de conteneur peut contenir plusieurs composants de présentation et d'autres composants de conteneur ; un groupe de présentation peut également contenir des composants de conteneur et d'autres composants d'affichage. Ce type de division du travail peut rendre la logique qui n'est pas directement liée au rendu des composants centralisée et responsable du composant conteneur, et le composant de présentation se concentre uniquement sur la logique de rendu du composant, rendant ainsi le composant de présentation plus facile à réutiliser. Pour les pages très simples, un seul composant conteneur suffit généralement ; mais pour les pages responsables, plusieurs composants conteneur sont nécessaires, sinon, si toute la logique métier est traitée dans un seul composant conteneur, le composant sera en même temps très complexe. les données source obtenues par ce composant peuvent devoir passer par de nombreuses couches de composants Props avant d'atteindre le composant d'affichage final utilisé.
Les concepts de Props et State sont très clairs Les propriétés communes d'un composant font référence aux propriétés qui sont directement montées sous celui-ci dans. le composant. En fait, Props et State sont également deux propriétés communes des composants, car nous pouvons les obtenir directement via this.props et this.state. Alors, dans quels scénarios les Props, State et autres propriétés communes des composants doivent-elles être utilisées ?
Les accessoires et l'état sont tous deux utilisés pour le rendu des composants, c'est-à-dire que l'apparence finale d'un composant dépend des accessoires et de l'état du composant. Les modifications dans les accessoires et l'état déclencheront la méthode de rendu du composant . Mais il existe des différences entre les deux. Les accessoires sont des données en lecture seule, qui sont transmises par le composant parent ; tandis que State est l'état maintenu par le composant lui-même et est modifiable. L'état peut changer en fonction des modifications apportées aux accessoires. Si d'autres propriétés sont nécessaires dans le composant et que cette propriété n'a rien à voir avec le rendu du composant (c'est-à-dire qu'elle ne sera pas utilisée dans la méthode de rendu), alors cette propriété peut être accrochée directement sous celle-ci au lieu d'être un état du composant.
Par exemple, si une minuterie est nécessaire dans un composant et que l'état du composant change toutes les quelques secondes, vous pouvez définir une propriété this.timer pour effacer la minuterie lorsque composantWillUnmount. (Si vous souhaitez en savoir plus, rendez-vous sur le site Web PHP chinois colonne React Reference Manual pour en savoir)
Le site officiel de React a mentionné que this.state et this.props La mise à jour peut être asynchrone et React peut fusionner plusieurs appels setState en une seule mise à jour d'état pour des raisons de performances. Ne vous fiez donc pas aux valeurs de this.props et this.state pour calculer l'état suivant. Citant un exemple de code du site officiel :
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});Si vous devez le faire, vous pouvez utiliser une autre méthode setState qui prend une fonction comme paramètre. Le premier paramètre de cette fonction est l'état précédent, et. le deuxième paramètre est le dernier accessoire actuellement reçu. Comme indiqué ci-dessous :
// 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。
当组件的属性可能发生变化时，这个方法会被调用。这里说可能，是因为父组件render方法每次被调用时，子组件的这个方法都会被调用（子组件第一次初始化时除外），但并不一定每次子组件的属性都会发生变化。如果组件的State需要根据Props的变化而变化，那么这个方法就是最适合这个这个逻辑的地方。例如当Props变化时，组件的State需要重置，就可以在这个方法中调用this.setState()来重置状态。需要注意，在这个方法中调用this.setState()并不会重新触发componentWillReceiveProps的调用，也不会导致render方法被触发两次。一般情况下，接收到新Props会触发一次render，调用this.setState也会触发一次render，但在componentWillReceiveProps中调用this.setState，React会把原本需要的两次render，合并成一次。
这个方法常作为优化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方法被调用，或者组件自己每次调用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)。这两个假设是：
如果两个组件或元素类型不同，那么他们就是完全不同的树，不需要再比较他们的子节点。例如，<Article>和<Comment>将产生是两个完全的树状结构；<p>children</p>和<p>children</p>也是两个完全不同的树。这种情况下，组件会被完全重建，旧的DOM节点被销毁，组件经历componentWillUnmount()，然后重新创建一棵新树， 组件经历 componentWillMount() 和 componentDidMount()。
可以为组件或元素设置key属性，key用来标识这个组件或元素。key不需要全局唯一，只需要在兄弟组件或兄弟元素间保证唯一性就可以。key常用到集合（List）元素中。例如：
<ul><li key='a'>Book A</li><li key='b'>Book B</li></ul>
当在第一个位置插入一条记录Book C 时，
<ul><li key='c'>Book C</li><li key='a'>Book A</li><li key='b'>Book B</li></ul>
由于有key的标识，React知道此时新增了一条记录，会创建一个新的<li>元素，并把它插入到列表中的第一个位置。如果没有设置key，React并不知道是新增了一条记录，还是原来的两条记录完全替换成新的三条记录，或者其他更加复杂的修改场景。React需要自上而下的比较每一条记录，这样每次比较节点都不同，所以需要修改两次节点，然后再新增一个节点，效率明显要差很多。
这里同时揭露了另一个问题，不要使用元素在集合中的索引值作为key，因为一旦集合中元素顺序发生改变，就可能导致大量的key失效，进而引起大量的修改操作。
当我们需要从服务器获取数据时，我们应该在组件的哪一个生命周期方法中发送网络请求呢？React官网上提到，可以在componentDidMount中发送网络请求，这也是一般情况下的最佳实践。有些人也会把发送网络请求放在componentWillMount中，并且认为这个方法先于componentDidMount调用，所以可以更快地获取数据。个人认为，这种使用方法一般也是没有问题的，但在一些场景下会出现问题，比如需要在服务器端渲染时，componentWillMount会被调用两次，一次是在Server端，一次是在Client端。可参考这篇文章。
本篇文章到这就结束了（想看更多就到PHP中文网React使用手册栏目中学习），有问题的可以在下方留言提问。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
