Офіційним Реагувати Документи стану, « React.PureComponent« и shouldComponentUpdate()тільки неглибоко порівнюють об'єкти », і радить проти цього , якщо стан" глибокого ".

З огляду на це, чи є якась причина, чому варто віддати перевагу React.PureComponentпід час створення компонентів React?

Запитання :

• чи є вплив на ефективність використання, React.Componentякий ми можемо розглянути React.PureComponent?
• Я припускаю , що shouldComponentUpdate()з PureComponentпреформ тільки неглибокі порівняння. Якщо це так, чи не можна вказаний метод використовувати для більш глибоких порівнянь?
• "Крім того, React.PureComponent's shouldComponentUpdate()пропускає оновлення підтримки для всього піддірева компонента" - Чи означає це, що зміни опори ігноруються?

Питання виникло після читання в цьому середньому блозі , якщо це допоможе.

Основна різниця між React.PureComponentта React.Componentполягає PureComponentв тому, чи є неглибоке порівняння щодо зміни стану. Це означає, що при порівнянні скалярних значень він порівнює їх значення, але при порівнянні об'єктів порівнює лише посилання. Це допомагає покращити ефективність програми.

Вам слід поступити, React.PureComponentколи зможете виконати будь-яку з наведених нижче умов.

• Стан / реквізит повинен бути незмінним об'єктом
• У штаті / реквізиті не повинно бути ієрархії
• Вам слід зателефонувати, forceUpdateколи дані зміняться

Якщо ви користуєтесь, React.PureComponentпереконайтесь, що всі дочірні компоненти також чисті.

чи є якийсь вплив на ефективність використання React.component, який ми можемо розглянути для React.PureComponent?

Так, це збільшить ефективність вашої програми (через неглибоке порівняння)

Я здогадуюсь, чи повиненComponentUpdate () Purecomponent виконує лише неглибокі порівняння. Якщо це так, чи не може зазначений метод використовуватись для більш глибоких порівнянь?

Ви правильно це здогадалися. Ви можете використовувати його, якщо задовольняєте будь-яку з умов, про які я згадував вище.

"Крім того, React.PureComponent’s shouldComponentUpdate () пропускає допоміжні оновлення для всього піддіречка компонента" - Чи означає це, що зміни опори ігноруються?

Так, зміни опори будуть проігноровані, якщо не вдасться знайти різницю в неглибокому порівнянні.

Componentі PureComponentмають одну різницю

PureComponentточно так само, як Componentза винятком того, що він обробляє shouldComponentUpdateметод для вас.

Коли реквізит або стан зміниться, PureComponentбуде проведено неглибоке порівняння як реквізиту, так і стану. Componentз іншого боку, не буде порівнювати поточний реквізит і стан з наступним поза коробкою. Таким чином, компонент буде повторно відображатися за замовчуванням щоразу, коли shouldComponentUpdateвикликається.

Неглибоке порівняння

Порівнюючи попередні реквізити та стан з наступним, дрібне порівняння перевірить, чи мають примітиви однакове значення (наприклад, 1 дорівнює 1 або що справжнє дорівнює істині) та що посилання однакові між більш складними значеннями JavaScript, як об'єкти та масиви.

Джерело: https://codeburst.io/when-to-use-component-or-purecomponent-a60cfad01a81

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

З іншого боку, чистий компонент не відображатиметься, якщо його батьківський показник не буде змінено, якщо не буде змінено реквізит (або стан) чистого компонента.

Наприклад, скажімо, що у нас є компонентне дерево з трирівневою ієрархією: батьки, діти та онуки.

Коли реквізит батьків змінюється таким чином, що реквізит однієї дитини змінюється, тоді:

• якщо всі компоненти є звичайними компонентами, тоді все дерево компонентів буде повторно представлено
• якщо всі діти та онуки є чистими компонентами, то лише одна дитина, і одна чи всі її онуки, залежать від того, чи змінено їх реквізит. Якщо в цьому дереві компонентів багато компонентів, це може означати значне підвищення продуктивності.

Однак іноді використання чистих компонентів не матиме ніякого впливу. У мене був такий випадок, коли батько отримував реквізит із магазину редукцій та потребував складного обчислення реквізиту своїх дітей. Батько використовував плоский список для надання своїх дітей.

Результат полягав у тому, що кожного разу, коли відбувалися навіть невеликі зміни в магазині скорочення, весь перелік плоских масивів даних про дітей перераховувався. Це означало, що для кожного компонента в дереві реквізит - це нові об'єкти, навіть якщо значення не змінювалися.

У цьому випадку чисті компоненти не допомагають, а підвищення продуктивності може бути досягнуто лише за допомогою звичайних компонентів та перевірки у дітей, у програмі shouldComponentUpdate, якщо потрібна повторна візуалізація.