Redux: Почему нельзя изменить состояние ....

https://github.com/rackt/redux/issues/328

Все дело в предсказуемости и надежности.

Редукторы в redux - это чистые функции, что означает, что у них нет побочных эффектов. Как только вы начинаете смотреть на какое-то внешнее состояние этих функций, они перестают быть чистыми. А если они не чистые, они могут быть ненадежными. И это вызывает ошибки, многие из которых очень трудно отследить.

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

И вы получаете бесплатные функции, такие как путешествия во времени, что очень удобно.

Закрытие дубликатом №328.

Просто чтобы уточнить: состояние не клонируется глубоко при каждом действии. Клонируются только те части, которые были изменены (опять же, не глубоко - зависит от того, что изменилось). Например, когда задача редактируется в приложении TodoMVC, клонируется только этот объект задачи. В остальном задачи такие же. Конечно, создается корневой массив нового списка задач, указывающий на новый объект, но сами объекты не клонируются, если они не изменились. Поэтому это не так дорого, как может показаться. Кроме того, когда это становится дорого (например, быстрое изменение массива), вы можете начать использовать библиотеку, такую ​​как Immutable.js, которая имеет очень быстрое копирование благодаря структурному разделению. С Immutable.js копирование даже больших массивов на самом деле не так дорого, потому что большие куски памяти используются повторно. Наконец, независимо от того, есть ли Immutable.js или нет, неизменяемость помогает нам эффективно повторно отрендерить приложение, потому что мы знаем, что именно изменилось, благодаря тому, что объекты не мутировали.

Ааа ... теперь вижу, что последний бит имеет смысл ... Я предполагаю, что этим вы говорите, что из-за изменения рендеринга компонента только из-за того, какое состояние изменилось, в результате механизм реагирования на различие / перерисовку стал быстрее? Похоже на shouldComponentUpdate

Я предполагаю, что вы говорите, что из-за изменения рендеринга компонента только из-за того, что изменилось состояние, в результате механизм реагирования на различие / перерисовку работает быстрее? Похоже на shouldComponentUpdate

Точно, react-redux использует агрессивный shouldComponentUpdate под капотом благодаря гарантии неизменности.

@gaearon Извини, что немного

Кроме того, когда это становится дорого (например, быстрое изменение массива), вы можете начать использовать библиотеку, такую ​​как Immutable.js, которая имеет очень быстрое копирование благодаря структурному разделению.

Я ищу использование redux для обработки обновлений массива, увеличивающегося до 8000 позиций, и ожидаю, что пропускная способность будет в районе 10-100 изменений на 100 мс. Я веду проигрышную битву, чтобы попытаться управлять состоянием таким образом, используя redux?
Мы планируем представить состояние через холст, а не через модель DOM, но я хотел бы понять, может ли, по вашему мнению, вызывать у нас проблемы с частотой обновлений или нет.

@dougajmcdonald : Мой первый вопрос: можно ли каким-то образом дополнить эту работу? Вам действительно нужно представлять каждое отдельное обновление как отдельную перерисовку пользовательского интерфейса?

Кроме того, я бы посоветовал вам взглянуть на эти ресурсы по производительности, связанной с Redux:

• Записи часто задаваемых вопросов Redux о производительности и масштабировании , минимизации уведомлений о подписке и использовании селекторов
• Мой пост Практический Redux, Часть 6: Связанные списки, формы и производительность
• Раздел Redux Performance в моем списке ссылок React / Redux

Я также был бы рад поговорить об этом подробнее в чатах Reactiflux .

@markerikson К сожалению, да, концепция игры включает в себя множество быстрых обновлений относительно большой структуры данных.
Я понимаю, что был не совсем ясен в своем первоначальном комментарии, когда я говорю 10-100 изменений, не все они вызывают перерисовку. 10-100 изменений - это изменения состояния, которые будут представлены одной перерисовкой за 100 мс.
Итак, мой вопрос на самом деле: если бы я разбивал свои обновления на 10-100 изменений состояния на 100 мс, смогло бы управление состоянием в redux эффективно обрабатывать их таким образом, чтобы это было разумно завершено в пределах окна 100 мс для разрешить перерисовку, чтобы объекты не отставали.
Обновления состояния будут в основном включать изменение 3-4 свойств в массиве размером 8000, поэтому мы будем говорить о создании нового массива 1-10 раз в мс (при условии, что мы хотим сохранить неизменность) с некоторыми изменениями в одном из объекты в индексе массива. Объекты довольно маленькие (3-4 свойства, пара чисел и пара небольших строк)

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

@dougajmcdonald : ну, "управление состоянием в Redux" на самом деле является единственной функцией корневого редуктора, которую вы предоставили :)

Immutable.js - это не волшебная серебряная пуля, улучшающая производительность. Он может сделать одни вещи быстрее, а другие - медленнее. У меня есть несколько статей по вопросам производительности, связанным с Immutable.js, которые вы, возможно, захотите посмотреть.

Честно говоря, с учетом вашего варианта использования вы _ теоретически могли бы избежать наказания с помощью прямой мутации, если бы захотели. Согласно моему сообщению Idiomatic Redux, Часть 1 - Реализация и намерение , само ядро ​​Redux на самом деле вообще не заботится о мутации - это в первую очередь уровень пользовательского интерфейса React-Redux, а также DevTools. Мутация - это не то, что вы _думали_ использовать Redux, но это возможно.

Мой личный совет - начать с простого. Просто используйте простые объекты и массивы JS. Неизменно обновляйте их либо «вручную», либо с помощью одной из множества доступных

Затем оттуда вы можете выполнить дополнительную работу по оптимизации с точки зрения пакетирования, сокращения диспетчеризации, логики обновления и т. Д.

@markerikson - тонкая насмешка в нос! : p Да, вы правы, сторона редуктора на данный момент - это в основном создание и уничтожение довольно большого массива, но я думаю, что реальная проблема, скорее всего, связана с битами и бобами жизненного цикла компонентов реакции, когда конечная цель будет элемент холста, идеально отображающий со скоростью 60 кадров в секунду.
Спасибо за точку зрения о неизменяемости и за точку зрения о прямой мутации, я немного прочитаю и рассмотрю их тоже.
На данный момент мой мыслительный процесс состоит в том, чтобы отключить состояние redux от холста и просто передать ему сообщения через pub / sub (именно так мы уже подключили его) просто с большим количеством движущихся частей

Думаю сменить:
pubsub> dispatch ()> reducer> redux state> react component stuff> canvas render.

Кому:
pubsub> состояние локального компонента> рендеринг холста

Я по-прежнему буду использовать redux для остальной части пользовательского интерфейса, но, возможно, не для холста в приложении.

Ваши вопросы абсолютно верны. На самом деле реализация redux vuejs, называемая vuex, работает в рамках концепции мутации. Таким образом, «редюсеры» на самом деле называются мутациями, и пока вы изменяете состояние централизованно, все должно быть в порядке. Это происходит потому, что vue добавляет наблюдателей и другие вещи в состояние приложения, поэтому, как вы упомянули, в vue имеет больше смысла изменять, а не заменять объект. Redux неизменяем, и, в конце концов, производительность обоих подходов реагирует на обновления виртуального DOM VS vue в основном одинакова в том месте, что невозможно сказать, что для всех случаев один лучше другого