Реакция: Какое снижение производительности вызывает вызов setState после изменения состояния непосредственно в компоненте?

Question

Так как метод рендеринга компонента вызывается с каждым setState *, мне было интересно узнать о снижении производительности, если я напрямую изменю свойства состояния, вызову setState ({}) с пустым объектом и позволю компоненту полностью отобразить себя. Это имеет интересный побочный эффект в управлении состоянием: в этом случае состояние используется как изменяемый объект, а не как неизменяемый. Поскольку компонент будет повторно отображаться с новыми значениями состояния после вызова setState, он будет отражать новые значения в представлении. Конечно, изменение состояния не рекомендуется командой React, так как они предлагают, чтобы состояние рассматривалось как объект только для чтения, но, тем не менее, в некоторых случаях управление изменяемым объектом становится проще для управления состоянием.

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

Посмотрите на следующий пример для простой демонстрации: https://codesandbox.io/s/k5zy9zw8kv

Итак, пожалуйста, дайте мне знать, что вы думаете.

Спасибо.

* Если shouldComponentUpdate не был реализован в компоненте и возвращает false в зависимости от текущего состояния и значения nextState.

PS: Мое личное мнение, для управления состоянием лучше использовать MobX для средних и крупных приложений. Мой вопрос в основном для относительно небольших приложений. Я думаю, что и реакция, и избыточность делают управление состоянием излишне сложным, чем должно быть. Как разработчик с опытом работы с OO, я хотел бы видеть более простые и элегантные решения.

Answer 1

Это ужасная идея.

1. Официально не поддерживается

Прямая мутация состояния не документирована, не поддерживается и не проверена, поэтому команда React может изменять поведение в разных версиях (без тестирования / документирования).

2. Разрывает методы жизненного цикла

Вы нарушаете несколько методов жизненного цикла, таких как componentDidUpdate, так как prevState не будет состоянием до мутации, поэтому вы отказываетесь от возможности использовать эти методы, если они понадобятся вам в будущем.

3. Держите состояние мелким вместо

Работа с изменяемым объектом упрощает управление состоянием

Вероятно, вы испытываете это чувство, когда у вас есть глубоко вложенные состояния, поэтому изменение вложенного свойства (например, product.quality) требует сначала клонировать весь объект (например, products).

Рекомендуется сохранять ваши состояния как можно более мелкими, как для простоты изменения состояния, так и для упрощения оптимизации производительности. Например. если вы указали неглубокое значение, объявление его как PureComponent позволит избежать его вызова render, когда родительский компонент перерисовывается без изменений в дочернем компоненте.

В вашем примере вы можете переместить состояние в Product вместо:

class Product {
  state = { quantity: 0 };
  ...
  this.setState(prevState => ({ quantity: prevState.quantity + 1 }));
}