Redux без состояния
ЗАЧЕМ?
Что, если бы вы могли воспользоваться всеми преимуществами Redux и не писать ни одного редуктора?
Что, если бы вам пришлось поддерживать устаревшее приложение AngularJS, jQuery, Backbone или Knockout? Если вы хотите использовать Redux прямо сейчас, вам придется беспокоиться о двух наборах состояний.
Что ж, вы можете! И все, что вам нужно, это Redux без состояния.
Но Redux - это государственный менеджер:
Так зачем кому-то использовать Redux без состояния? Это как если бы кто-то дал вам на обед уже съеденное яблоко. Что в этом хорошего?
Настоящая сила Redux исходит не от государственного управления. Это всего лишь побочный эффект ключевого ингредиента: системы обмена сообщениями.
Обмен сообщениями в Redux
Сообщения называются действиями в Redux и обычно используются для обновления состояния.
Функции промежуточного программного обеспечения - еще один важный элемент Redux, но они не обновляют состояние. Эти функции только отправляют действия или выполняют побочные эффекты (такие как вызовы AJAX и ведение журнала консоли).
Это означает, что они только слушают действия, а затем отправляют другие действия:
Промежуточное ПО Redux просто потрясающе. Вот несколько примеров того, что вы можете делать с действиями Redux после добавления промежуточного программного обеспечения:
Точно так же, как вам не нужен Redux для использования Redux-Observable, вам также не нужны состояния или редукторы для использования системы действий в Redux. Чтобы понять обмен сообщениями Redux, вы должны сначала понять действия.
Что такое действие?
В основе системы обмена сообщениями Redux лежит действие. Это объект со свойством type.
{ type: 'SOME_ACTION' }
Вот и все.
type может быть любым: string, object, symbol или даже number. Лучшая практика - использовать строку, написанную заглавными буквами, для облегчения отладки.
Действия - это ключ к созданию Redux без сохранения состояния.
Redux без сохранения состояния
Реализовать собственный Redux без сохранения состояния довольно просто. Мы собираемся рассмотреть несколько различных способов создания вашего собственного.
Вы можете создать свою собственную dispatch функцию следующим образом:
Примеры приведены в ES5 из соображений совместимости.
Если action.type существует в stateModifiers, вызовите эту функцию и передайте action.
Звучит знакомо?
Редукторы Redux тоже слушают действия. Единственная разница в том, что редуктор не изменяет состояние, а возвращает новое.
Но вы, вероятно, используете устаревшую систему, и изменение состояния является нормой. Вот почему эти функции-модификаторы состояния позволяют изменять состояние.
Вот как наша dispatch функция будет выглядеть в контроллере AngularJS:
Каждый раз, когда мы изменяем состояние, это происходит в объекте stateModifiers. Думайте об этом как о функции редуктора. Поскольку в вашем приложении уже есть метод поддержания состояния, все, что вы делаете, - это обертывание этого кода.
Не переписывайте AngularJS только для того, чтобы использовать Redux. Позвольте Redux работать с вашим существующим приложением. Вы можете постепенно добавлять dispatch функций к своим контроллерам и обновлять их по мере необходимости. Таким образом, вам не нужно менять библиотеки рендеринга только для того, чтобы воспользоваться преимуществами Redux.
Модификации состояний больше не разбросаны по вашей кодовой базе. Теперь они все в одном месте; легко найти, легко отладить.
По большей части все, что вам нужно, это dispatch. Запустите консольные действия по ведению журнала, и вы уже пользуетесь сообщениями Redux.
Добавление подписчиков
Диспетчеризация - это здорово, но большинству приложений Redux требуется промежуточное ПО. Вам нужно каким-то образом сказать «когда X изменяется, отправляйте другие действия».
Хотя большинство библиотек, таких как Knockout и Angular, позволяют отслеживать изменения состояния, это только часть уравнения.
Возможно, вы захотите преобразовать действие в другое действие или выполнить побочный эффект. Одним из таких примеров является подключение к сторонним библиотекам - подумайте о поддержке клиентов чата и сервисов, таких как LogRocket. В большинстве случаев одно действие вызывает выполнение более одного фрагмента кода.
Вот почему вам нужен способ подписки на вашу dispatch функцию и выполнение промежуточного программного обеспечения после обновления состояния:
Вот простой пример того, почему вам может понадобиться промежуточное ПО:
По сравнению с нашим предыдущим примером, мы больше не выполняем вызов данных при щелчке. Вместо этого мы отправляем только действие GET_IDS.
В нашем примере две функции промежуточного программного обеспечения прослушивают GET_IDS. Один запускает индикатор загрузки. Другой выполняет вызов данных.
Именно здесь проявляется разделение интересов Redux. Вашему обработчику кликов больше не нужно управлять вашей бизнес-логикой; это обрабатывается модификатором состояния и функциями промежуточного программного обеспечения.
Мошенничество
Если вы хотите создать промежуточное ПО с использованием объекта stateModifiers, это технически возможно. Дело в том, что я этого не рекомендую.
Если вы комбинируете свои модификаторы состояния с функциями промежуточного программного обеспечения, вы теряете возможность хранить обновления состояния как часть отдельной сущности.
Делаем его многоразовым
Допустим, вы хотели использовать это в своем приложении сегодня. Вы бы хотели написать это немного по-другому. Что-то вроде этого:
Теперь у нас есть журнал ошибок, и все это содержится в createStore функции, как и Redux. Единственная разница в том, что нет другого состояния, кроме внутреннего списка подписчиков «хранит».
В этой версии subscribe может принимать массив промежуточного программного обеспечения, а наша функция диспетчеризации имеет некоторые проверки безопасности и регистрацию ошибок.
Если вы установите window.__isDebugging на true, он также будет регистрировать каждое действие, чтобы вы могли отслеживать, что происходит. Конечно, это не инструменты разработчика Redux, но все же полезно.
Если вы видите большой блог с красными сообщениями об ошибках, теперь вы можете отследить, какое действие вызвало их, посмотрев на консоль.
Вот как вы это использовали:
Хотя Redux представляет собой своего рода библиотеку «единое глобальное хранилище, чтобы управлять ими всеми», эту версию без сохранения состояния можно и, вероятно, следует использовать в каждом контроллере.
Таким образом, у вас будет больше контроля над тем, что происходит, без того, чтобы все ваше приложение узнало о себе в глобальном масштабе. Во многих устаревших приложениях это то, что вам нужно.
Использование Stateless Redux с Legit Redux
Вы также можете выполнить Redux без сохранения состояния с помощью официальной библиотеки. Все, что вам нужно сделать, это использовать один редуктор и всегда возвращать предыдущее состояние:
Не так хорошо, как индивидуальное решение, но тогда вы можете без проблем подключиться к существующим промежуточным библиотекам, таким как Redux-Observable.
Хотя, если у вас есть возможность вводить зависимости npm, вам, вероятно, также не нужен Redux без сохранения состояния.
Настоящее объектно-ориентированное программирование
Я говорил о системе обмена сообщениями Redux, как о чем-то феноменальном, и это так.
Алан Кей, парень, который называл объектно-ориентированное программирование, на самом деле говорил о программировании, ориентированном на сообщения.
Из электронного письма Алану Кею 2003 года он сказал следующее:
Я думал об объектах, которые похожи на биологические клетки и / или отдельные компьютеры в сети, которые могут общаться только с помощью сообщений (так что обмен сообщениями появился в самом начале - потребовалось время, чтобы увидеть, как отправлять сообщения на языке программирования достаточно эффективно, чтобы быть полезный).
Я хотел избавиться от данных. […] Я понял, что метафора ячейка / весь компьютер избавит от данных, и что «‹ - »будет просто еще одним токеном сообщения (мне потребовалось довольно много времени, чтобы обдумать это, потому что я действительно думал обо всех этих символах как имена для функций и процедур.)
В двух словах, это Redux без сохранения состояния.
Вывод
До Redux было не так много хороших методов для отслеживания состояния вашего приложения.
Оглядываясь назад, можно сказать, что большая часть кода jQuery также была управляема событиями, как и система сообщений Redux. Вы слушаете такие вещи, как обработчики событий щелчка, перемещение мыши, отслеживание обновлений, загруженный документ и загруженное изображение. Но почему Redux такой чистый, а jQuery превращается в спагетти-код?
Раньше вы подписывались на конкретное действие (событие). Вы не могли подписаться ни на какие действия, как на промежуточное ПО Redux. Кроме того, при использовании эмиттеров событий нет разделения между обновлениями состояния и функциями промежуточного программного обеспечения.
Подумайте о Redux с точки зрения стоимости.
В краткосрочной перспективе это связано с небольшими затратами, но в долгосрочной перспективе оно легко обслуживается и отделяет бизнес-логику от ваших представлений. Даже с Redux без сохранения состояния, хотя вы не получаете неизменяемого состояния и легко тестируемых чистых функций, вы получаете огромные преимущества, зная, что именно происходит.
Больше Чтений
Если вам понравилось то, что вы прочитали, ознакомьтесь с другими моими статьями на похожие интересные темы:
