Cómo usar la nueva función experimental Profiler en React

¡Entonces React 16.4.0 ha salido! (Nota traductor: esta característica se agregó en la versión 16.4.0, luego se escribió esta publicación). Y en esos momentos entiendes cómo eres JavaScript, un geek si sigues actualizaciones menores de tu marco favorito. Genial



Si leyó las notas de la versión 16.4 publicadas por el equipo React, esta actualización debería haberse considerado bastante aburrida. Los eventos de puntero parecen atractivos, pero para ser honesto, he escuchado poco sobre ellos antes.

Además, hay una getDerivedStateFromProps de getDerivedStateFromProps para un nuevo método getDerivedStateFromProps (ahora se llamará en cada render). Todavía no lo he usado lo suficiente, por lo que para mí esta actualización no fue muy importante.

Entonces vi el anuncio, enterrado bajo los encabezados, de que habían agregado un nuevo componente experimental, unstable_Profiler . Al ver que mi vida ahora es bastante inestable ( unstable_ ), decidí leer el RFC y probarlo.

TLDR

La gente del equipo React está tratando de hacer que el renderizado sea asíncrono . Esto puede dificultar determinar cuándo renderizar componentes al montar / actualizar. Por lo tanto, están jugando con este nuevo y brillante componente Profiler .

Entonces, ¿qué puedes usar hoy?

Entonces, si eres un profesional en el seguimiento del rendimiento de tus aplicaciones de reacción, esta será definitivamente otra buena herramienta en tu arsenal. Si no se trata de ti, ya no puedes leer y volver a crear aplicaciones geniales.

Usando <Profiler />

Advertencia : tal vez no debería usar esto en producción (bueno, en realidad, esto es unstable_ ). Más tarde terminarán la capacidad de crear un perfil y un código de producción.

Básicamente, Profiler es un componente que se puede extraer del paquete predeterminado React. Dado que tiene un nombre subrayado cauteloso al que muchas linters juran, puede evitar esto de la siguiente manera:

 import React, { unstable_Profiler as Profiler } from 'react'; ... const Profiler = React.unstable_Profiler; 

¡Ahora que tiene Profiler , Profiler los componentes! Puede envolver cualquier parte de su árbol JSX en Profiler para ver qué le sucede. Profiler acepta la función onRender , que captura información sobre el tiempo de representación. Aquí hay un simple ejemplo de contador :

 import React, { unstable_Profiler as Profiler } from 'react'; class ComponentWithProfiling extends React.Component { state = { count: 0 }; logProfile = (id, phase, actualTime, baseTime, startTime, commitTime) => { console.log(`${id}'s ${phase} phase:`); console.log(`Actual time: ${actualTime}`); console.log(`Base time: ${baseTime}`); console.log(`Start time: ${startTime}`); console.log(`Commit time: ${commitTime}`); }; go = direction => () => this.setState(({ count }) => ({ count: direction === "up" ? count + 1 : count - 1 })); render() { return ( <Profiler id="app" onRender={this.logProfile}> <button onClick={this.go("up")}>️</button> <div>The count is {this.state.count}</div> <button onClick={this.go("down")}></button> </Profiler> ); } } 

Tenga en cuenta que debe dar una id cada fragmento que perfila. Como puede ver a continuación, onRender acepta un montón de métricas interesantes:


7jroojkv30.codesandbox.io

En primer lugar, puede ver cuál fue la fase de renderizado (ya sea mount o update ), que se puede utilizar para identificar partes del código que se actualizan inesperadamente (al igual que el excelente paquete de por qué actualizó que usé muchas veces y Muy recomendable).

A continuación, obtenemos actualTime y baseTime . Están relacionados con el tiempo real que React pasa en los cálculos de representación; es decir averiguar lo que ha cambiado. Tenga en cuenta que el tiempo real (tiempo inicial) de la conexión inicial (montaje) es mayor que el tiempo de actualización (actualización). Esto se debe a que en la conexión inicial, técnicamente todo es "nuevo". Durante la actualización, los cálculos deberían ser más simples, porque, espero, los componentes en el árbol se actualizan solo si realmente han cambiado (es decir, cuando los valores de prop / states han cambiado).

En aplicaciones grandes / del mundo real, estos datos lo ayudarán a comprender dónde se shouldComponentUpdate usar incorrectamente shouldComponentUpdate o en absoluto, lugares donde los accesorios con tipos de referencia a menudo cambian o se envían nuevos accesorios, o solo lugares donde no esperaba que las actualizaciones demoraran tanto.

Los últimos valores que obtenemos en onRender son startTime y commitTime . Estas son, de hecho, marcas de tiempo desde el lanzamiento inicial. startTime es el tiempo a partir del cual el componente seleccionado comenzó a realizar cálculos para la representación, mientras que commitTime es el momento en que React realmente commitTime estos cambios durante la representación.

Si realiza un seguimiento de otros eventos con marcas de tiempo (como clics o pulsaciones de teclas), estas métricas pueden ayudar a identificar deltas entre cuándo ocurren los eventos del usuario y cuándo ocurre la representación real. Si la brecha es grande, este retraso puede ser palpable para los usuarios y debe examinarse cuidadosamente.

Conclusión

Para mí personalmente, esta herramienta aún no es muy útil. Pero esta es una de esas cosas que es bueno saber, porque si alguna vez me encuentro con estos cuellos de botella de rendimiento, será una buena manera de medirlos.

Es importante medir primero sus problemas de rendimiento, de modo que cuando realiza "mejoras" puede saber si esto realmente mejora la situación o solo empeora. Descubrí que optimizar el rendimiento es una de esas cosas en las que puedes pasar mucho tiempo. Por lo tanto, antes de optimizar algo, asegúrese de que sea realmente necesario.

Espero con ansias lo que el equipo de React hará con Profiler en el futuro. ¡Gracias @bvaughn por agregar esta ingeniosa función!

Del traductor:
Por el momento (versión actual 16.6.0) Profiler no funciona con la representación del lado del servidor. La solicitud de función ya existe.