¿Cómo ofrecerán los componentes sin estado de React 0.14 las mejoras de rendimiento sin debería actualizar el componente?

8

Esta pregunta ha estado dando vueltas y vueltas en mi cabeza desde que leí las notas de la versión (y otras exageraciones relacionadas) sobre React 0.14. Soy un gran fan de React y creo que los componentes sin estado ( enlace ) son una excelente idea, tanto para la facilidad para escribir dichos componentes y para expresar en el código la intención de que estos componentes deben ser "puros" en términos de representación coherente para los mismos datos de utilería.

La pregunta es: ¿cómo será posible que React optimice estas funciones de los componentes sin estado sin dejar de lado y asumiendo que las referencias de accesorios no solo sean inmutables, ya que no deben ser manipuladas dentro del componente, sino también que ¿Nunca se puede cambiar fuera del ciclo de vida del componente? La razón por la que los componentes "regulares" (también conocidos como componentes con estado - en otras palabras, los componentes que atraviesan todo el ciclo de vida; componentWillMount, getInitialState, etc.) tienen una función opcional "shouldComponentUpdate" es que React no asume que todos los accesorios y Las referencias de estado son completamente inmutables. Después de que los componentes se hayan procesado, ciertas propiedades de las referencias de accesorios pueden cambiar y, por lo tanto, la misma instancia de "accesorios" puede tener contenidos diferentes más adelante. Esto se debe en parte a la razón por la que hubo mucho entusiasmo por el uso de estructuras totalmente inmutables y se dijo que el uso de Om con React podría ofrecer grandes ganancias de rendimiento; debido a que las estructuras inmutables usadas allí garantizaban que cualquier instancia dada de cualquier objeto nunca podría ser mutada, por lo tanto, ComponentUpdate podría realizar verificaciones de igualdad de referencia realmente baratas en propiedades y estado ( enlace ).

He estado tratando de encontrar más información sobre esto, pero no he llegado a ninguna parte. No puedo imaginar qué mejoras de rendimiento podrían realizarse alrededor de los componentes sin estado sin suponer que los datos de utilería consistirán en tipos inmutables ... tal vez algún análisis preliminar de los tipos de utilería no inmutables para tratar de adivinar si "props" y "nextProps" representan la mismos datos?

Simplemente me pregunté si alguien tenía alguna información interna o alguna información esclarecedora sobre esto. Si React comenzó a exigir que los tipos de accesorios sean "completamente inmutables" (permitir que las comparaciones de igualdad de referencia confirmen que los datos no han cambiado), creo que sería un gran paso adelante, pero también podría ser un gran cambio.

    
pregunta Dan Roberts 17.11.2015 - 21:21

1 respuesta

4

Hay un problema con github en el proyecto de reacción sobre exactamente esto.

De acuerdo con este problema github comment:

  

Para componentes complejos, debe definir shouldComponentUpdate (por ejemplo, pure   render) generalmente excederá los beneficios de rendimiento de los apátridas   componentes Las oraciones en los documentos están apuntando a algún futuro   optimizaciones que hemos planeado, por lo que no asignaremos una   instancia interna para componentes funcionales sin estado (solo   llamar a la función). También podríamos no seguir sujetando los pilares, etc.   Optimizaciones minúsculas. No hablamos de los detalles en la documentación.   porque las optimizaciones aún no están implementadas (sin estado)   Los componentes abren las puertas a estas optimizaciones).

y de otro responder del mismo colaborador:

  

Hay discusiones sobre la posibilidad de tener una marca pureRender que puedas   establecer en la función, o permitir que participe en el shouldUpdate   Ciclo de vida, pero actualmente no está implementado. En el momento,   Las funciones sin estado no pueden ser de representación pura.

finalmente de este comentario obtenemos una respuesta a tu pregunta:

  

no hacemos renderización pura por defecto, pero podemos proporcionarle una forma   para optar en el futuro.

Por lo tanto, tendremos que ver cómo nos permiten participar en 'pureRender' :)

    
respondido por el Siamore 28.01.2016 - 14:53

Lea otras preguntas en las etiquetas