首页 > 解决方案 > 解析器与 Redux

问题描述

我已经在使用 Angular 的中小型项目中工作了很长时间,只要有一些数据需要从服务器加载,团队就会直接将其存储到 Redux 存储中。这允许在用户在“页面”之间导航以及他们决定刷新页面时保留数据。

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

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

是否有更多使用我不理解的 Redux 的理由,或者使用这种方法有更多的缺点?

标签: angularreduxangular-resolverangular-redux

解决方案


是 redux 的创建者的一篇非常有名的文章。它被称为你可能不需要redux。

Angular 是一个众所周知的解决数据间依赖问题的框架。如果事件和数据绑定的组件间通信对您有效并且通过服务进行缓存是可以的,不会导致以下问题,那么您应该坚持使用它们。

为什么?

  1. 对于大多数学习曲线陡峭的开发人员来说,Redux 是违反直觉的
  2. 需要大量样板代码,如果你不需要它的权衡,那么你不应该打扰它

Redux 和 Flux 通常被误解并以错误的方式广泛使用。有迹象表明您何时需要使用 redux,您可以在angular univercity中看到这些迹象。它几乎说以下内容

React 组件按层次结构排列。大多数时候,您的数据模型也遵循层次结构。在这些情况下,Flux 不会给您带来太多收益。但是,有时您的数据模型不是分层的。当你的 React 组件开始接收感觉无关紧要的 props,或者你有少量组件开始变得非常复杂时,那么你可能想要研究 Flux。

你有一条数据需要在你的应用程序的多个地方使用,通过 props 传递它会使你的组件打破单一职责原则(即让它们的界面变得不那么有意义)

有多个独立的参与者(通常是服务器和最终用户)可能会改变该数据

在任何其他情况下(并且当上面的示例受到限制时),我会选择不使用 redux 并使用 Angular 开箱即用的解析器、守卫和服务。


推荐阅读