Так что я очень опаздываю на вечеринку, но в свободное время я работаю над приложением для составления бюджета. По сути, это большой проект, который поможет мне изучить весь стек 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. Если у вас есть какие-либо вопросы или комментарии, оставьте их ниже!