流量与全局变量(服务中)

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

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

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

就一致性而言,在许多情况下,其他人必须处理“您的”代码。使用经过行业测试的框架有很大的好处。它可以防止你(不适当地)重新发明轮子,它周围通常有很好的文档(与你的个人框架不同),你可以在社区中找到已经知道它的人,或者在你有问题时可以支持你的人。因此,如果您发现自己正在写任何东西,而不仅仅是一个简单的可观察服务,那么您可能需要后退一步,想想您正在创建的怪物。

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

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

但使用商店也有成本。有很多锅炉板(很多!!!)。此外,我的主要抱怨是,我的消费者被从我的生产者那里抽象出来(商店就在他们之间)。因此,我可以编写任何rxjs魔术,在订阅的基础上,在需要数据时,我可以管理获取数据( ngrx polling to refresh data when subscribed )。

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

“您将知道何时需要流量。如果您不确定是否需要流量,则不需要流量。”

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