Массивы объектов в state — как обновлять?

Question

[maksipes]

Дано:
В state массив, в массиве объекты.
Надо:
Обновить у одного из объектов, одно из свойств.

Умные люди научили меня не мутировать state и делать примерно так:

onItemHintClick = (index, e) => {
    const newItems = this.state.items.map((item, i) => {
      if (i === index) {
        return { ...item, htogle: !item.htogle };
      } else {
        return {...item};
      }
    });
    this.setState({ items: newItems });
  };

Т.е. в цикле собирается клон массива из массива в state, где меняется одно свойство, одного элемента.

Я только начинаю изучать React и JS и мне кажется странным - ради простой операции устраивать такую возню.

А если элементов в массиве много и они сами по себе большие?

Ведь есть прямой и изящный способ изменить нужное значение, сделать, например, так:

this.state.items[index].htogle = !this.state.items[index].htogle
this.forceUpdate();

А теперь прошу внимания - я знаю, что против такого способа выступает официальная документация, где сказано - не мутируй state и избегай forceUpdate(), это может привести к непрогнозируемым багагм.

Так я хочу спросить - ПОЧЕМУ так нельзя делать и КАКИЕ негативные последствия это может иметь?

Именно в данном случае, где не планируется использовать houldComponentUpdate() и другие продвинутые техники управления состоянием приложения.

Мне кажется, что в простых ситуациях, мутация state и немедленный вызов forceUpdate() будет работать не хуже setState, при этом код будет внятней и эффективней.

ПС. пожалуйста, не посылайте меня читать документацию, эти фразы про setState и forceUpdate() - я хочу понять, а не только слепо следовать.

Answer 1

[lnked]

onItemHintClick = (index, e) =>
  this.setState(({ items }) => ({
    items: [
      ...items,
      [index]: {
        ...items[index],
        htogle: !items[index].htogle,
      },
    ],
  }));

Answer 2

[Антон Спирин]

Умные люди научили меня не мутировать state и делать примерно так

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

против такого способа выступает официальная документация, где сказано - не мутируй state и избегай forceUpdate(), это может привести к непрогнозируемым багагм.
Так я хочу спросить - ПОЧЕМУ так нельзя делать и КАКИЕ негативные последствия это может иметь?

Ну вы же сами пишите, что читали, что это может привести к непрогнозируемым багам.

Мне кажется, что в простых ситуациях, мутация state и немедленный вызов forceUpdate() будет работать не хуже setState, при этом код будет внятней и эффективней.

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

Если вам нравится подход с мутациями, то вы можете попробовать использовать с React библиотеку MobX.

Comments

[maksipes]

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

Вот тут не понял?

Насколько я понимаю - ренедер все равно полностью выполнится, изменили мы один элемент в массиве или изменили все элементы.

Это же обычный метод, который строит виртуальный дом.

[Антон Спирин]

maksipes, ну смотрите. Например, у вас есть список комментариев, с тредами, лайками, реакциями и прочим функционалом, который строится рендером массива comments, но все остальные данные нужные комментариям вы забираете из центрального хранилища и у вас там для оптимизации вроде memo, реализации shouldCompnentUpdate, PureComponent или просто connect, в случае использования Redux. И вот если обновить только один элемент и сам список, перерисуется только компонент списка и нужный комментарий, а остальные комментарии перерисованы не будут. В случае, если реализовать обновление как в коде в вопросе, произойдет напрасная перерисовка всех комментариев - довольно сложных компонентов. И пусть это будет только в Virtual DOM, это все-равно будет не дешевая операция.