reactjs - props - React.Component vs React.PureComponent

setstate reactjs

Question

Los documentos oficiales de React establecen que " React.PureComponent ''s shouldComponentUpdate() solo compara los objetos de forma superficial", y desaconseja esto si el estado es "profundo".

Dado esto, ¿hay alguna razón por la que uno prefiera React.PureComponent al crear componentes React?

Preguntas :

• ¿Hay algún impacto en el rendimiento al usar React.Component que podamos considerar para React.PureComponent ?
• Supongo que shouldComponentUpdate() de PureComponent realiza solo comparaciones superficiales. Si este es el caso, ¿no se puede usar dicho método para realizar comparaciones más profundas?
• "Además, React.PureComponent ''s shouldComponentUpdate() omite las actualizaciones de utilería para todo el subárbol componente". ¿Significa esto que se ignoran los cambios de utilería?

La pregunta surgió de la lectura en este blog medio , si es útil.

Answer 1

Component y PureComponent tienen una diferencia

PureComponent es exactamente lo mismo que Component excepto que maneja el método shouldComponentUpdate por usted.

Cuando los accesorios o el estado cambian, PureComponent hará una comparación superficial tanto en los accesorios como en el estado. Component por otro lado, no comparará los accesorios y el estado actuales con el siguiente fuera de la caja. Por lo tanto, el componente se volverá a representar de forma predeterminada cada shouldComponentUpdate se llame a shouldComponentUpdate .

Comparación superficial

Al comparar accesorios y estado anteriores con el siguiente, una comparación superficial comprobará que las primitivas tienen el mismo valor (por ejemplo, 1 es igual a 1 o que verdadero es igual a verdadero) y que las referencias son las mismas entre valores de JavaScript más complejos como objetos y matrices.

Fuente: https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81

Answer 2

La principal diferencia entre React.PureComponent y React.Component es que PureComponent hace una comparación superficial sobre el cambio de estado. Significa que cuando compara valores escalares, compara sus valores, pero cuando compara objetos solo compara referencias. Ayuda a mejorar el rendimiento de la aplicación.

Debe React.PureComponent por React.PureComponent cuando pueda satisfacer cualquiera de las siguientes condiciones.

• State / Props debe ser un objeto inmutable
• El estado / los accesorios no deben tener una jerarquía
• Debe llamar a forceUpdate cuando los datos cambien

Si está utilizando React.PureComponent , debe asegurarse de que todos los componentes secundarios también sean puros.

¿Hay algún impacto en el rendimiento al usar React.component que podamos considerar para React.PureComponent?

Sí, aumentará el rendimiento de su aplicación (debido a la comparación superficial)

Supongo que shouldComponentUpdate () de Purecomponent realiza solo comparaciones superficiales. Si este es el caso, ¿no se puede usar dicho método para realizar comparaciones más profundas?

Lo has adivinado correctamente. Puede usarlo si cumple con alguna de las condiciones que mencioné anteriormente.

"Además, React.PureComponent shouldComponentUpdate () omite las actualizaciones de utilería para todo el subárbol componente" - ¿Esto significa que se ignoran los cambios de utilería?

Sí, los cambios de utilería serán ignorados si no puede encontrar diferencia en la comparación superficial.

Answer 3

La principal diferencia, según lo veo, es que un componente se retrae cada vez que su padre se retrae, independientemente de si los accesorios y el estado del componente han cambiado.

Un componente puro, por otro lado, no volverá a rendirse si su padre se vuelve a rendir, a menos que los accesorios (o estado) del componente puro hayan cambiado.

Por ejemplo, supongamos que tenemos un árbol de componentes con una jerarquía de tres niveles: padres, hijos y nietos.

Cuando los accesorios de los padres se cambian de una manera que se cambian los accesorios de un solo hijo, entonces:

• si todos los componentes son componentes regulares, todo el árbol de componentes se volverá a procesar
• Si todos los hijos y nietos son componentes puros, solo un hijo volverá a rendir, y uno o todos sus nietos, dependiendo de si se cambian sus accesorios. Si hay muchos componentes en este árbol de componentes, puede significar un aumento significativo del rendimiento.

A veces, sin embargo, el uso de componentes puros no tendrá ningún impacto. Tuve un caso así cuando el padre recibió sus accesorios de una tienda redux y necesitaba realizar un cálculo complejo de los accesorios de sus hijos. El padre usó una lista plana para representar a sus hijos.

El resultado fue que cada vez que hubo un pequeño cambio en la tienda redux, se recalculó toda la matriz de la lista plana de los datos de los niños. Esto significaba que para cada componente del árbol, los accesorios eran objetos nuevos, incluso si los valores no cambiaban.

En este caso, los componentes puros no ayudan, y el aumento del rendimiento solo se puede lograr mediante el uso de componentes regulares y la comprobación de los elementos secundarios, en shouldComponentUpdate, si es necesario volver a generar.