TLDR;

npm install redux-thunk-routine

Мотивация

redux-thunk дает нам возможность создавать асинхронные действия, но вам не кажется, что вы снова и снова пишете шаблонный код?

Вы чувствуете, что все становится еще хуже, когда вы пытаетесь добавить статическую типизацию?

Вдохновившись redux-saga-routines, библиотекой для redux-saga, у нас есть redux-thunk-routine для redux-thunk!

Так что же такое routine? Давайте объясним это на примере.

Разобраться с рутиной за 1 минуту

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

Глядя на пример, мы могли бы обнаружить, что есть запах шаблона:

Для каждого thunk:

  1. Нам нужно определить 3 константы: REQUEST, SUCCESS, FAILURE
  2. Нам нужно определить 3 создателя действий: request, success, failure
  3. У нас такой же логический поток диспетчерских действий

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

Например, мы можем реализовать глобальный редьюсер загрузки и глобальный редуктор ошибок на основе регулярного выражения для соответствия типам действий, а затем удалить ветки обработки действий «ЗАПРОС» и «ОШИБКА» в других редьюсерах.

Подробности в этом блоге.