Flux 与全局变量(在服务中)

Fil*_*p T 5 architecture design-patterns flux ngrx angular

我正在 Angular/NGRX 中开发 Flux 应用程序。与我一起工作的一位实习生说,他在他的第一个应用程序之一中使用了角度服务来存储数据。乍一看,这对我来说似乎是不正确的方法,但经过一段时间的考虑,我发现它与助焊剂存储的想法没有太大区别。您认为这种方法的优点和缺点是什么?
使用 ngrx 存储、操作、减速器等,而不是仅仅使用一些 getter/setter 的普通角度服务,是否会更好?
谢谢!

byg*_*ace 5

对我来说,区别在于便利性和一致性的问题。

\n\n

您可以轻松地将大多数 redux 原则(不变性、纯函数、可观察等)应用于角度服务。因此,您可以获得与商店相同的许多好处(可预测的状态突变、可测试性、性能……)。

\n\n

就便利性而言,有些好处比其他好处更容易实现。例如,使用scan操作符模仿减速器很容易,但如果您想要在创建投影 ( createSelector) 时获得记忆,那么这可能需要更多的工作。如果您发现您喜欢调度操作(命令模式),那么您可以创建自己的事件总线。如果您发现自己喜欢出色的调试工具(Redux DevTools chrome 插件),那么您必须编写自己的集成。因此,您应该查看已经用 ngrx 编写的工具的优点,确定您真正想要的工具,然后决定是否真的值得自己编写。

\n\n

就一致性而言,在许多情况下,其他人必须处理“您的”代码。使用经过行业测试的框架有很大的好处。它可以防止您重新发明轮子(不正确地),通常有很好的文档围绕它(与您的个人框架不同),并且您可以在社区中找到已经了解它或在您遇到问题时可以为您提供支持的人。因此,如果您发现自己正在编写的不仅仅是简单的可观察服务,您可能需要退一步思考一下您正在创建的怪物。

\n\n

此外,Redux 不仅仅是一套工具,它还是解决问题的心理框架。拥有这样的框架可以为整个团队的开发实践带来一致性。当技能差距较大时,这一点尤其重要。在框架中,一切都有其位置,因此您知道在哪里寻找东西。同样,您可以自己定义这一点,只需衡量开发、教学和支持的努力即可。

\n\n

此外,这家商店是全球性的。尽管您可以创建一个可观察的、整体的、上帝服务,但我希望这不是您的计划(请不要这样做)。您可能正在创建多个较小的可观察服务。全局有利有弊,所以这取决于您的情况是否认为这是一个优势。

\n\n

但使用商店也是有成本的。有很多样板(一大堆!!!)。另外,我的主要抱怨是,我的消费者与生产者分离(商店位于他们之间)。因此,我可以编写任何 rxjs 魔法,我可以根据订阅在需要时管理获取数据(ngrx 轮询以在订阅时刷新数据)。

\n\n

所以恕我直言,一般来说,如果您只需要简单的可观察、可共享的数据,那么就使用服务。如果您需要更多,请前往商店。它在很大程度上取决于您的应用程序,但我宁愿从简单的服务开始,并在需要时将其移至商店。最好的建议来自react-howto,其中写道:

\n\n
\n

“你\xe2\x80\x99会知道什么时候需要Flux。如果你\xe2\x80\x99不确定是否需要它,那么你\xe2\x80\x99就不需要它。”

\n
\n\n

进一步阅读:https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/

\n