我已经基于real-world example在小型项目上使用Redux / sagas工作流，但是这些逻辑并没有那么复杂。我应该如何使用更全面的api（即Reddit的API），而又不会过于冗长？
我是否为每个端点都创建一个const？即export const fetchUser = login => callApi(`users/${login}`, userSchema)
我应该担心管理entity cache吗？
有没有办法进一步降低复杂性/样板（即对同一端点使用get / put / post / delete进一步分组请求类型）？
有没有比real-world更大或更复杂的例子？
最佳答案
我认为答案取决于您希望组件的流动性。
我正在使用sagas开发大型代码库，我们的页面分为“类型”，例如“列表”类型，“表单”类型等。
我们有一个传奇故事负责获取内容，而每个pageComponent呈现时则负责提供端点。
这允许采用非常模块化的方法，添加处理文件系统的一个子部分所需的组件。
我们的页面主要是一个包含所有这些信息的配置文件，并且我们使用此配置来呈现具有正确数据的“通用”组件。
Saga可重用性
我将Sagas视为顺序过程，它们可以用于异步获取数据，但是它们对于需要按顺序处理的任何事情也很有用。
这些“流”有时在代码库中非常相似，而这些正是您要概括的。
就像您说的那样，最常见的操作是任何端点的CRUD，可以轻松地将它们组合在一起。Login与loadUserList极为不同，之后需要发生不同的事情，但是loadUserList和loadRepoList极为相似。
影响可重用性的事物
您具有控制API的能力，如果可以决定所使用的API的形状，则可以在前端获得更多的概括。
应用程序的形状（前向）-您的页面奇怪地依赖于彼此的状态吗？例如，保险计划具有相互链接的表格并不少见，您可以按所需的任何顺序填写前3个表格，但是一旦这三个表格都完成，第4个解锁即可。
这些依赖关系中的每一个通常都会有自己的传奇，这些传奇决定着您使用故事的流程。
您的应用程序需要同步吗？您可以轻松创建可自动与不同端点同步数据并更新Redux状态的sagas，这里有很多要考虑的因素，包括是否我们决定用新数据打扰用户（我们可能想让他知道他正在编辑的表单具有过期的数据）-同步需要一个独特的传奇，因为何时同步什么数据通常会有各种业务规则-如果规则非常不同，这可能会迫使您创建多个sagas
可以整合的常见Sagas
UserSagas-登录，注销。
FetchData-获取单个记录或集合。
DeleteData-删除单个记录或ID集合
数据同步-定期从远程更新本地数据。
关于实体缓存
实体缓存只是他们选择的名称，但这可以追溯到前面提到的要点。
您的应用程序是否在旧数据上运行，还是在每次加载组件时从服务器获取数据？
如果仅提取一次数据并显示陈旧数据，则将其存储在某种类型的缓存中（基本上是redux存储）。
如果显示过时的数据，这就是方法。
关于javascript - Redux/sagas:大型API的方法，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/43895719/