React: Devtools V4: где основные обновления?

Здесь та же проблема. Выделить обновления ушел.
Мне было интересно, нужно ли сейчас использовать Profiler для отслеживания обновлений?

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

Честно говоря, у нас не было времени на его реализацию, и мы не считали его достаточно важным, чтобы заблокировать выпуск всех других функций.

Однако есть более глубокие причины, по которым мы не уверены, что добавим его обратно. Это способствует неправильному представлению о том, что повторный рендеринг сам по себе плох (это не так, если он дешевый). Поэтому люди тратят время на оптимизацию бесполезных вещей и упускают из виду реальные проблемы с производительностью.

Новый DevTools включает профилировщик, который должен помочь вам найти реальные проблемы с производительностью в вашем коде. Я понимаю стремление к сверхлегкому способу поиска дополнительных рендеров - и, возможно, мы добавим это, - но сначала нам нужно больше подумать о том, как это должно работать.

Отредактировано для добавления встроенного комментария

Некоторое связанное с этим предыдущее обсуждение https://github.com/bvaughn/react-devtools-experimental/issues/244

Highlight Updates был очень полезен не столько для исправления проблем с производительностью (новый Profiler намного лучше в этом), сколько для обнаружения неожиданных рендеров. Это спасло нас бесчисленное количество раз, особенно при работе с Context, когда одно изменение может вызвать повторный рендеринг в других частях приложения. При работе с Profiler вы, как правило, сосредотачиваетесь только на части дерева, поэтому регрессии легко пропустить.

Я понимаю опасения @gaearon по поводу неправильной идеи, так что как насчет:

1. Выберите цвет контура в зависимости от продолжительности рендеринга.

Дешевые рендеры должны быть зелеными, дорогие - желтыми или красными. Или просто используйте те же цвета, что и Профилировщик.

2. Варьируйте скорость затухания контура.

Анимация затухания контура должна относиться к продолжительности рендеринга. Быстрые рендеры должны исчезать немедленно, медленные - медленнее.

3. Разграничивайте перекрашенные участки.

Я иногда использовал Highlight Updates с Paint Flashing Chrome. Это сделало рендеры, которые приводили к перерисовке, выделялись иначе, чем рендеры, не имевшие эффекта DOM. Я думаю, что в DevTools должна быть встроена аналогичная функция.

• Дорогой рендер без перерисовки должен быть основной целью оптимизации производительности.
• Очевидно, что перерисовываемые рендеры делают некоторую работу, которую необходимо выполнить.
• Быстрые рендеры, которые не приводят к перерисовке, можно игнорировать.

Возможно, даже есть параметр, который мигает только первым из вышеперечисленных (с некоторым настраиваемым порогом).

Определить "дешевый" или "быстрый" рендер не так просто, как кажется, из-за таких факторов, как:

• Сборки для разработки выполняются намного медленнее, чем для производственных.
• Ноутбуки разработчиков, как правило, намного быстрее ноутбуков конечных пользователей.

Хорошая особенность Profiler заключается в том, что он сообщает скорость как относительную, что позволяет вам сосредоточиться на самой медленной части приложения в любом конкретном сеансе. (Вы сами решаете, когда самая медленная часть будет достаточно быстрой.) Это можно сделать только ретроспективно.

Он также дает вам статический снимок коммитов и измененные свойства / состояние, позволяя вам видеть не только, как часто рендерится конкретный компонент (было ли это больше, чем вы ожидали?), Но также конкретно _почему_ он рендерится повторно и что еще рендеринг с ним.

Я думаю, есть большая вероятность, что мы могли бы рассмотреть возможность добавления какого-то механизма обновления прошивки обратно в DevTools как часть Profiler. Может, мигает (как раньше) только при активном профилировании? Может быть, он мигает каждый компонент, который повторно отрисовывается, когда вы выбираете новую фиксацию в профилировщике после остановки профилирования? (Мне отчасти нравится эта идея, поскольку она позволяет «воспроизвести» что-то, если вы что-то пропустили.) Нам нужно немного поэкспериментировать с этим и посмотреть, что работает лучше всего.

Я часто использовал эту функцию, чтобы убедиться, что визуализируются только те компоненты, которые должны отображаться. У меня есть приложение, которое отрисовывает один и тот же компонент много раз с разными идентификаторами, и мне нравится следить за тем, чтобы рендерировался только тот, который нужно перерисовать, а не все они. Я не вижу возможности проверить это с помощью нового профилировщика.

Я не вижу способа проверить это с помощью нового профилировщика

Что ты пробовал? Профилировщик должен четко показывать, выполняется ли повторный рендеринг: один дочерний элемент или несколько.

Я часто использовал функцию «Выделить обновления». Это была особенность dev-tools, которую я использовал больше всего. Просто чтобы увидеть, что обновлялось, а не как часто. Конечно, вы можете использовать профилировщик для этого, но это значительно сложнее, чем иметь быструю визуальную индикацию.

Для меня «Основные обновления» были «убийственной особенностью» ...

Мы вас слышим :-) Я не думаю, что дальнейшие комментарии, просто говоря «Я использовал это», существенно помогут в этой теме, чего бы это ни стоило. Мы знаем, что есть люди, использующие эту функцию, и думаем, что было бы правильным способом вернуть ее обратно. Спасибо за отзыв!

Эта опция была важным компонентом моего повседневного рабочего процесса, чтобы мгновенно указать на проблему с повторной визуализацией. Так что я был бы очень рад, если вы сможете вернуть эту замечательную функцию в ближайшее время.

+1 за возвращение некоторой версии этой функции, которая обеспечивает быстрый высокоуровневый просмотр повторных рендеров (даже для повторных рендерингов, которые совершенно нормальны, например, когда мы обновляем Context).

+1 за возвращение

Так что я был бы очень рад, если вы сможете вернуть эту замечательную функцию в ближайшее время.

Как просили выше:

Я не думаю, что дальнейшие комментарии со словами «Я использовал это» существенно помогут

Чтобы перефразировать это более явно:

Мы вас слышим!

На этот репозиторий подписано много людей. Мы не хотим рассылать им одни и те же комментарии каждые несколько часов. Кроме того, мы лично используем уведомления GitHub. Если этот поток каждый день получает «+1», нам в конечном итоге придется отказаться от подписки, чтобы уменьшить шум. Что, скорее всего, прямо противоположно вашему намерению.

Перед тем, как комментировать, убедитесь, что вы добавляете то, о чем раньше не говорили. Если вы видите комментарий, похожий на то, что вы хотели написать, просто добавьте к нему реакцию 👍.

Спасибо за понимание.
Мы ценим ваши отзывы, но их достаточно, чтобы помочь расставить приоритеты.

что вы добавляете то, о чем раньше не говорили.

Хочу спросить, а есть ли возможность установить предыдущую версию расширения? Собственно, апдейт сломал тот поток, к которому я привык. К сожалению, торговая площадка расширений Chrome не позволяет установить предыдущую версию, например npm. У вас есть ссылка на скомпилированное расширение? Спасибо.
_ (Я пытался установить автономную версию, но эта ссылка из репозитория v3 не работает, ссылка на расширение Crome ведет к последней версии) _

Новый DevTools включает профилировщик, который должен помочь вам найти реальные проблемы с производительностью в вашем коде.

И вот ответ, почему новое расширение сломало мой поток. Профилировщик рекомендует нажимать кнопки для начала, а затем для завершения профилирования, но это происходит не мгновенно. С подсветкой обновлений вы видите все без лишних ходов. Он также очень интуитивно показывает фактические обновления и то, что на самом деле было запущено.

Это напоминает мне собственный монитор производительности Chrome DevTools, который раньше тоже @Carduelis, гораздо проще не нажимать кнопки запуска / остановки). Это бросает вызов циклу OODA и, несомненно, повлияет на то, как часто пользователи используют эту функцию, и, в свою очередь, повлияет на качество самого приложения.

Не поймите это неправильно - новый монитор производительности - это круто, и его можно использовать, когда вам нужно копнуть глубже, но он не может просто заменить быстрые и грязные визуализации, такие как выделение старых обновлений.

Хочу спросить, а есть ли возможность установить предыдущую версию расширения?

@Carduelis Инструкции по установке предыдущей версии DevTools описаны в сообщении блога о выпуске: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get- the-old-version-back

Я немного бегал по кругу, пытаясь установить v3 в Chrome из приведенных выше инструкций, и просто не мог заставить автономный профилировщик выделять изменения. Итак, я сделал подробные пошаговые инструкции, если вы просто хотите заставить его работать и вернуться к оптимизации ваших компонентов:

Установка React Dev Tools V3 (пошаговая инструкция) :
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

Могу я немного разглагольствовать, хотя на техническом уровне это может показаться «инструментами углубленного профилирования»> «глупой функцией выделения», мы все просто люди и быстро черпаем много информации из простых визуальных подсказок, поэтому В некотором смысле функция выделения является довольно важной именно по той причине, что ее так легко использовать. Для меня это причина, по которой я открываю React Dev Tools 90% времени.

Могу я немного разглагольствовать, хотя на техническом уровне это может показаться «инструментами углубленного профилирования»> «глупой функцией выделения», мы все просто люди и быстро черпаем много информации из простых визуальных подсказок, поэтому В некотором смысле функция выделения является довольно важной именно по той причине, что ее так легко использовать.

Я не думаю, что мы с Дэном спорили о том, что это «проще в использовании», просто это может побудить людей тратить время на «починку» вещей, которые не «ломаются» (то есть чрезмерной оптимизации вещей, которые не медленные). . Мы уже видели этот паттерн с такими вещами, как повсеместное избегание встроенных функций из-за опасений, связанных с "производительностью". Энергия, вложенная в устранение неполадок, - это энергия, которая не тратится на устранение других потенциально более важных вещей.

Как мы уже говорили выше , я думаю, что есть большая вероятность, что мы могли бы добавить какой-то механизм обновления прошивки обратно в DevTools как часть Profiler.

На самом деле это не самая важная вещь в моей тарелке, поэтому я попрошу терпения, а не повторять этот разговор. Мы слышим и признаем, что эта функция важна. Мы постараемся сопоставить удобство с другими соображениями, упомянутыми выше, и придумаем что-то большее, чем то, что у нас есть в настоящее время.

Что касается чрезмерной оптимизации, я могу засвидетельствовать, что визуальная подсветка рендеринга может этому способствовать. Поэтому я хотел бы кое-что добавить к обсуждению здесь.

Для тех, кто пропустил эту функцию, вы можете найти https://github.com/welldone-software/why-did-you-render более информативным.

Это может быть что-то, что следует учитывать при реализации этой функции. По умолчанию WhyDidYouRender выполняет глубокое сравнение значений и сообщает только тогда, когда что-то на самом деле не изменилось между повторными рендерингами. Было бы здорово иметь такую ​​же фильтрацию для визуальных бликов отрисовки. Это повлечет за собой более продуманную оптимизацию (плюс это различие, которое профилировщик не предоставляет).

Теоретически должна существовать возможность повторного рендеринга всего приложения без проблем с производительностью, поэтому добавление SCU повсюду, чтобы не видеть подсветку рендеринга, является контрпродуктивным путем.

Я по-прежнему считаю, что выделение rerender полезно для демонстрации того, как работает React.

По умолчанию WhyDidYouRender выполняет глубокое сравнение значений и сообщает только тогда, когда что-то на самом деле не изменилось между повторными рендерингами.

Это звучит очень медленно для приложений, у которых действительно есть проблемы с производительностью. Любое глубокое сравнение - это не то, что мы хотели бы делать всегда. В тот момент, когда вы включаете его (чтобы выбрать более медленную производительность), почему бы просто не запустить Profiler?

Это повлечет за собой более продуманную оптимизацию (плюс это различие, которое профилировщик не предоставляет).

Профилировщик предоставляет такую ​​версию:

Если вы видите компонент, который был повторно отрисован, но не имел никаких измененных свойств / состояний / хуков, я думаю, это то, что вы описываете.

@bvaughn Ну, вы обычно включаете глубокое сравнение только для одного компонента за раз. Я согласен, что это не то, что вы включаете по умолчанию для всех компонентов. Возможно, что-то там, где Вы щелкните правой кнопкой мыши эту зеленую полосу и выберите «выделить обновления рендеринга».
Это довольно красиво и очень полезно, но это то, к чему вам нужно докопаться.

@bvaughn Мне нравится "Почему это рендеринг?" (пока что Highlight Updates переосмысливается), но после прочтения всей доступной документации и беглого просмотра вашего руководства на YouTube я все еще не уверен, как ее интерпретировать для нескольких случаев:

Не совсем понятно, что означает подчеркивание:

Почему это рендеринг?

• реквизиты изменены: (__)

Я использую только api хуков, но до сих пор не уверен в их значении:

Почему это рендеринг?

• Крючки изменены

Есть ли шанс найти одно или два объяснения для этих случаев и, возможно, других, с которыми я еще не сталкивался, кроме очевидного случая, когда в нем перечислены фактические props / state которые изменились?

Не совсем понятно, что означает подчеркивание:

Похоже, что-то в вашем приложении передается в опоре с именем __ и эта опора меняется между коммитами 😄

Я использую только api хуков, но до сих пор не уверен в значении

См. # 16477

Привет

Я много использовал Highlight Updates. Я разрабатываю приложение, которое часто обновляется, и это будущее было важным для меня в моей повседневной работе.

Я получаю решение, которое представил

Вы все еще собираетесь реализовать это обратно ?? Если нет, то как я могу понизить мои инструменты разработки React, потому что я просто не могу развиваться без него.

Вы все еще собираетесь реализовать это обратно ?? Если нет, то как я могу понизить мои инструменты разработки React, потому что я просто не могу развиваться без него.

Уже ответил @oztune.

Как мне вернуть старую версию?
https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the-old-version-back

Я хочу вернуть старую версию, пожалуйста. В новом было так много функций, которые были потеряны, и это невероятно бесполезно.

Я хочу вернуть старую версию, пожалуйста. В новом было так много функций, которые были потеряны, и это невероятно бесполезно.

Вот как вернуть старую версию, у меня сработало:
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

HI @einarq на самом деле, мне бы хотелось, чтобы в новой версии отсутствовала функциональность. Я вижу много хороших новых вещей, но некоторые из старых имеют решающее значение, и я не понимаю, как это было удалено. Чтобы проверить рендеры сейчас, я помещаю консольный журнал в функцию рендеринга, чтобы определить, уменьшаю ли я количество рендеров или нет. Это не идеально, но работает. Предыдущая версия делала это смехотворно простым и полезным, потому что она также показывала мне другие ненужные повторные рендеры, которые я мог заметить. Теперь это просто больно.

Верните недостающие функции в новую версию.

В моем слове новая версия означает, что у вас есть: редизайн и улучшения старой и добавленные новые фьючерсы. Не удалены и добавлены новые функции, которые отличаются от предыдущей.

Также почему я не могу теперь изменить значения состояния ??

И props Booleans больше не являются флажками ?? Это было так круто. И снова ушел.

Теперь состояние не может быть изменено, и мне нужно ввести это false / true вместо этого просто щелкнуть и посмотреть, как компонент на это реагирует.

Супер раздражает.

Привет @PMustard!

Я не работаю над этим, я просто предлагал один потенциальный подход, чтобы вернуть старую версию инструментов разработчика, если вам не нравится новая. У меня это сработало.

Я уверен, что команда, работающая над инструментами разработки (в основном, Брайан Вон, я полагаю?), Учтет ваши опасения, если вы создадите для них отдельные проблемы.

И не забудьте также выразить признательность. Мы получаем эти инструменты бесплатно :)
Только конструктивная обратная связь.

С уважением,

Эйнар

Если вам срочно нужна эта функция, вы можете использовать старую версию в качестве временного решения: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the -old-version-back. Я также рекомендую вам попробовать использовать Profiler. Несмотря на то, что для запуска требуется немного больше усилий, он сообщает вам, какие повторные рендеры важны, а какие нет. Простой подсчет количества рендеров часто отвлекает от реальных проблем с производительностью.

Мы понимаем, что очень важно иметь легкий способ обнаружить неожиданные повторные рендеры. Мы объяснили в https://github.com/facebook/react/issues/16437#issuecomment -523629000, что это находится на нашем радаре и что дополнительные комментарии со словами «Мне это нужно» бесполезны. Поскольку этот поток, тем не менее, продолжает собирать комментарии типа «Мне это нужно», я собираюсь заблокировать его, чтобы уменьшить поток уведомлений. Будьте уверены, ваш голос слышен.

Я реализовал эту функцию в новом DevTools (# 16989) со следующими оговорками:

• На данный момент он включен только в расширении браузера (и пакете react-devtools-inline NPM), поэтому поддерживает только React DOM.
• Он не реализован для устаревших модулей рендеринга (v15), хотя может быть добавлен кем-то, если они захотят отправить последующий PR.

Закрытие этой проблемы сейчас, когда приземляется # 16989. Скорее всего, сегодня выйдет 4.2 с новой функцией.