React: Devtools V4 : Où sont les mises à jour de surbrillance ?

Même problème ici. Les mises à jour de surbrillance ont disparu.
Je me demandais s'il fallait utiliser Profiler maintenant pour suivre les mises à jour ?

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

La réponse honnête est que nous n'avons pas eu le temps de l'implémenter et que nous ne l'avons pas considéré comme suffisamment important pour empêcher la publication de toutes les autres fonctionnalités.

Cependant, il y a des raisons plus profondes pour lesquelles nous ne sommes pas sûrs de le rajouter. Cela contribue à la fausse idée que les rendus en eux-mêmes sont mauvais (ils ne le sont pas s'ils sont bon marché). Les gens passent donc du temps à optimiser des choses inutiles et à ignorer les problèmes de performances réels.

Le nouveau DevTools inclut un profileur qui devrait vous aider à trouver les problèmes de performances réels dans votre code. Je comprends le désir d'un moyen ultra léger de trouver des rendus supplémentaires - et nous l'ajouterons peut-être - mais nous devrons d'abord réfléchir davantage à la façon dont cela devrait fonctionner.

Modifié pour ajouter un commentaire en ligne

Quelques discussions précédentes connexes https://github.com/bvaughn/react-devtools-experimental/issues/244

Highlight Updates a été très utile non pas pour résoudre les problèmes de performances (le nouveau Profiler est bien meilleur à cela), mais pour découvrir des rendus surprenants. Cela nous a fait gagner un nombre incalculable de fois, en particulier lorsque nous travaillons avec Context, où un changement peut entraîner des rendus dans d'autres parties de l'application. Lorsque vous travaillez sur le profileur, vous avez tendance à vous concentrer uniquement sur une partie de l'arbre, les régressions sont donc faciles à manquer.

Je comprends les inquiétudes de

1. Choisissez la couleur du contour en fonction de la durée du rendu

Les rendus bon marché doivent être verts, les rendus coûteux doivent être jaunes ou rouges. Ou utilisez simplement les mêmes couleurs que celles utilisées par le profileur.

2. Variez la vitesse de fondu du contour

L'animation de fondu de contour doit être relative à la durée du rendu. Les rendus rapides devraient s'estomper immédiatement, les rendus lents devraient s'estomper plus lentement.

3. Différencier les zones repeintes

J'ai parfois utilisé Highlight Updates avec le Paint Flashing Chrome. Cela a rendu les rendus qui ont conduit à repeindre pour être mis en évidence différemment des rendus qui n'avaient pas d'effet DOM. Je pense que DevTools devrait avoir une fonction similaire intégrée.

• Un rendu coûteux sans repeint devrait être la cible principale des optimisations de performances.
• Les enduits qui repeignent font évidemment du travail qui doit être fait.
• Les rendus rapides qui n'entraînent aucune repeinture sont acceptables à ignorer.

Peut-être même avoir un paramètre qui ne fait clignoter que le premier des éléments ci-dessus (avec un seuil configurable).

L'identification d'un rendu "bon marché" ou "rapide" n'est pas aussi simple qu'il y paraît, en raison de facteurs tels que :

• Les versions de développement sont beaucoup plus lentes que les versions de production.
• Les ordinateurs portables des développeurs sont généralement beaucoup plus rapides que les ordinateurs portables des utilisateurs finaux.

L'avantage du Profiler est qu'il rapporte la vitesse comme relative, ce qui vous permet de vous concentrer sur la partie la plus lente d'une application dans une session donnée. (Vous décidez quand la partie la plus lente est assez rapide.) Cependant, cela ne peut être fait que rétrospectivement.

Il vous donne également un instantané statique des commits, et quels accessoires/états ont changé, vous permettant de voir non seulement à quelle fréquence un composant particulier a été rendu (était-ce plus que ce à quoi vous vous attendiez ?) re-rendu avec.

Je pense qu'il y a de fortes chances que nous examinions l'ajout d'un mécanisme de mise à jour clignotant à DevTools dans le cadre de Profiler. Peut-être qu'il ne clignote (comme avant) que lorsque le profilage est actif ? Peut-être qu'il fait clignoter chaque composant qui a été rendu à nouveau lorsque vous sélectionnez un nouveau commit dans le profileur après l'arrêt du profilage ? (J'aime bien cette idée, car elle vous permet de « rejouer » si vous avez manqué quelque chose.) Nous devons l'expérimenter un peu et voir ce qui fonctionne le mieux.

J'ai beaucoup utilisé cette fonctionnalité pour m'assurer que seuls les composants qui devaient être rendus étaient rendus. J'ai une application qui rend le même composant plusieurs fois, avec des identifiants différents, et j'aime m'assurer que seul celui qui doit être restitué est rendu, plutôt que tous. Je ne vois pas de moyen de vérifier cela avec le nouveau profileur.

Je ne vois pas de moyen de vérifier cela avec le nouveau profileur

Qu'as-tu essayé? Le profileur doit clairement montrer si un enfant est en train de restituer ou plusieurs.

J'utilisais fréquemment les « mises à jour en surbrillance ». C'était la fonctionnalité des outils de développement que j'utilisais le plus. Juste pour voir ce qui a été mis à jour, pas à quelle fréquence. Bien sûr, vous pouvez utiliser le profileur pour le faire, mais c'est considérablement plus lourd que d'avoir une indication visuelle rapide.

Pour moi, "Surligner les mises à jour" était la "fonctionnalité qui tue"...

Nous vous entendons :-) Je ne pense pas que d'autres commentaires disant simplement "J'ai utilisé ceci" vont aider de manière significative dans ce fil, pour ce que ça vaut. Nous savons que des personnes utilisent cette fonctionnalité et réfléchissons à la bonne façon de la rétablir. Merci pour vos commentaires !

Cette option était un élément essentiel de mon processus de travail quotidien pour indiquer instantanément le problème de rendu. Je serais donc très heureux si vous pouviez ramener cette fonctionnalité géniale bientôt.

+1 sur le retour d'une version de cette fonctionnalité qui permet une vue rapide de haut niveau des rendus (même pour les rendus qui sont tout à fait corrects comme lorsque nous mettons à jour Context).

+1 au retour

Je serais donc très heureux si vous pouviez ramener cette fonctionnalité géniale bientôt.

Comme demandé ci-dessus :

Je ne pense pas que d'autres commentaires disant simplement "J'ai utilisé ceci" vont considérablement aider

Pour reformuler plus explicitement :

Nous vous entendons!

De nombreuses personnes sont abonnées à ce référentiel. Nous ne voulons pas les spammer avec les mêmes commentaires toutes les quelques heures. De plus, nous utilisons personnellement les notifications GitHub. Si ce fil est renvoyé tous les jours avec un "+1", nous devrons éventuellement nous en désabonner pour réduire le bruit. Ce qui est probablement le contraire de votre intention.

Avant de commenter, assurez-vous d'ajouter quelque chose qui n'a pas été dit auparavant. Si vous voyez un commentaire similaire à ce que vous vouliez écrire, ajoutez simplement une réaction 👍 à la place.

Merci de votre compréhension.
Nous apprécions vos commentaires, mais les s sont suffisants pour aider à hiérarchiser les tâches.

que vous ajoutez quelque chose qui n'a pas été dit auparavant.

Je voudrais demander, y a-t-il un moyen d'installer la version précédente de l'extension ? En fait, la mise à jour a interrompu le flux, comme j'en avais l'habitude. Malheureusement, le marché des extensions Chrome ne vous permet pas d'installer la version précédente comme 'npm'. Avez-vous un lien avec l'extension compilée ? Merci.
_(J'ai essayé d'installer la version autonome, mais ce lien du référentiel v3 est rompu, le lien vers l'extension Crome mène à la version la plus récente)_

Le nouveau DevTools inclut un profileur qui devrait vous aider à trouver les problèmes de performances réels dans votre code.

Et voici une réponse, pourquoi la nouvelle extension a cassé mon flux. Profiler vous encourage à appuyer sur les boutons pour démarrer, puis pour terminer le profilage, mais ce n'est pas instantané. Avec le surligneur de mises à jour, vous voyez tout sans mouvements supplémentaires. Il vous montre également de manière très intuitive les mises à jour réelles et ce qui a réellement été déclenché.

Cela me rappelle le propre moniteur de performances de Chrome DevTools, qui était également mis à jour en direct , puis a été migré un jour vers press-to-record . Ce mouvement avait probablement du sens en raison de la complexité et de l'impact sur les performances, mais le fait est qu'il ajoute d'énormes frictions (comme le souligne @Carduelis , il est beaucoup plus facile de ne pas appuyer sur les boutons marche/arrêt). Cela jette une clé dans la boucle OODA et affectera sans aucun doute la fréquence à laquelle les utilisateurs utilisent cette fonctionnalité, et à son tour affectera la qualité de l'application elle-même.

Ne le prenez pas mal --- le nouveau moniteur de performances est cool et a son utilité lorsque vous avez besoin de creuser en profondeur, mais il ne peut pas simplement remplacer les visualisations rapides et sales comme l'ancienne mise en évidence des mises à jour.

Je voudrais demander, y a-t-il un moyen d'installer la version précédente de l'extension ?

Les instructions d'installation de @Carduelis pour la version précédente de DevTools sont décrites dans l'article de blog de la version : https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get- l'ancienne-version-retour

J'ai un peu tourné en rond en essayant d'installer la v3 dans Chrome à partir des instructions ci-dessus, et je n'ai tout simplement pas pu obtenir le profileur autonome pour mettre en évidence les modifications. J'ai donc fait des instructions détaillées étape par étape si vous voulez juste le faire fonctionner et revenir à l'optimisation de vos composants :

Installation de React Dev Tools V3 (instructions pas à pas) :
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

Si je peux me permettre un petit coup de gueule, bien que sur le plan technique, cela puisse sembler être des "outils de profilage approfondis" > "une fonctionnalité de mise en évidence idiote", nous ne sommes tous que des humains et nous glanons rapidement beaucoup d'informations à partir de simples repères visuels, donc à certains égards, la fonction de surbrillance est un gros problème exactement pour la raison qu'elle est si facile à utiliser. Pour moi, c'est la raison pour laquelle j'ouvre React Dev Tools 90% du temps.

Si je peux me permettre un petit coup de gueule, bien que sur le plan technique, cela puisse sembler être des "outils de profilage approfondis" > "une fonctionnalité de mise en évidence idiote", nous ne sommes tous que des humains et nous glanons rapidement beaucoup d'informations à partir de simples repères visuels, donc à certains égards, la fonction de surbrillance est un gros problème exactement pour la raison qu'elle est si facile à utiliser.

Je ne pense pas que Dan ou moi-même avons débattu du fait que c'est "plus facile à utiliser", juste que cela pourrait encourager les gens à investir du temps dans "réparer" les choses qui ne sont pas "cassés" (c'est-à-dire sur l'optimisation des choses qui ne sont pas lentes) . Nous avons déjà vu ce modèle avec des choses comme l'évitement généralisé des fonctions en ligne en raison des coûts de « performance » redoutés. L'énergie investie dans la résolution des non-problèmes est une énergie qui n'est pas dépensée pour régler d'autres choses potentiellement plus importantes.

Comme nous l'avons dit ci -

En réalité, ce n'est pas la chose la plus prioritaire dans mon assiette, donc je vais demander de la patience plutôt que de répéter cette conversation. Nous entendons et reconnaissons que cette fonctionnalité est importante. Nous essaierons de comparer la commodité aux autres considérations mentionnées ci-dessus et de proposer quelque chose de plus que ce que nous avons actuellement.

Au point de sur-optimiser, je peux attester que la mise en évidence du rendu visuel peut encourager cela. Par conséquent, je voudrais ajouter quelque chose à la discussion ici.

Pour ceux qui manquent la fonctionnalité, vous pouvez trouver https://github.com/welldone-software/why-did-you-render plus informatif.

Cela peut être quelque chose à considérer lorsque cette fonctionnalité est implémentée. Par défaut, WhyDidYouRender effectue une comparaison approfondie des valeurs et ne signale que lorsque les choses n'ont pas réellement changé entre les rendus. Ce serait formidable d'avoir ce même filtrage sur les hautes lumières du rendu visuel. Cela dirigerait des optimisations plus réfléchies (de plus, c'est une distinction non offerte par le profileur).

En théorie, il devrait être possible de restituer l'intégralité de l'application sans problème de performances, donc l'ajout de SCU partout pour éviter de voir la mise en évidence du rendu est un chemin contre-productif.

J'ai toujours trouvé le surlignage de rendu utile pour les démonstrations sur le fonctionnement de React.

Par défaut, WhyDidYouRender effectue une comparaison approfondie des valeurs et ne signale que lorsque les choses n'ont pas réellement changé entre les rendus.

Cela semble très lent pour les applications qui ont réellement des problèmes de performances. Toute sorte de comparaison approfondie n'est certainement pas quelque chose que nous voudrions toujours faire. Au moment où vous l'allumez (pour opter pour des performances plus lentes), pourquoi ne pas simplement démarrer le profileur ?

Cela dirigerait des optimisations plus réfléchies (de plus, c'est une distinction non offerte par le profileur).

Le profileur fournit une version de ceci :

Si vous voyez un composant qui a été rendu à nouveau, mais n'a pas modifié les accessoires/états/crochets, c'est ce que vous décrivez, je pense.

@bvaughn Eh bien, vous
C'est assez astucieux et super utile, mais c'est quelque chose que vous devez creuser.

@bvaughn J'adore le "Pourquoi ce rendu ?" fonctionnalité (dans l'intervalle pendant que Highlight Updates est repensé), mais après avoir lu toute la documentation disponible et parcouru votre didacticiel youtube, je ne sais toujours pas comment l'interpréter pour quelques cas :

Ce que signifie le trait de soulignement n'est pas intuitif :

Pourquoi ce rendu ?

• accessoires modifiés : (__)

Je n'utilise que les hooks api, mais toujours pas certain de la signification :

Pourquoi ce rendu ?

• Crochets changés

Y a-t-il une chance qu'il y ait une phrase ou deux explications pour ces cas et peut-être d'autres que je n'ai pas encore rencontrés à part le cas évident où il répertorie les props / state réels qui ont changé ?

Ce que signifie le trait de soulignement n'est pas intuitif :

On dirait que quelque chose dans votre application passe dans une prop nommée __ et que cette prop change entre les commits 😄

Je n'utilise que les crochets api, mais toujours pas certain de la signification

S'il vous plaît voir #16477

salut

J'utilisais beaucoup les mises à jour de surbrillance. Je développe une application fréquemment rafraîchissante et cet avenir était essentiel pour moi dans mon travail quotidien.

J'obtiens la solution que

Allez-vous toujours mettre en œuvre ce retour ?? Sinon, comment puis-je rétrograder mes outils de développement React, car je ne peux tout simplement pas développer sans.

Allez-vous toujours mettre en œuvre ce retour ?? Sinon, comment puis-je rétrograder mes outils de développement React, car je ne peux tout simplement pas développer sans.

Déjà répondu par @oztune.

Comment récupérer l'ancienne version ?
https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the-old-version-back

Je veux récupérer l'ancienne version s'il vous plaît. Il y a tellement de fonctionnalités qui ont été perdues dans le nouveau et c'est incroyablement inutile

Je veux récupérer l'ancienne version s'il vous plaît. Il y a tellement de fonctionnalités qui ont été perdues dans le nouveau et c'est incroyablement inutile

Voici comment récupérer l'ancienne version, a fonctionné pour moi:
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

Salut @einarq, en fait, j'aimerais avoir des fonctionnalités manquantes dans la nouvelle version. Je vois beaucoup de nouvelles choses intéressantes, mais certaines des anciennes sont cruciales et je ne les comprends pas comme elles ont été supprimées. Pour vérifier les rendus maintenant, je mets une fonction de rendu de connexion à la console pour déterminer si je réduis le nombre de rendus ou non. Ce n'est pas idéal mais ça marche. La version précédente rendait cela ridiculement facile et utile car elle me montre également d'autres rendus inutiles que je pouvais repérer. Maintenant, c'est juste douloureux.

Veuillez remettre ces fonctionnalités manquantes dans la nouvelle version.

Dans mon mot, la nouvelle version signifie que vous avez : une refonte et des améliorations de l'ancienne et de nouveaux futurs ajoutés. Non supprimé et ajouté de nouvelles fonctionnalités différentes de la précédente.

Aussi pourquoi je ne peux pas changer maintenant les valeurs d'état ??

Et les accessoires booléens ne sont plus des cases à cocher ?? C'était tellement cool. Et encore disparu.

Maintenant, l'état ne peut pas être modifié et les accessoires que je dois taper faux/vrai à la place, cliquez simplement et voyez comment un composant réagit à cela.

Hyper ennuyeux.

Salut @PMustard ,

Je ne travaille pas là-dessus, je suggérais juste une approche potentielle pour ramener l'ancienne version des outils de développement si vous n'aimez pas la nouvelle. Cela a fonctionné pour moi.

Je suis sûr que l'équipe travaillant sur les outils de développement (principalement Brian Vaughn, je suppose ?) prendrait vos préoccupations en considération si vous leur créiez des problèmes séparés.

Et n'oubliez pas de montrer une certaine appréciation ainsi. Nous obtenons ces outils gratuitement :)
Commentaires constructifs uniquement.

Salutations,

Einar

Si vous avez un besoin urgent de cette fonctionnalité, vous pouvez utiliser une ancienne version comme solution de contournement : https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the -ancienne-version-arrière. Je vous encourage également à essayer d'utiliser le Profiler. Même si l'exécution demande un peu plus d'efforts, elle vous indique quels rendus sont importants et lesquels ne le sont pas. Le simple fait de compter les nombres de rendu est souvent une distraction des problèmes de performances réels.

Nous comprenons qu'il est précieux d'avoir un moyen léger de repérer les rendus inattendus. Nous avons expliqué dans https://github.com/facebook/react/issues/16437#issuecomment -523629000 que cela est sur notre radar et que plus de commentaires disant « J'ai besoin de ça » ne sont pas utiles. Étant donné que ce fil a néanmoins continué à recueillir des commentaires « J'ai besoin de ça », je vais le verrouiller pour réduire le flot de notifications. Soyez assuré que votre voix est entendue.

J'ai implémenté cette fonctionnalité dans le nouveau DevTools (#16989) avec les mises en garde suivantes :

• Il n'est activé que dans l'extension du navigateur (et le package react-devtools-inline NPM) pour le moment, il ne prend donc en charge que React DOM.
• Il n'est pas implémenté pour les moteurs de rendu hérités (v15), bien qu'il puisse être ajouté par quelqu'un s'il souhaite soumettre un PR de suivi.

Fermeture de ce problème maintenant que #16989 débarque. Sortira probablement 4.2 avec la nouvelle fonctionnalité aujourd'hui.