TLDR;
npm install redux-thunk-routine
Мотивация
redux-thunk
дает нам возможность создавать асинхронные действия, но вам не кажется, что вы снова и снова пишете шаблонный код?
Вы чувствуете, что все становится еще хуже, когда вы пытаетесь добавить статическую типизацию?
Вдохновившись redux-saga-routines, библиотекой для redux-saga
, у нас есть redux-thunk-routine для redux-thunk
!
Так что же такое routine
? Давайте объясним это на примере.
Разобраться с рутиной за 1 минуту
Представьте, что мы создаем асинхронное действие для получения данных с помощью API, мы могли бы написать код, как показано ниже:
Глядя на пример, мы могли бы обнаружить, что есть запах шаблона:
Для каждого thunk
:
- Нам нужно определить 3 константы:
REQUEST
,SUCCESS
,FAILURE
- Нам нужно определить 3 создателя действий:
request
,success
,failure
- У нас такой же логический поток диспетчерских действий
Что, если я скажу вам, что есть умная штука под названием routine
, позволяющая сократить эту повторяющуюся работу?
Давайте посмотрим на routine
версию предыдущего примера:
Видите, нет необходимости определять константы и генераторы синхронных действий:
Каждый routine
имеет 3 определенных типа действий:
routine.REQUEST
routine.SUCCESS
routine.FAILURE
У каждого routine
есть 3 определенных создателя действий (их типы также четко определены):
routine.request()
routine.success()
routine.failure()
Дальнейшее обсуждение
Удалите шаблон из создателя действия thunk
Вместо отправки 3 действий в каждом thunk
вручную, как показано выше, мы можем заменить его, как показано ниже:
Фактический поток такой же, но мы пишем гораздо меньше кода.
Если вы хотите перезаписать процесс создания полезной нагрузки для действия запроса и действия при отказе, вы можете использовать 3-й параметр:
Ввод для редуктора
При использовании redux-thunk-routine
тип полезной нагрузки уже проверяется при отправке, поэтому безопасно использовать Action<any>
при определении редьюсера:
Однако, если вы все еще хотите строго добавить тип действий в сигнатуру редуктора, вы можете обратиться к приведенному ниже коду:
Получить типизированную полезную нагрузку в редукторе
Чтобы получить доступ к типизированной полезной нагрузке внутри редуктора, вы можете использовать эти функции:
routine.isSuccessAction()
routine.isFailureAction()
routine.getSuccessPayload()
routine.getFailurePayload()
Пример:
Как использовать getState
с getThunkActionCreator
?
Ну, есть дебаты об использовании getState
в создателях действий, и это было проиндексировано в этом блоге.
ИМО, лучше позволить компоненту выбрать все необходимые состояния перед отправкой thunk
. Потому что поток и логика thunk
таким образом выглядят проще и их легче тестировать.
В соответствии с этим параметр getState
не передается функции-исполнителю при использовании getThunkActionCreator
.
Однако, если вам нужно вызвать getState
в некоторых случаях, вы можете сделать это, определив другого создателя действия thunk для отправки thunk
, созданного routine
:
Другие преимущества использования подпрограмм
При использовании routine
мы вынуждены следовать общему шаблону для именования наших типов действий. Это дает нам огромное преимущество, если мы хотим получить больше повторяющейся логики в редьюсерах.
Например, мы можем реализовать глобальный редьюсер загрузки и глобальный редуктор ошибок на основе регулярного выражения для соответствия типам действий, а затем удалить ветки обработки действий «ЗАПРОС» и «ОШИБКА» в других редьюсерах.
Подробности в этом блоге.