3

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

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

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

  • getIssueById
  • 按项目获取问题
  • getIssuesByAssignedUser
  • 获取问题评论
  • getIssueCommentById
  • ETC...

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

  • 添加问题
  • 更新问题
  • 删除问题
  • 添加问题评论
  • ETC...

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

这是反对通量“方式”吗？以这种方式处理通量有什么问题吗？

4

1 回答 1

5

我不会太在意“商店”这个词。如果您希望组件呈现某些内容，则需要以某种方式创建应用程序状态。如果每次发出不同的请求时都需要清除该状态，那没问题。以下是使用 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 个步骤开始。

正如您所看到的，这实际上并不是对数据进行建模，而只是控制数据的出现和消失方式。

于 2014-12-11T20:04:39.450 回答