当您处理多个主要详细信息视图时，最佳做法是在反应应用程序中获取详细信息数据？
举个例子，如果你有 - / rest / departments api返回部门列表 - / rest / departments /：departmentId / employees api返回部门内的所有员工。
要获取我使用的所有部门：
componentDidMount() {
this.props.dispatch(fetchDepartments());
}但是生病需要一个逻辑来获取每个部门的所有员工。在部门减速器逻辑中为每个部门调用员工行动创建者会是一个好主意吗？
在渲染方法中调度员工操作对我来说不是一个好主意。
当然，在部门减速器内调用员工动作创建者是一个坏主意，因为减速器应该是纯函数;你应该在你的fetchDepartments动作创建者中做到这一点。
无论如何，如果您需要为每个部门（而不仅仅是所选部门）获得所有员工，那么进行许多API调用并不理想：如果可能，我会要求后端开发人员拥有一个返回数组的端点部门和每个部门的嵌入式员工队伍，如果数字当然不是太大......
大老“取决于”
最后，您需要选择一种方法，看看它如何与您的特定数据和用户需求协同工作。这在某种程度上也会处理网络问题，例如延迟。在一个非常好的网络环境中，例如我是网络管理员的前三保险公司，您可以实现超低延迟的网络呼叫。在这种情况下，多个网络请求将与房主基于互联网的环境明显不同。即便如此，你还是要考虑各种各样的可能性。而且你总是需要考虑你的最终目标。
（不要在技术方面过于苛刻，但延迟可以相当准确地定义为“您等待网络请求实际开始发送数据的时间”。这可能很重要的一个典型示例是在线第一人称射击游戏游戏。你点击拍摄，数据不会像你想要的那样快速传输，因为网络正在等待发送数据，然后你就死了。带宽比延迟更有用的典型例子是下载或上传大文件。你必须等待一两秒才能移动实际数据，但是当它移动时你可以在几秒钟内下载一个GB，那么哦，我会接受它。）
目前，我的网站多次调用加载动态菜单和动态内容。这是非常小的数据。这是在三个单独的电话中完成的。在网上。这是“好的”，但我不会说这是“好”。由于用户正在等待所有这一切甚至开始，我不妨把它全部放在一个网络呼叫中。此外，如果两个调用正常，那么第三个调用会稍微窒息，用户可能开始导航，然后弹出更多菜单并且它不理想。这就是为什么无论如何，您必须考虑您的具体需求，以及可能适用的可能用例范围。 （我目前正在重写整个网站）
正如之前（在我看来“好”）的回答所说，将整个数据集一次性地拍摄给你可能是有意义的。在我看来，这是一个内部的，或至少是商业应用程序，具有良好的网络，更重要的是，没有失去客户的风险，因为你的东西没有加载超快。
也就是说，如果事情不顺利，特别是如果你在谈论大型数据集，那么考虑一个延迟加载架构。例如，您的用户在看到部门之前无法联系到员工。因此，根据您的网络和大数据大小，加载部门，然后在它返回后启动员工数据的异步加载可能没问题。当您的用户浏览部门名称时，现在正在加载员工数据。
您可能想澄清的一个大问题是，是否有任何员工列表数据与部门一起呈现。在我的一个案例中，我有一个工作订单系统，我在登录后加载，但是很懒，当它被加载时，它会在工作订单菜单上抛出一个徽章，以显示有多少未完成。由于我没有很多订单，基本上是一秒等待。没什么大不了的。它不像用户必须等待它加载才能开始工作。如果你想要每个部门的徽章，那么它可能会变得奇怪。如果按部门加载，您可以随机弹出多个徽章。在这种情况下，它可能会导致用户混淆，并且在一个大块中加载它可能是一个不错的选择。如果用户不得不等待，它可能会产生一个较少的呼叫，用户询问“这样做是否正常？”。特别是对于工作场所的软件，在工作日开始时必须等待初始加载更为可接受。
需要明确的是，要考虑所有这些复杂情况，您必须尽可能地利用软件编码实践进行开发。这样，您就可以编写一个解决方案，如果它不能满足您的性能或用户需求，那么进行更改并不是一场噩梦。在一个小数据的一般情况下，我只是将它加载到一个大口中开始，如果加载时间有问题则从那里复杂化。从一开始就使代码复杂化，没有明确需要的原因是将代码混乱到使其完全难以维护的好方法。
第三点，如果您正在处理企业规模数据集，那就完全不同了。然后你必须处理分页，是的，它会变得有点复杂。
问候，
DB
我不确定fetchDepartments究竟做了什么，但我确保从Redux中间件执行实际的fetch请求。通过从中间件进行操作，您可以指纹/缓存/去除所有请求，并在应用程序中制作单个请求，无论有多少组件请求该事物。
通常，中间件是处理异步副作用的最佳位置。