Реактивный отладчик производительности

Question

Я недавно начал практиковать повышение производительности и отладки для реагирования.

О РЕАКТ Tools Performance:

Я начал отладку с react.addons.Perf.printWasted(), его держать показать мне эти результаты:

"AlertRow > Connect(AlertsBottomPanel)" 
"Connect(AlertsBottomPanel) > AlertsBottomPanel" 

Что хочет от моя функция соединения connectx? Кажется, я не понимаю, что я читаю. Есть ли какие-нибудь хорошие инструменты для отладки производительности в Turural, просто ничего на google.

О shouldComponentUpdate методы: после прочтения кучи статей, в нижней строке я понял, просто скопировать пасты:

shouldComponentUpdate(nextProps, nextState) { 
    return !_.isEqual(this.props, nextProps) || 
    !_.isEqual(this.state, nextState); 
} 

Я прочитал эту хорошую статью: http://benchling.engineering/performance-engineering-with-react/

является то, что на самом деле все есть ли это, или я что-то упускаю?

Answer 1

Что он хочет от моей функции connectix connectix?

Это не «хочет» что-нибудь, он просто говорит, что connect() от Redux провел некоторую работу, если ваши определения реквизита изменился, но они не имеют, так что в некотором смысле, что работа была впустую.

"Wasted" не всегда означает что-то плохое. Это просто означает, что некоторые работы были выполнены, но это не повлияло ни на какие изменения в DOM. В случае connect() это действительно имеет смысл, потому что именно так оно и есть: позвоните в ваш mapStateToProps и определите, нужно ли отображать что-либо ниже. Поскольку у вас нет контроля над компонентом ed connect() (он создается React Redux), вы не можете ничего с этим поделать.

Также: о каких номерах мы говорим? Не беспокойтесь о сохранении одного или двух миллисекунд, они не будут иметь никакого значения.

после прочтения кучи статей, в нижней строке я понял, просто скопировать пасты:

shouldComponentUpdate(nextProps, nextState) { 
    return !_.isEqual(this.props, nextProps) || 
    !_.isEqual(this.state, nextState); 
} 

Где вы читаете это? Это очень неэффективный способ реализации shouldComponentUpdate, потому что он performs a deep comparison. Это означает, что он будет медленнее на глубоких деревьях, на самом деле, скорее всего, медленнее, чем просто позволить React повторно отобразить компонент.

Моей рекомендацией было бы использовать аддон shallowCompare, который поставляется с React, и экономно. Используйте его только в том случае, если вы действительно видите его, что повышает производительность. Не просто наденьте его на все компоненты «на всякий случай».

Наконец, не забудьте проверить эффективность вашего приложения с помощью сборки React. Он может быть от 5x до 10x быстрее, чем версия для разработки, поэтому убедитесь, что вы не оптимизируете то, что не нужно оптимизировать.