Redux по проводу
Когда вы начнете использовать React (в 2017 году), вы быстро узнаете, как передавать реквизиты, как это может быть неудобно для более глубокого пользовательского интерфейса и, наконец, как Redux может помочь вам в этом вопросе. Но что именно предлагает Redux? Ну, как говорится в документации:
[Redux] помогает писать приложения, которые работают согласованно, работают в разных средах (клиентских, серверных и собственных) и легко тестируются.
Нам, как интерфейсным инженерам, нравятся эти характеристики. Что, если я скажу, что вы можете добавить функции реального времени, постоянство и масштабируемость, не теряя этих хороших свойств?
Одним из часто используемых решений является самостоятельное управление подключением к WebSocket. Или используйте конечную точку GraphQL или даже REST с опросом. Даже если у этих решений есть свои плюсы и минусы, вам все равно придется переводить свои действия с сокращением в понятные инструкции для библиотеки, которую вы используете на стороне сервера. Это часто навязчиво и усложняет ваше приложение.
Именно здесь на помощь приходит Aquedux. По своей сути, он берет концепции редукции и переносит их в более широкую область: приложение в целом (несколько клиентских приложений, серверные службы, базы данных).
Состояние подъема вверх
В приложении React вы можете разделить свое состояние на множество мест, и обычно оно начинается с состояния компонента. Счетчик для рендеринга? Просто сохраните число count в компоненте Counter. Нужно увеличить его? Используйте setState. Для базовой реализации потребуются два компонента: один, который фактически отображает счетчик, и другой, который хранит и обрабатывает данные счетчика.
Таким образом, мы создали связь между нашим чисто визуальным компонентом и компонентом диспетчера состояний. Но единственное отношение, которое мы можем создать, - это родительское отношение к потомку, и только одно состояние может быть привязано к одному компоненту.
Что, если счетчик отображается в разных местах нашего приложения, и мы хотим сохранить одно и то же состояние для них обоих. Если это так, мы хотели бы поделиться состоянием счетчика по всему приложению. Вот где в игру вступает Redux. Создаем отношение магазина к компонентам. Redux - это менеджер состояния приложения.
Ответственность за данные была повышена и централизована в магазине Redux. Состояние теперь доступно через приложение React. Но что, если вы хотите видеть счетчик в нескольких экземплярах ваших приложений одновременно? Один в вашем мобильном приложении, поддерживающем реакцию, другой в приложении React на веб-панели инструментов и везде, где вы можете использовать среду Javascript с возможностями Redux и WebSocket. Вот где в игру вступает Aquedux.
Состояние больше не хранится в одном переднем приложении, а за серверным приложением, которое синхронизирует его для всех клиентов.
Aquedux - это просто Redux по проводам ...
И именно здесь мы достигаем нашей цели, не покидая экосистему Redux! Тем самым мы сохраняем его замечательные свойства, указанные во введении: согласованность, кроссплатформенность и тестируемость. Последовательность в нашем коде также, потому что редукторы и создатели действий, которые вы пишете, повторно используются на стороне клиента и сервера.
Это также добавляет масштабируемость. Для приложения Aquedux потребуется 2 компонента: клиентское приложение, использующее библиотеку aquedux-client, и серверное приложение, использующее библиотеку aquedux-server. Серверная часть - это объект без состояния, который зависит от других замечательных инструментов, таких как Redis, распределенное хранилище ключей и значений. Почему Redis? Потому что он добавляет недостающее свойство, чтобы сделать Aquedux подходящим инструментом для масштабируемых, постоянных приложений реального времени.
Давайте посмотрим, как нам удается перемещаться между действиями Redux с минимальным количеством кода или знаний, отличных от Redux.
Сначала действие отправляется одним из ваших компонентов React. Затем он проходит через промежуточное программное обеспечение Aquedux, которое блокирует любое действие из белого списка, которое вы решили отправить через соединение WebSocket в серверное приложение. На данный момент действие не достигло вашего локального редуктора, и компонент не был уведомлен об изменении состояния.
Затем заблокированное действие отправляется через соединение WebSocket на связанный с ним сервер Aquedux.
Вот где происходит волшебство. Действие принимается сервером и немедленно помещается в базу данных Redis. База данных уведомляет нас (и любые другие экземпляры серверного приложения) с тем же действием. Почему? Потому что так мы можем достичь двух свойств:
* Масштабируемость: каждое серверное приложение может обрабатывать ограниченное количество подключений WebSocket. Благодаря механизмам публикации / подписки Redis действие безопасно передается всем заинтересованным серверным приложениям, и, таким образом, вы можете создавать любое количество серверных приложений у своего любимого облачного провайдера.
* Постоянство: полагаясь на функции сохраняемости Redis. Любое действие в очереди сохраняется в очереди, и Redis отслеживает каждое действие, а также может делать снимки своего состояния в памяти. Подробнее об этом здесь.
Таким образом, все состояние приложения хранится в хранилище Redis в форме всех очередей действий. Когда серверное приложение получает новое действие от Redis, оно отправляет его в собственном потоке Redux. Таким образом, действие сокращается, и временное состояние клиентского приложения находится в состоянии Redux серверного приложения.
Как только серверное приложение сократило действие, оно отправляет его обратно всем подключенным фронтальным приложениям. Переднее приложение делает то же самое, что и серверное приложение: оно сокращает действие локально. И вуаля! Ваш счетчик увеличился во всех подключенных мобильных приложениях.
Одно действие перемещалось, сохранялось и достигало всех других клиентских приложений, и все это в режиме реального времени.
Тебе следует это попробовать!
Мы говорили только о поверхностных возможностях Aquedux. Мы не говорили о том, как состояние гидратируется при первом подключении, как логика приложения может в основном обрабатываться с помощью связки промежуточного программного обеспечения Redux на стороне сервера, как хранилище Redux можно разделить для прослушивания и воздействия только на подсостояние. с помощью каналов Aquedux.
Но для того, чтобы правильно осветить все эти функции, потребуется больше, чем одна статья. Поэтому могу только рекомендовать попробовать самому! Просто зайдите в репозиторий Aquedux на Github и посмотрите папку с примерами. Он содержит классический пример Redux MVC с мощью Aquedux поверх него!
