reactjs - 使用“即发即弃”API 分配专用于实体创建的 Redux 状态是否是一种好习惯？

Question

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

它们中没有一个（冲浪后的 AFAIK）处理服务器上的完全异步 API，例如即发即弃行为。CQRS环境中的
主要命令经常处理这种即发即弃的情况。

让我们以 Twitter 的虚构示例来轻松理解这个想法：

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

• Redux 操作：POST_TWEET
• 服务器 API：在响应数据中返回整个创建的推文。
• 状态：TweetReducer从响应中探索和存储创建的推文数据。
• UI：直接从Tweet状态 收听新推文。

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

但是，在服务器上的即发即弃 API 的上下文中：

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

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

在社区中是“常规”还是有其他聪明的方法？

标签： reactjsasynchronousreduxarchitecturecqrs

Answer 1

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

结论

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

其他注意事项（对于两种方法）

• 我省略了有关在更新时避免直接状态突变的细节，因为这是非常基本的。
• 您可能需要执行一些操作，例如为待处理的推文生成一个临时 id 并将其从服务器发送回，以便您可以在SET_TWEET_ID.
• 临时 id 可以使用不同的对象键（或使用附加标志），以便您可以区分组件中的待处理推文和已确认推文（例如，在待处理推文旁边呈现加载图标）。
• 替换[]为{}使用 id 作为对象键可能会更好（取决于确切的要求），但这不是这个问题的重点。