Flux 与全局变量（在服务中）
Flux vs Global Variables (in services)
我正在 Angular/NGRX 开发 flux 应用程序。与我一起工作的一位实习生说，他使用 angular 服务在他的第一个应用程序中存储数据。乍一看，这似乎是不正确的方法，但经过一段时间的考虑，我发现它与 flux store 的想法没有太大区别。
您怎么看，这种做法的优缺点是什么？
使用 ngrx store、actions、reducer 等而不是简单的 angular 服务和一些 getters/setters 会更好吗？
谢谢！
对我来说，区别在于方便性和一致性。
您可以轻松地将大部分 redux 原则（不可变性、纯函数、可观察性等）应用于 angular 服务。因此，您可以获得许多与商店相同的好处（可预测的状态突变、可测试性、性能……）。
就便利性而言，有些好处比其他好处更容易获得。例如，使用 scan 运算符很容易模仿 reducer，但如果您想要在创建投影 (createSelector) 时获得记忆，那么这可能需要更多的工作。如果您发现自己喜欢调度操作（命令模式），那么您可以创建自己的事件总线。如果您发现自己喜欢出色的调试工具（Redux DevTools chrome 插件），那么您将不得不编写自己的集成程序。所以你应该看看已经用 ngrx 编写的工具的好处，确定你真正想要的，然后决定是否真的值得自己编写。
就一致性而言，在许多情况下，其他人将不得不处理 "your" 代码。使用经过行业测试的框架有很大的好处。它可以防止您（不正确地）重新发明轮子，它通常有很好的文档（与您的个人框架不同），并且您可以在社区中找到已经了解它或在遇到问题时可以支持您的人。因此，如果您发现自己正在编写一个简单的可观察服务之外的任何东西，您可能想退后一步，想想您正在创建的怪物。
此外，Redux 不仅仅是一套工具，它还是解决问题的思维框架。拥有这样的框架可以使整个团队的开发实践保持一致。当存在较大的技能差距时，这一点尤为重要。在框架中，一切都有它的位置，所以你知道在哪里寻找东西。同样，您可以自己定义它，只需衡量开发、教学和支持的努力。
此外，商店是全球性的。尽管您可以创建一个可观察的、整体的、上帝的服务，但我希望这不是您的计划（请不要这样做）。您可能正在创建多个较小的可观察服务。 global有利也有弊，所以看你的情况是不是有利。
但是使用商店也是有成本的。有很多样板（一大堆！！！）。此外，我的主要抱怨是，我的消费者与我的生产者是抽象的（商店在他们之间）。所以我可以编写任何 rxjs 魔法，我可以在需要时根据订阅管理获取数据 (ngrx polling to refresh data when subscribed)。
所以恕我直言，一般来说，如果您只需要简单的可观察、可共享的数据，那么请使用服务。如果您需要更多，请使用商店。它在很大程度上取决于您的应用程序，但我宁愿从简单的服务开始，并在需要时将其移至商店。最好的建议来自 react-howto，它说：
"You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it."
进一步阅读：https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/
我正在 Angular/NGRX 开发 flux 应用程序。与我一起工作的一位实习生说，他使用 angular 服务在他的第一个应用程序中存储数据。乍一看，这似乎是不正确的方法，但经过一段时间的考虑，我发现它与 flux store 的想法没有太大区别。
您怎么看，这种做法的优缺点是什么？
使用 ngrx store、actions、reducer 等而不是简单的 angular 服务和一些 getters/setters 会更好吗？
谢谢！
对我来说，区别在于方便性和一致性。
您可以轻松地将大部分 redux 原则（不可变性、纯函数、可观察性等）应用于 angular 服务。因此，您可以获得许多与商店相同的好处（可预测的状态突变、可测试性、性能……）。
就便利性而言，有些好处比其他好处更容易获得。例如，使用 scan 运算符很容易模仿 reducer，但如果您想要在创建投影 (createSelector) 时获得记忆，那么这可能需要更多的工作。如果您发现自己喜欢调度操作（命令模式），那么您可以创建自己的事件总线。如果您发现自己喜欢出色的调试工具（Redux DevTools chrome 插件），那么您将不得不编写自己的集成程序。所以你应该看看已经用 ngrx 编写的工具的好处，确定你真正想要的，然后决定是否真的值得自己编写。
就一致性而言，在许多情况下，其他人将不得不处理 "your" 代码。使用经过行业测试的框架有很大的好处。它可以防止您（不正确地）重新发明轮子，它通常有很好的文档（与您的个人框架不同），并且您可以在社区中找到已经了解它或在遇到问题时可以支持您的人。因此，如果您发现自己正在编写一个简单的可观察服务之外的任何东西，您可能想退后一步，想想您正在创建的怪物。
此外，Redux 不仅仅是一套工具，它还是解决问题的思维框架。拥有这样的框架可以使整个团队的开发实践保持一致。当存在较大的技能差距时，这一点尤为重要。在框架中，一切都有它的位置，所以你知道在哪里寻找东西。同样，您可以自己定义它，只需衡量开发、教学和支持的努力。
此外，商店是全球性的。尽管您可以创建一个可观察的、整体的、上帝的服务，但我希望这不是您的计划（请不要这样做）。您可能正在创建多个较小的可观察服务。 global有利也有弊，所以看你的情况是不是有利。
但是使用商店也是有成本的。有很多样板（一大堆！！！）。此外，我的主要抱怨是，我的消费者与我的生产者是抽象的（商店在他们之间）。所以我可以编写任何 rxjs 魔法，我可以在需要时根据订阅管理获取数据 (ngrx polling to refresh data when subscribed)。
所以恕我直言，一般来说，如果您只需要简单的可观察、可共享的数据，那么请使用服务。如果您需要更多，请使用商店。它在很大程度上取决于您的应用程序，但我宁愿从简单的服务开始，并在需要时将其移至商店。最好的建议来自 react-howto，它说：
"You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it."
进一步阅读：https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/