React: Devtools V4: Onde estão as atualizações de destaque?

O mesmo problema aqui. As atualizações em destaque desapareceram.
Eu queria saber se é preciso usar o Profiler agora, para rastrear as atualizações.

https://www.reddit.com/r/reactjs/comments/cqx554/introducing_the_new_react_devtools/ex1r9nb/

A resposta honesta é que não tivemos tempo de implementá-lo e não o consideramos importante o suficiente para bloquear o lançamento de todos os outros recursos.

No entanto, há motivos mais profundos pelos quais não temos certeza se o adicionaremos de volta. Contribui para a ideia errada de que as reconstruções por si mesmas são ruins (não serão se forem baratas). Assim, as pessoas gastam tempo otimizando coisas inúteis e perdendo problemas reais de desempenho.

O novo DevTools inclui um Profiler que deve ajudá-lo a encontrar problemas reais de desempenho em seu código. Eu entendo o desejo de uma maneira superleve de encontrar renderizações extras - e talvez possamos adicionar isso - mas precisamos pensar mais sobre como isso deve funcionar primeiro.

Editado para adicionar comentário inline

Algumas discussões anteriores relacionadas https://github.com/bvaughn/react-devtools-experimental/issues/244

O Highlight Updates foi muito útil, não tanto para corrigir problemas de desempenho (o novo Profiler é muito melhor nisso), mas para descobrir renderizações surpreendentes. Isso nos salvou inúmeras vezes, especialmente ao trabalhar com Context, onde uma alteração pode causar uma nova renderização em outras partes do aplicativo. Ao trabalhar no Perfilador, você tende a se concentrar em apenas uma parte da árvore, portanto, as regressões são fáceis de perder.

Eu entendo as preocupações de @gaearon sobre dar a ideia errada, então que tal:

1. Escolha a cor do contorno com base na duração da renderização

Os rebocos baratos devem ser verdes, os rebocos caros devem ser amarelos ou vermelhos. Ou apenas use exatamente as mesmas cores usadas pelo Perfilador.

2. Varie a velocidade de desvanecimento do contorno

A animação de esmaecimento do contorno deve ser relativa à duração da renderização. As renderizações rápidas devem desaparecer imediatamente, as renderizações lentas devem desaparecer mais lentamente.

3. Diferencie as áreas repintadas

Às vezes usei Highlight Updates com Paint Flashing do Chrome. Isso fez com que os renderizadores que levavam ao redesenho fossem realçados de forma diferente dos que não tinham efeito DOM. Acho que DevTools deve ter uma função semelhante embutida.

• Uma renderização cara sem redesenho deve ser o alvo principal para otimizações de desempenho.
• Os renderizadores que repintam obviamente estão fazendo algum trabalho que precisa ser feito.
• As renderizações rápidas que resultam em nenhuma repintura podem ser ignoradas.

Talvez até tenha uma configuração que pisca apenas o primeiro dos itens acima (com algum limite configurável).

Identificar uma renderização "barata" ou "rápida" não é tão simples quanto parece, devido a fatores como:

• As compilações de desenvolvimento são muito mais lentas do que as compilações de produção.
• Os laptops do desenvolvedor geralmente são muito mais rápidos do que os laptops do usuário final.

O bom do Profiler é que ele relata a velocidade como relativa, permitindo que você se concentre na parte mais lenta de um aplicativo em qualquer sessão. (Você decide quando a parte mais lenta é rápida o suficiente.) No entanto, isso só pode ser feito em retrospecto.

Ele também dá a você um instantâneo estático dos commits, e quais props / estado mudaram, permitindo que você veja não apenas a frequência com que um determinado componente renderizado (foi mais do que você esperava?), Mas também especificamente _por que_ ele foi renderizado novamente, e o que mais renderizado novamente com ele.

Eu acho que há uma boa chance de podermos adicionar algum tipo de mecanismo de atualização de flash de volta ao DevTools como parte do Profiler. Talvez pisque (como costumava) apenas quando a criação de perfil está ativa? Talvez ele atualize todos os componentes que são renderizados novamente quando você seleciona um novo commit no criador de perfil depois que a criação de perfil é interrompida? (Eu meio que gosto dessa ideia, já que permite que você "repita" se você perdeu alguma coisa.) Precisamos experimentar um pouco e ver o que funciona melhor.

Usei muito esse recurso para ter certeza de que apenas os componentes que deveriam ser renderizados estavam sendo renderizados. Eu tenho um aplicativo que renderiza o mesmo componente, muitas vezes, com ids diferentes, e gosto de ter certeza de que apenas aquele que precisa ser renderizado é renderizado, ao invés de todos eles. Não vejo uma maneira de verificar isso com o novo criador de perfil.

Não vejo uma maneira de verificar isso com o novo criador de perfil

O que você tentou? O criador de perfil deve mostrar claramente se um filho está sendo renderizado novamente ou muitos.

Eu estava usando 'atualizações em destaque' com frequência. Foi o recurso do dev-tools que mais usei. Apenas para ver o que foi atualizado, não com que frequência. Claro, você pode usar o criador de perfil para fazer isso, mas isso é consideravelmente mais complicado do que ter uma indicação visual rápida.

Para mim, "atualizações em destaque" era o "recurso matador" ...

Ouvimos você :-) Não acho que comentários adicionais apenas dizendo "Eu usei isso" vão ajudar significativamente neste tópico, por que vale a pena. Sabemos que há pessoas usando esse recurso e estamos pensando qual seria a maneira certa de trazê-lo de volta. Obrigado pelo feedback!

Essa opção era um componente essencial para meu processo de trabalho diário para indicar o problema de reenvio instantaneamente. Eu ficaria muito feliz se você pudesse trazer esse recurso incrível de volta em breve.

+1 em trazer de volta alguma versão deste recurso que permite uma visão rápida de alto nível de re-renderizações (mesmo para re-renderizações que são totalmente boas como quando atualizamos Contexto).

+1 em trazer de volta

Eu ficaria muito feliz se você pudesse trazer esse recurso incrível de volta em breve.

Conforme solicitado acima:

Não acho que comentários adicionais apenas dizendo "Eu usei isso" vão ajudar significativamente

Para reformular isso de forma mais explícita:

Nós ouvimos você!

Existem muitas pessoas inscritas neste repositório. Não queremos enviá-los com os mesmos comentários a cada poucas horas. Além disso, usamos pessoalmente notificações do GitHub. Se este tópico receber um "+1" todos os dias, eventualmente teremos que cancelar a inscrição para reduzir o ruído. O que provavelmente é o oposto de sua intenção.

Antes de comentar, certifique-se de adicionar algo que não foi dito antes. Se você vir um comentário semelhante ao que deseja escrever, basta adicionar uma reação 👍 a ele.

Obrigado pela compreensão.
Agradecemos seus comentários, mas 👍s são suficientes para ajudar a priorizar tarefas.

que você está adicionando algo que não foi dito antes.

Eu gostaria de perguntar, há uma maneira de instalar a versão anterior da extensão? Na verdade, a atualização quebrou o fluxo, que eu costumava fazer. Infelizmente, o mercado de extensões do Chrome não permite que você instale a versão anterior como 'npm'. Você tem um link com extensão compilada? Obrigada.
_ (Tentei instalar a versão autônoma, mas este link do repositório v3 está quebrado, o link para a extensão do Crome leva à versão mais recente) _

O novo DevTools inclui um Profiler que deve ajudá-lo a encontrar problemas reais de desempenho em seu código.

E aqui está uma resposta, por que a nova extensão interrompeu meu fluxo. O Profiler o incentiva a pressionar os botões para iniciar e, em seguida, para encerrar a criação de perfil, mas não é instantâneo. Com atualizações de realce, você vê tudo sem movimentos extras. Também mostra de uma forma muito intuitiva as atualizações reais e o que realmente foi acionado.

Isso me lembra do próprio monitor de desempenho do Chrome DevTools, que também costumava ser atualizado ao vivo e, então, um dia foi migrado para o botão de gravação. Essa mudança provavelmente fez sentido por causa da complexidade e do impacto no desempenho, mas o ponto é que adiciona um atrito enorme (como @Carduelis aponta, é muito mais fácil não pressionar os botões start / stop). Isso é uma chave para o ciclo OODA e, sem dúvida, afetará a frequência com que os usuários usam esse recurso e, por sua vez, afetará a qualidade do próprio aplicativo.

Não leve a mal - o novo monitor de desempenho é legal e tem seus usos quando você precisa se aprofundar, mas não pode simplesmente substituir as visualizações rápidas e sujas como o realce da atualização antiga.

Eu gostaria de perguntar, há uma maneira de instalar a versão anterior da extensão?

@Carduelis As instruções de instalação para a versão anterior do DevTools são abordadas na postagem do blog de lançamento: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get- a versão antiga de volta

Eu corri em círculos tentando obter a v3 instalada no Chrome a partir das instruções acima, e simplesmente não consegui fazer o criador de perfil autônomo destacar as alterações. Então, fiz instruções detalhadas passo a passo, se você quiser apenas fazer com que funcione e voltar a otimizar seus componentes:

Instalando Reagir Dev Tools V3 (instruções passo-a-passo):
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

Se eu puder reclamar um pouco, embora em um nível técnico possa parecer "ferramentas de perfil em profundidade"> "um recurso de destaque bobo", somos todos apenas humanos e coletamos muitas informações rapidamente a partir de dicas visuais simples, então de certa forma, o recurso de realce é muito importante, exatamente pelo motivo de ser tão fácil de usar. Para mim, é a razão pela qual abro o React Dev Tools 90% das vezes.

Se eu puder reclamar um pouco, embora em um nível técnico possa parecer como "ferramentas de perfil em profundidade"> "um recurso de destaque bobo", somos todos apenas humanos e coletamos muitas informações rapidamente a partir de dicas visuais simples, então de certa forma, o recurso de realce é muito importante, exatamente pelo motivo de ser tão fácil de usar.

Não acho que Dan ou eu tenhamos debatido que é "mais fácil de usar", apenas que pode encorajar as pessoas a investir tempo em "consertar" coisas que não estão "quebradas" (também conhecido como otimização excessiva de coisas que não são lentas) . Já vimos esse padrão antes com coisas como evitar amplamente as funções inline por causa dos temidos custos de "desempenho". Energia investida para consertar não-problemas é a energia que não é gasta consertando outras coisas potencialmente mais importantes.

Como dissemos acima , acho que há uma boa chance de adicionarmos algum tipo de mecanismo de atualização de flash de volta ao DevTools como parte do Profiler.

Realisticamente, não é a coisa mais prioritária no meu prato, então vou pedir paciência em vez de repetir esta conversa. Ouvimos e reconhecemos que esse recurso é importante. Tentaremos comparar a conveniência com as outras considerações mencionadas acima e chegar a algo mais do que temos atualmente.

A ponto de otimizar demais, posso atestar que o destaque da renderização visual pode encorajar isso. Portanto, gostaria de acrescentar algo à discussão aqui.

Para aqueles que sentem falta do recurso, você pode encontrar https://github.com/welldone-software/why-did-you-render mais informativo.

Isso pode ser algo a considerar quando este recurso for implementado. Por padrão, WhyDidYouRender faz uma comparação de valor profunda e apenas relata quando as coisas não mudaram realmente entre as novas renderizações. Seria ótimo ter essa mesma filtragem nos destaques de renderização visual. Isso direcionaria otimizações mais ponderadas (além de ser uma distinção não oferecida pelo criador de perfil).

Em teoria, deveria ser possível renderizar o aplicativo inteiro sem preocupação com o desempenho, portanto, adicionar SCU em todos os lugares para evitar ver o realce de renderização é um caminho contraproducente.

Ainda achei o realce da renderização útil para demonstrações de como o React funciona.

Por padrão, WhyDidYouRender faz uma comparação de valor profunda e apenas relata quando as coisas não mudaram realmente entre as novas renderizações.

Isso parece muito lento para aplicativos que realmente têm problemas de desempenho. Qualquer tipo de comparação profunda certamente não é algo que gostaríamos de fazer sempre. No momento em que você o está ativando (para optar por um desempenho mais lento), por que não iniciar o Profiler?

Isso direcionaria otimizações mais ponderadas (além de ser uma distinção não oferecida pelo criador de perfil).

O Profiler fornece uma versão disso:

Se você vir um componente que foi renderizado novamente, mas não teve nenhum adereço / estado / ganchos alterados, acho que é isso que você está descrevendo.

@bvaughn Bem, geralmente você só
Isso é muito inteligente e super útil, mas é algo que você precisa cavar.

@bvaughn Eu amo o "Por que isso renderizou?" recurso (entretanto, enquanto Highlight Updates é repensado), mas depois de ler toda a documentação disponível e folhear seu tutorial do youtube, ainda não tenho certeza de como interpretá-lo em alguns casos:

Não é intuitivo o que o sublinhado significa:

Por que isso foi renderizado?

• adereços alterados: (__)

Eu só uso a API de ganchos, mas ainda não tenho certeza do significado:

Por que isso foi renderizado?

• Ganchos trocados

Alguma chance de haver uma frase ou duas explicações para esses casos e talvez outros que ainda não encontrei além do caso óbvio em que lista os props / state reais que mudaram?

Não é intuitivo o que o sublinhado significa:

Parece que algo em seu aplicativo está passando por um prop chamado __ e esse prop está mudando entre os commits 😄

Eu só uso a API de ganchos, mas ainda não tenho certeza do significado

Por favor, veja # 16477

Oi

Eu estava usando muito as atualizações de destaque. Estou desenvolvendo um aplicativo que sempre atualiza e esse futuro foi essencial para o meu dia a dia de trabalho.

Recebo a solução apresentada por @bvaughn . É muito útil, mas não posso aplicá-lo ao meu cenário por causa da taxa de atualização. Preciso de uma indicação rápida em vez de uma ferramenta de perfil, que parece incrível, aliás.

Você ainda vai implementar isso de volta ?? Se não, como posso fazer o downgrade de minhas React Dev Tools, porque simplesmente não consigo desenvolver sem elas.

Você ainda vai implementar isso de volta ?? Se não, como posso fazer o downgrade de minhas React Dev Tools, porque simplesmente não consigo desenvolver sem elas.

Já respondido por @oztune.

Como faço para recuperar a versão antiga?
https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the-old-version-back

Eu quero a versão antiga de volta, por favor. Há tantas funcionalidades perdidas no novo e são impossivelmente inúteis

Eu quero a versão antiga de volta, por favor. Há tantas funcionalidades perdidas no novo e são impossivelmente inúteis

Veja como obter a versão antiga de volta, funcionou para mim:
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

HI @einarq, na verdade, eu adoraria ter alguma funcionalidade faltando na nova versão. Vejo muitas coisas novas legais, mas algumas das antigas são cruciais e não entendi da maneira como foram removidas. Para verificar os rerenders agora, coloquei um log do console na função de renderização para detectar se estou reduzindo o número de rerenders ou não. Não é ideal, mas funciona. A versão anterior estava tornando isso ridiculamente fácil e útil porque também me mostra outros renderizadores desnecessários que eu poderia identificar. Agora, isso é doloroso.

Coloque essas funcionalidades ausentes de volta na nova versão.

Na minha palavra, nova versão significa que você tem: redesenho e melhorias da anterior e novos futuros adicionados. Não removido e adicionado nova funcionalidade que é diferente da anterior.

Além disso, por que agora não posso alterar os valores de estado ??

E os adereços booleanos não são mais caixas de seleção ?? Isso foi tão legal. E novamente se foi.

Agora o estado não pode ser alterado e os adereços eu tenho que digitar falso / verdadeiro em vez de apenas clicar e ver como um componente está reagindo a isso.

Super irritante.

Olá @PMustard ,

Eu não trabalho nisso, eu estava apenas sugerindo uma abordagem potencial para trazer de volta a versão antiga das ferramentas de desenvolvimento se você não gostar da nova. Funcionou para mim

Tenho certeza de que a equipe que trabalha nas ferramentas de desenvolvimento (principalmente Brian Vaughn, eu acho?) Levaria suas preocupações em consideração se você criar alguns problemas separados para eles.

E não se esqueça de mostrar algum apreço também. Estamos recebendo essas ferramentas gratuitamente :)
Feedback construtivo apenas.

Cumprimentos,

Einar

Se você precisar desse recurso com urgência, pode usar uma versão antiga como solução alternativa: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the -old-version-back. Também encorajo você a tentar usar o Profiler. Mesmo que seja um pouco mais trabalhoso para executar, ele informa quais re-renderizações são importantes e quais não são. Apenas contar os números de renderização costuma ser uma distração dos problemas reais de desempenho.

Entendemos que é valioso ter uma maneira leve de detectar reprocessadores inesperados. Explicamos em https://github.com/facebook/react/issues/16437#issuecomment -523629000 que isso está em nosso radar e que mais comentários dizendo “Eu preciso disso” não são úteis. Uma vez que este tópico continuou a coletar comentários do tipo "Eu preciso disso", vou bloqueá-lo para reduzir a inundação de notificações. Tenha certeza de que sua voz será ouvida.

Implementei esse recurso no novo DevTools (# 16989) com as seguintes ressalvas:

• Ele só está habilitado na extensão do navegador (e no pacote react-devtools-inline NPM) por enquanto, portanto, ele só suporta React DOM.
• Não é implementado para renderizadores legados (v15), embora possa ser adicionado por alguém se quiser enviar um PR de acompanhamento.

Fechando este problema agora que o # 16989 está pousando. Provavelmente lançará 4.2 com o novo recurso hoje.