在几个博客视频等中，有一个使用Redux的CRUD教程。

他们都没有（冲浪后的AFAIK）在服务器上处理完全异步API，例如即发即弃行为。
CQRS 环境中的主要命令经常处理那些即发即弃的问题。

让我们通过Twitter的一个虚构示例来轻松获得这个想法：

基本上，在同步 CRUD API 的上下文中，您可能有：

除了经典的提取API之外， TweetReducer 可以完全处理 POST_TWEET 操作，因为它可以直接包含新的推文。

但是，在服务器上发生了“即发即弃”API的情况下：

Redux操作： POST_TWEET
服务器API：仅在响应中返回推文的ID（例如位置）。
状态： TweetReducer 无法处理创建，因为在成功操作触发时推文不可用。
因此，一个新的Redux状态专门用于处理标记为 TweetCreation 的推文，通常拥有这些属性：（data: {id: string}, inProgress: boolean, errors: []）。
然后，它会在数据中获取新创建的推文ID，并允许UI听取此状态（ TweetCreation ）。
用户界面：收听TweetCreation状态，因此会显示发送推文，甚至尝试按某个时间间隔获取服务器以获取完整的推文。

有些人尝试在Redux商店添加另一个状态来处理即发即弃的API ，这是一个好习惯吗？

是＆＃34;传统＆＃34;在社区还是有另一种聪明的方式？

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(...)。

对待处理的推文使用相同的状态似乎是一种更简单（因此更好）的方法。