Então o React 16.4.0 foi lançado! (Note tradutor - esse recurso foi adicionado na versão 16.4.0, e este post foi escrito). E, nesses momentos, você entende como você é o JavaScript - um geek se você seguir pequenas atualizações da sua estrutura favorita. Ótimo!
Se você ler
as notas de versão
da versão 16.4 publicadas pela equipe do React, essa atualização deve ter sido considerada um pouco chata.
Os eventos de ponteiro parecem atraentes, mas, para ser sincero, já ouvi falar pouco sobre eles antes.
Além disso, há uma correção de
getDerivedStateFromProps para um tipo de novo método
getDerivedStateFromProps (agora ele será chamado em todas as renderizações). Ainda não usei o suficiente, portanto, para mim, essa atualização não foi muito importante.
Então eu vi o anúncio, enterrado sob os títulos, de que eles haviam adicionado um novo componente experimental,
unstable_Profiler . Vendo que minha vida agora é bastante instável (
unstable_ ), decidi ler o
RFC e experimentá-lo.
TLDR
As pessoas da equipe React
estão tentando tornar a renderização assíncrona . Isso pode dificultar a determinação de quando renderizar componentes ao montar / atualizar. Portanto, eles estão brincando com esse novo e brilhante componente
Profiler .
Então, o que você pode usar hoje?Portanto, se você é um profissional no acompanhamento do desempenho de seus aplicativos de reação, essa será definitivamente outra boa ferramenta em seu arsenal. Se isso não é sobre você, não é mais possível ler e voltar a criar aplicativos interessantes.
Usando <Profiler />
Aviso : talvez você não deva usar isso na produção (bem, na verdade, isso é unstable_ ). Mais tarde, eles concluirão a capacidade de criar perfil e código de produção.Basicamente, o
Profiler é um componente que pode ser extraído do pacote React padrão. Como ele tem um nome sublinhado cauteloso que muitos linters juram, você pode contornar isso da seguinte maneira:
import React, { unstable_Profiler as Profiler } from 'react'; ... const Profiler = React.unstable_Profiler;
Agora que você possui o
Profiler , vamos criar um perfil dos componentes! Você pode agrupar qualquer parte da sua árvore JSX no
Profiler para ver o que acontece com ela.
Profiler aceita a função
onRender , que captura informações sobre o tempo de renderização.
Aqui está um exemplo simples 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> ); } }
Observe que você deve fornecer um
id cada fragmento em seu
onRender você pode ver abaixo, o
onRender aceita
onRender métricas interessantes:
7jroojkv30.codesandbox.ioPrimeiro, você pode ver qual foi a fase de renderização (
mount ou
update ), que pode ser usada para identificar partes do código que são atualizadas inesperadamente (assim como o excelente pacote por que
você atualizou que usei muitas vezes e recomendo).
Em seguida, obtemos
actualTime e
baseTime . Eles estão relacionados ao tempo real que o React gasta na renderização de cálculos; isto é descobrir o que mudou. Observe que o tempo real (hora inicial) da conexão inicial (montagem) é maior que o tempo de atualização (atualização). Isso ocorre porque, na conexão inicial, tecnicamente tudo é "novo". Durante a atualização, os cálculos
devem ser mais simples, porque, espero, os componentes na árvore serão atualizados apenas se realmente tiverem sido alterados (ou seja, quando os valores de prop / states forem alterados).
Em aplicativos grandes / do mundo real, esses dados permitem que você entenda onde o
shouldComponentUpdate usado incorretamente ou não, lugares onde objetos com tipos de referência geralmente mudam ou novos objetos são enviados ou apenas lugares onde você não esperava que as atualizações demorassem tanto.
Os últimos valores que obtemos no
onRender são
commitTime e
commitTime . Esses são, de fato, registros de data e hora desde o lançamento inicial.
startTime é a hora a partir da qual o componente selecionado começou a executar cálculos para renderização, enquanto
commitTime é a hora em que o React realmente
commitTime essas alterações durante a renderização.
Se você rastrear outros eventos com registro de data e hora (como cliques ou pressionamentos de teclas), essas métricas poderão ajudar a identificar deltas entre quando os eventos do usuário ocorrem e quando a renderização real ocorre. Se a diferença for grande, esse atraso pode ser palpável para os usuários e deve ser cuidadosamente examinado.
Conclusão
Para mim, pessoalmente, essa ferramenta ainda não é muito útil. Mas é bom saber disso, porque se eu encontrar esses gargalos de desempenho, seria uma boa maneira de medi-los.
É importante primeiro avaliar seus problemas de desempenho; assim, quando você fizer "melhorias", poderá dizer se isso realmente melhora a situação ou apenas piora. Descobri que otimizar o desempenho é uma daquelas coisas nas quais você pode gastar muito tempo. Portanto, antes de otimizar algo., Verifique se é realmente necessário.
Estou ansioso pelo que a equipe do React fará com o
Profiler no futuro. Obrigado
@bvaughn por adicionar este recurso
bacana !
Do tradutor:No momento (versão atual 16.6.0), o Profiler não funciona com a renderização do servidor.
A solicitação de recurso já existe.