Resolver vs Redux

Question

我已经在有角的中小型项目中工作了很长一段时间，只要有一些数据需要从服务器加载，团队就会直接将其存储到Redux存储中。这样，当用户在“页面”之间导航时，如果用户决定刷新页面，就可以保留数据。

然而，最近我一直在做一个“适当的”角度教程，我们通过组合服务(在app.module.ts中提供)实现了相同的结果，以保留数据和解析器。解析器确保在加载主页面时，所需的数据被加载到服务中。此外，如果数据不太大，我甚至可以将其存储到localStorage中，因此，如果数据不存在，则消除解析器中的HTTP请求。

除了不太可能的用例( 1.需要加载大量数据)和2.用户由于某些原因经常刷新网页之外，我不太明白为什么我们应该实现一个完整的redux存储。

是否有更多的理由使用Redux (我还没有理解)，还是使用这种方法有更多的缺点？

Answer 1

这是redux的创建者写的一篇非常著名的文章。它叫你可能不需要重来。

角是已知的解决了数据间依赖问题的框架。如果事件和数据绑定的组件间通信对您有效，并且通过服务进行缓存没有引起以下问题，那么您应该坚持使用它们。

为什么？

1. 对于大多数学习曲线陡峭的开发人员来说，Redux是违反直觉的。
2. 需要大量的样板代码，如果你不需要它，那么你就不应该去理会它

在一般情况下，残差和通量被错误地解释和广泛使用。有迹象显示您何时需要使用redux，您可以在角均匀性中看到它。它大致上说如下

反应组件排列在层次结构中。大多数情况下，您的数据模型也遵循层次结构。在这种情况下，Flux不会给你买多少钱。然而，有时您的数据模型并不是分层的。当您的反应性组件开始接收到感觉无关的道具时，或者您有少量的组件开始变得非常复杂，那么您可能需要查看Flux。 您有一段数据需要在应用程序中的多个地方使用，通过道具传递数据会使组件打破单一责任原则(即使它们的接口变得不那么有意义)。 有多个独立的参与者(通常是服务器和终端用户)可以对数据进行变异。

在任何其他情况下(当上面的例子是有限的)，我会选择不使用redux，使用Resolver、Guards和服务，这些服务都是开箱即用的。