Блог

Почему редуктор должен возвращать новое состояние, в чем причина этого.Почему мы не можем вернуть обновленное состояние? Это шаблон, которому мы должны следовать или что?Также, пожалуйста, дайте мне знать, что ngrx и redux — это совершенно разные?

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

В обеих библиотеках они возвращают недавно измененное состояние или исходное состояние

Просто просматриваю официальные документы как для NgRX reducer, так и для Redux reducer

Редуктор NGRX

Редукторы в NgRx отвечают за обработку переходов из одного состояния в следующее в вашем приложении.

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

Редуктор Redux

Редукторы определяют, как изменяется состояние приложения в ответ на действия, отправляемые в хранилище.

Независимо от шаблона управления состоянием, вам необходимо изменить состояние с помощью редукторов, поскольку действия отвечают за fpr источник информации для хранилища. Они являются точками входа для взаимодействия с хранилищем как в NgRx , так и в ‘redux’, более того, в Vuex тоже.

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

Надеюсь, это поможет!

Обе библиотеки нацелены на управление состоянием, которым можно манипулировать только определенными, предопределенными способами; редукторы — это доступ, который они предоставляют к состоянию.

Ограничивая возможность прямого управления состоянием, они облегчают понимание того, как было достигнуто конкретное состояние; всегда можно достичь определенного состояния, повторно отправив те же действия, и данное состояние может быть достигнуто только в результате действий, отправленных в state (по крайней мере, это идеальный вариант — нечистые * редукторы потенциально могут привести к достижению разных состояний в результате одних и тех же действий).

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

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

Состояние доступно только для чтения

Единственный способ изменить состояние — это выполнить действие, объект, описывающий, что произошло.

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

Изменения вносятся с помощью чистых функций

Чтобы указать, как дерево состояний преобразуется действиями, вы пишете чистые редукторы.

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

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

* Функция с нечистой функцией выполняла бы одно или многие из следующих действий:

1. Доступ к состоянию, отличному от переданных аргументов
2. Манипулируйте аргументами, которые были переданы
3. Содержит побочный эффект — что-то, что влияет на состояние вне самого себя

Изменяющееся состояние является наиболее распространенной причиной ошибок в приложениях Redux, включая компоненты, не выполняющие повторную визуализацию должным образом, а также приводит к прерыванию отладки во времени в Redux DevTools. Фактической мутации значений состояния всегда следует избегать, как внутри редукторов, так и во всем остальном коде приложения.

Используйте такие инструменты, как redux-immutable-state-invariant, чтобы перехватывать мутации во время разработки, и Immer, чтобы избежать случайных мутаций при обновлении состояния.

Примечание: можно изменять копии существующих значений — это обычная часть написания неизменяемой логики обновления. Кроме того, если вы используете библиотеку Immer для неизменяемых обновлений, написание «изменяющей» логики приемлемо, потому что реальные данные не изменяются — Immer безопасно отслеживает изменения и генерирует постоянно обновляемые значения внутри.

Из документа Redux.