Может ли редукция рассматриваться как паб/суб или шаблон наблюдателя?

Я просто пытаюсь поднять голову на response.js, но, как говорится, я только что закончил несколько учебных пособий в Интернете.

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

С сокращением мы теперь попытаемся сделать общее состояние приложения глобальным, и мы должны определить действия для манипулирования этим (глобальным) состоянием, так что же это за действия, отличные от "нормального" шаблона pub/sub или наблюдателя javascript? Или, может быть, я ошибаюсь? - Было бы высоко оценено разъяснение.

Ответ 1

Redux не должен "заменять исходную идею реакции .js", подумайте об этом скорее как библиотеку для управляемого общего состояния между компонентами и координируйте мутации состояния. Redux действительно использует шаблон pub/sub, см. Здесь методы хранения: http://redux.js.org/docs/api/Store.html#store-methods Вы найдете метод subscribe, который используется компонентами для подписки на изменения в дереве состояний. Обычно вы не используете store.subscribe напрямую, так как привязки Redux-React (Redux connect в основном) делают это для вас. Вы можете проверить реальную реализацию здесь, это не так сложно (на самом деле для меня это главное преимущество Redux над другими реализациями Flux): https://github.com/reactjs/react-redux/blob/master/src/components/connect.js#L199

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

Считайте также, что прекрасно поддерживать внутреннее состояние компонентов вместе с Redux. Вы можете использовать внутреннее состояние для хранения состояния, которое вам не нужно/хотите поделиться с другими компонентами.

Вы видите потребность в чем-то вроде Redux, когда у вас есть более сложное приложение, с компонентами верхнего уровня, которые должны разговаривать друг с другом (действия) и каким-то образом разделять какое-то состояние.

Действия в Redux по умолчанию просто POJO (простые старые объекты javascript), вы можете думать о них как о "событиях", которые вы часто отправляете в ответ на действия, инициируемые пользователем (например, пользователь нажал кнопку), но вы, не ограничиваясь этим, вы можете отправить действие из любого места, где захотите. Магазин Redux прослушивает эти действия и вызывает редукторы (чистые функции), передавая объект действия, который вы отправили.

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

В этом смысле редуктор - это функция, которая обрабатывает действия и обновляет состояние по мере необходимости.

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

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

С помощью reducex-thunk вы можете отправлять функции в отличие от простых объектов. Отправляя функцию, вы эффективно реализуете инверсию шаблона управления очень простым способом. Ваше действие становится "рецептом", описываемым функцией, а не просто простым утверждением, как с действием POJO.

Почему только POJO поддерживаются "из коробки", для действий, почему нет базового класса Action или чего-то еще? В основном потому, что в этом нет необходимости. Простой объект (считающийся суммой для значений в основном) с свойством type - это все, что вам действительно нужно, это в основном простейший возможный интерфейс. Вы можете рассматривать это как программирование против интерфейса (действия) вместо реализации.

Почему глобальное состояние лучше, а не каждый компонент, управляющий своим собственным состоянием? В основном потому, что управление состоянием на самом деле является самой сложной частью нетривиального js-приложения. Используя Redux, вы извлекаете всю эту логику из уровня пользовательского интерфейса, что упрощает тестирование. Фактически, вы должны в идеале быть в состоянии проверить всю реальную "бизнес-логику" приложения Redux, даже не создавая один компонент.

Компоненты становятся "более глупыми" и "более чистыми", поскольку они просто делают то, что им говорят. "Purer" здесь означает, что, поскольку они не содержат никакого состояния, то, что вы видите, только что зависит от входов (читайте "реквизит" ) в любой момент времени, а не по какой-либо истории, следовательно, "без гражданства".

Наличие состояния как единого, json serialisable объекта также позволяет легко отлаживать, снижать его и отправлять/восстанавливать с сервера или локального хранилища.

Ответ 2

Невозможно переместить ответ Fabios дважды, а раздел комментариев - небольшой:

Да, на мой взгляд, это как pub/sub с соглашением.

Чтобы проиллюстрировать, как пропустить реквизит может быть боль, вот пример.

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