Является ли хорошей практикой выделение состояния Redux, предназначенного для создания сущностей, с помощью API «запускай и забывай»? - PullRequest
Новая
       7

Является ли хорошей практикой выделение состояния Redux, предназначенного для создания сущностей, с помощью API «запускай и забывай»?

0 голосов
/ 27 апреля 2018

В нескольких блогах и т. Д. Есть учебник по CRUD с Redux.

Ни один из них (AFAIK после серфинга) не имеет дело с полностью асинхронным API на серверах, как, например, fire-and-забудь поведение.
Основные команды в среде CQRS часто имеют дело с подобными действиями "забей и забудь".

Давайте возьмем вымышленный пример Twitter, чтобы легко понять:

По сути, в контексте синхронного CRUD API вы, вероятно, имеете:

  • Действие Redux: POST_TWEET
  • Серверный API: возврат всего созданного твита в данных ответа.
  • Состояние: TweetReducer исследование и сохранение данных созданного твита из ответа.
  • Пользовательский интерфейс: прослушивание нового твита из состояния Tweet напрямую.

TweetReducer , кроме классических API извлечения, может полностью обрабатывать действие POST_TWEET , поскольку оно может охватывать новый твит напрямую.

Однако в контексте API-интерфейса fire-and-Forgot на сервере:

  • Redux Action: POST_TWEET
  • Серверный API: возвращает в ответе только идентификатор твита (например, местоположение).
  • Состояние: TweetReducer не обрабатывает создание, так как твит недоступен во время запуска действия успеха.
    Таким образом, новое состояние Redux, предназначенное для обработки создания твитов, помечено TweetCreation , как правило, обладающее этими свойствами: (data: {id: string}, inProgress: boolean, errors: []).
    Затем он получит идентификатор недавно созданного твита в данных и позволит пользовательскому интерфейсу прослушивать это состояние ( TweetCreation ).
  • Пользовательский интерфейс: прослушивает состояние TweetCreation и, следовательно, отображает, что твит отправляется или даже пытается извлечь сервер через некоторый интервал времени, чтобы получить полный твит.

Является ли хорошей практикой, что некоторые люди экспериментируют с добавлением другого состояния в хранилище Redux для работы с API-интерфейсами "забывай и забывай" ?

Это "общепринятый" в сообществе или есть другой умный способ?

1 Ответ

0 голосов
/ 27 апреля 2018

1. Создание отдельного состояния для ожидающих твитов

Для начала вам нужно изменить TweetCreation на массив в случае, если пользователь сделает второй твит, прежде чем первый подтвердится.

Итак, ваша фигура будет выглядеть так: { pendingTweets: [], confirmedTweets: [] }.

В POST_TWEET вы добавляете новый твит к pendingTweets.
В SET_TWEET_ID вы удаляете соответствующий твит из pendingTweets и помещаете его в confirmedTweets.

В вашем компоненте вы, вероятно, делаете что-то вроде confirmedTweets.concat(pendingTweets).map(...).

2. Используйте то же состояние для ожидающих твитов

Форма будет просто { tweets: [] }.

В POST_TWEET вы добавляете новый твит в tweets.
В SET_TWEET_ID вы обновляете соответствующий твит в tweets.

В вашем компоненте вы делаете tweets.map(...).

Заключение

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

Дополнительные соображения (для обоих подходов)

  • Я упустил подробности о том, как избежать прямых мутаций состояния при обновлении, поскольку это очень просто.
  • Возможно, вам нужно что-то сделать, например, создать временный идентификатор для ожидающего твита и отправить его обратно с сервера, чтобы найти соответствующий твит в SET_TWEET_ID.
  • Временный идентификатор может использовать другой ключ объекта (или использовать дополнительный флаг), чтобы вы могли различать ожидающий и подтвержденный твит в компоненте (например, чтобы отобразить значок загрузки рядом с ожидающими твитами).
  • Замена [] на {} с использованием идентификатора в качестве ключа объекта может быть лучше (в зависимости от точных требований), но это не главное в этом вопросе.
...