Так что я очень опаздываю на вечеринку, но в свободное время я работаю над приложением для составления бюджета. По сути, это большой проект, который поможет мне изучить весь стек Javascript — как внутренний, так и внешний. Я начал с попытки изучить React и Redux. Достаточно сказать, что первая попытка была ужасна — изучение нескольких технологий одновременно, пытаясь изучить и внедрить лучшие практики для каждой из них, является сложной задачей для любого, и я написал беспорядочную реализацию классификатора, используя React, Redux, и React-DND (перетаскивание). Я сделал это за полтора месяца в прошлом году, а потом пришлось приостановить проект по состоянию здоровья.

Теперь я вернулся к проекту и понимаю, сколько мне нужно рефакторить/выбросить. Я продолжал пытаться реорганизовать части React (в частности, компоненты контейнера), и я пришел к выводу, что делаю это неправильно; Сначала мне нужно сделать часть Redux.

Но почему? Во-первых, имело место постоянное ползучести рефакторинга. И вторая, более показательная причина, — это урок из опыта работы над приложением/игрой с карточками React Native для Android. Этот урок таков: Redux, по своей сути, является вашим приложением.

Что я имею в виду? Во-первых, позвольте мне сказать, что не имело смысла говорить мне, что Redux — это контейнер состояния. Абстрактно это ничего не значило. Но когда я работал над карточной игрой, мне нужен был способ отделить игру от пользовательского интерфейса, используемого для отображения игры. Мне нужен был способ представить колоду карт и отделить ее от всего, что я собирался использовать для отображения верхней карты.

Для этой игры Redux — это технология для моделирования этой колоды карт. Состояние будет состоять из 52 карточек, каждая с текстом, который она должна отображать. Были бы действия, которые пользователь мог бы предпринять, например, посмотреть следующую карту или перетасовать колоду. а редукторы - это реализации указанных действий.

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

Теперь, когда мы понимаем место Redux в контексте реального приложения, как это применимо к приложению для составления бюджета? Допустим, я работаю над классификатором, и этот классификатор имеет список транзакций и список категорий, которые вы можете использовать, чтобы пометить транзакцию, перетащив транзакцию в категорию. Здорово. Но что влечет за собой перетаскивание? С перетаскиванием происходит много неявных вещей. Во-первых, транзакция должна быть помечена как перетаскиваемая. Другой заключается в том, что категорию следует отредактировать, чтобы показать, что теперь она содержит транзакцию. После этого серверная часть должна быть обновлена ​​новыми данными, когда перетаскивание будет завершено. Наконец, транзакция должна быть не отмечена. Короче говоря, одно действие пользователя — это несколько небольших шагов, объединенных вместе.

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

Здесь на помощь приходит Redux-Saga.

Redux-Saga — это промежуточное ПО, которое обычно используется для выполнения асинхронных действий, таких как выборка данных из серверной части. Собственно, так обычно рекламируют Redux-Saga. Тем не менее, что мне больше всего нравится в Redux-Saga, так это то, что он позволяет группировать действия. Вы создаете нечто, называемое сагой, и эта сага может прослушивать действия и передавать действия в хранилище. Я не буду вдаваться в подробности о том, как работает Redux-Saga, но достаточно сказать, что он поощряет различие между действиями пользователя, которые слушает сага, и простыми общими действиями, которые сага отправляет в хранилище для обработки детали управления государством.

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

Вывод

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