2017-01-16 3 views
2

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

Это должно быть? Есть ли в этом неэффективность? Переключение дочернего компонента на PureComponent исправляет это, а дочерний компонент не будет повторно. Должен ли я одобрять PureComponents над обычными компонентами?

+0

PureComponents больше ошибка подверженным. Общая рекомендация реагирующих документов заключается в том, чтобы использовать компонент повсюду и использовать PureComponent только при решении реальной проблемы с производительностью и только тогда, когда ее использование действительно повышает производительность. Я не могу найти ссылку на источник прямо сейчас. –

+0

Из документов PureComponent: «Если функция рендеринга() вашего компонента React отображает тот же результат с учетом того же реквизита и состояния, вы можете использовать React.PureComponent для повышения производительности в некоторых случаях». «If» - это то, что мне интересно ... Является ли функция рендеринга работать, когда все одинаково? Или должны быть немые компоненты без состояния или реквизита, которые когда-либо не повторялись при использовании обычных компонентов. Как регулярные компоненты решают, когда делать? –

+0

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

ответ

1

Если вы хотите контролировать, что делает компонент Rerender, то вы должны использовать shouldComponentUpdate, который может использоваться для всех компонентов, если они не являются функциональными компонентами без гражданства. PureComponent в основном использует shouldComponentUpdate автоматически и делает неглубокую проверку прошлых и текущих реквизитов/состояний, и если бы произошла смена, она будет повторно.

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

https://facebook.github.io/react/docs/react-component.html#shouldcomponentupdate

Здесь также информация для PureComponent

https://facebook.github.io/react/docs/react-api.html#react.purecomponent

+0

Спасибо, я понимаю, что функциональность, я просто пытаюсь понять, должен ли я беспокоиться о контроле над реинжинирингом? Должен ли я войти в привычку пытаться свести к минимуму переобучение компонентов, которые не нужны для перерегистрации? –

+1

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

+0

Спасибо, это полезно. Я просто прочитал некоторые документы, которые пояснили, что метод рендеринга на самом деле не подразумевает переименование фактического DOM. React по-прежнему сравнивает предоставленный vritual DOM-элемент с реальной вещью, чтобы определить, нужно ли его отображать в пользовательском интерфейсе. –

Смежные вопросы