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

Зачем упрощать?

Обратите внимание, что мы написали много шаблонного кода только для обработки одного вызова API. Кроме того, код станет повторяющимся для нескольких вызовов, что противоречит DRY и другим методологиям написания программного обеспечения.

Процесс упрощения

Мы выберем каждое из наших действий, типов, редьюсеров и упростим их одно за другим.

Действия и типы

Вот как мы пишем наши действия и типы в этом подходе:

Обратите внимание, что здесь есть 3 действия и 3 типа. И тот же шаблон будет повторяться для каждого вызова API. Представьте, если есть 10 вызовов API. Это означает, что будет 30 действий и 30 типов, которые нужно будет написать вручную. Чтобы избежать этого, мы напишем вспомогательную функцию, которая будет принимать одну входную строку и возвращать все это. Функция будет выглядеть примерно так:

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

const getUsersList = actionCreator('GET_USERS_LIST')

Это даст все необходимые действия и типы.
Следующий вопрос, как все это использовать. Ответ довольно прост. getUsersList — это объект, поэтому соответствующие действия и типы будут следующими:

  • getUsersList.request вместо getUsersListRequest
  • getUsersList.success вместо getUsersListSuccess
  • getUsersList.failure вместо getUsersListFailure
  • getUsersList.REQUEST вместо GET_USERS_LIST_REQUEST
  • getUsersList.SUCCESS вместо GET_USERS_LIST_SUCCESS
  • getUsersList.FAILURE вместо GET_USERS_LIST_FAILURE

Редуктор

Вот как выглядит текущий редуктор, и его можно использовать только для одного вызова API.

Редуктор теперь будет изменен на это:

Обратите внимание, что здесь мы сделали 2 вещи:

  • Мы объединили соответствующие случаи переключения вместе и перенесли логику хранилища обновлений в новую функцию reducerHandler.
  • Мы добавили ключ usersList, который будет содержать все состояние для этого конкретного API. Это гарантирует, что один и тот же редуктор можно использовать для нескольких вызовов API.

Давайте теперь посмотрим определение функции reducerHandler (вспомогательная функция будет написана только один раз):

Хотя мы добавили несколько функций, может показаться, что код увеличился, но обратите внимание, что задача создания нескольких действий, типов и редюсеров сводится к нескольким строкам. Теперь, если нам нужно сделать новый вызов API, добавляется всего одна строка для создания действий и типов и несколько строк добавляется в редюсеры вместо того, чтобы писать около 50 строк и добавлять новый редюсер. Это сильно упрощает код.

Интеграция с промежуточным ПО

Другая часть вызовов из саг и диспетчерских действий останется прежней. Давайте посмотрим на пример:

Это поможет поддерживать чистоту кода и поможет разработчикам повысить производительность и сосредоточиться на других областях.

Исчерпывающий пример

Чтобы показать, как работает этот подход, приведем пример всего с тремя вызовами API:

Старый подход

Упрощенный новый подход

Если вы видите, усилие уменьшается почти на 1/3 с тем же желаемым эффектом.

Мы все? Да! На этом этапе количество повторяющейся логики сокращается, а код упрощается. Можем ли мы еще упростить это? Возможно, но советовать не буду. Мы даже можем написать оболочку, чтобы вообще не писать действия и редукторы, но это может принести больше вреда, чем пользы.

Существуют ли библиотеки, которые могут предоставить эти утилиты?

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

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

Первоначально опубликовано на https://dev.to 18 декабря 2020 г.