如何使用助焊剂商店

Question

Flux 的大多数示例都使用待办事项或聊天示例。在所有这些示例中，您存储的数据集有点小，并且保存在本地，因此不确定我计划使用的商店是否符合不断变化的“方式”。

我打算使用商店的方式有点像 ORM 存储库。一种以多种方式访问​​数据并将数据持久保存到数据服务的方法，无论是什么方式。

假设我正在构建一个项目管理系统。我可能会有这样的数据检索方法：

• getIssueById
• 按项目获取问题
• getIssuesByAssignedUser
• getIssueComments
• getIssueCommentById
• 等等……

我也会有这样的方法来将数据持久化到数据服务：

• 添加问题
• 更新问题
• 删除问题
• 添加问题评论
• 等等……

我不会做的一件主要事情是在本地存储任何问题数据（就此而言，大多数存储与数据存储相关的数据）。大多数数据对于更新很重要，因为自从我上次检索该问题以来，问题状态可能已经更新。我所有的数据检索方法可能总是向最新数据发出 API 请求。

这是违背通量“方式”的吗？以这种方式处理通量有什么问题吗？

Answer 1

我不会太拘泥于“商店”这个词。如果您希望组件呈现某些内容，则需要以某种方式创建应用程序状态。如果每次发出不同的请求时都需要清除该状态，那没问题。以下是使用 getIssueById() 的流程示例：

1. 组件调用 store.getIssueById(id)
2. 返回空对象，因为问题不在商店的缓存中
3. 商店调用 action.fetchIssue(id)
4. 组件呈现空状态
5. 服务器响应问题数据并调用 action.receiveIssue(data)
6. 存储缓存该数据并调度更改事件
7. 组件通过调用store.getIssueById(id)响应事件
8. 问题数据返回
9. 组件渲染数据

持久性更改类似，只有最近的服务器响应保存在存储中。

1. 组件中的用户交互触发 action.updateIssue(modifiedIssue)
2. 存储处理操作，将更改发送到服务器
3. 服务器响应更新的问题并调用 action.receiveIssue(data)

...等等，从上面的最后 4 个步骤开始。

如您所见，这实际上并不是对数据进行建模，而只是控制数据的流入和流出方式。