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