javascript - 终极版/传奇 : Approach for larger API's

Question

我在基于此 real-world example 的小型项目中使用 Redux/sagas 工作流，但这些逻辑并不那么复杂。我应该如何使用更全面的 API(即 Reddit 的 API)而不会使事情变得过于冗长？

• 我是否为每个端点创建了一个const？ IE。， export const fetchUser = login => callApi(`users/${login}`, userSchema)
• 我应该担心管理entity cache吗？ ？
• 有没有办法进一步降低复杂性/样板文件(即针对同一端点使用 get/put/post/delete 进一步分组请求类型)？
• 有没有处理比真实世界更大/更复杂的例子？

Answer 1

我认为答案取决于您希望组件的流动性。

我正在使用 sagas 开发大型代码库，我们的页面分为“类型”，例如“列表”类型、“表单”类型等。

我们有一个 saga 负责获取内容，而每个 pageComponent 在呈现时负责提供端点。

这允许一种非常模块化的方法，添加一个组件来处理文件系统的一个子部分。

我们的页面主要是包含所有这些信息的配置文件，我们使用此配置来呈现具有正确数据的“通用”组件。

Saga 可重用性

我将 Sagas 视为顺序进程，它们可以用于异步获取数据，但它们对于任何需要按顺序处理的事情也很有用。
这些“流程”有时在代码库中非常相似，而这些正是您想要概括的。
正如您所说，最常见的操作是任何端点的 CRUD，可以很容易地组合在一起。

Login 与 loadUserList 截然不同，之后需要发生不同的事情，但是 loadUserList 和 loadRepoList 是极其相似。

影响可重用性的因素

1. 您控制 API 的能力，如果您可以决定您使用的 API 的形状，您就可以在前端实现更多的概括。

2. 应用程序的形状(正面)- 您的页面是否奇怪地依赖于彼此的状态？例如，保险计划的表格相互链接并不少见，您可以按任意顺序填写前 3 个表格，但一旦所有三个表格都完成，第 4 个表格就会解锁。
   这些依赖项中的每一个通常都会有自己的 saga 来控制您的使用故事的流程。

3. 您的应用程序是否需要同步？您可以轻松创建 sagas，自动与您的不同端点同步数据并更新您的 Redux 状态，这里有很多需要考虑的地方，包括我们是否决定用新数据打断用户(我们可能想让他知道他正在编辑的表单有过时的数据)- 同步需要一个独特的 saga，因为通常有各种业务规则何时同步什么数据 - 如果规则非常不同，这可能会迫使您创建多个 saga)

可以统一的通用 Sagas

1. UserSagas - 登录、注销。
2. FetchData - 获取单个记录或集合。
3. DeleteData - 删除单个记录或一组 ID
4. 数据同步 - 定期从远程更新您的本地数据。

关于实体缓存

实体缓存只是他们取的一个名字，但这又回到了前面提到的要点。

您的应用程序是在陈旧数据上运行，还是每次加载组件时都从服务器获取数据？
如果数据只被获取一次并且你显示陈旧数据，你将把它存储在一种缓存中(基本上就是 redux 存储)。
如果您显示过时的数据，这就是要走的路。