我问自己，直接订阅 NGRX 操作流是否被认为是代码味道。
考虑以下用例：
假设我有一个存储在 NGRX 存储中的实体列表。通过 UI 更新一批实体会为效果侦听的每个更新实体分派操作。该效果确实会调用 REST 调用，并根据 REST 调用的成功情况调度后续操作。为了通知 UI（想想进度条或错误提示），我可能
订阅操作流最适合我，因为只要进程持续，我就可以使存储不受具有生命周期的进程状态的影响，即进程完成后，状态不再重要。但这是否被认为是代码味道，因为我不消耗通常通过商店流发送的操作的有效负载。
是什么让我在这里写这个问题的原因是
我知道这些想法不会有唯一的答案。这更像是询问如何解决问题的一些提示和观点。也就是说，感谢您分享的任何想法。
我发现您有几个问题必须单独解决。让我们从主要问题开始：
订阅 NGRX 操作流是否被视为代码异味？
是的。操作流有其目的，并且（在我看来）它有很好的文档记录。
我不知道存储是否最好仅用于域/实体数据，因为建模过程状态现在感觉很奇怪（也许只是因为我缺乏经验）
不。因为否则 NGRX 团队不会将路由器的状态等信息放在那里。此外，“应用程序状态”这个名称意味着存储不仅可以包含纯数据，因为仅仅数据实体当然不能描述整个应用程序及其行为方式。 但这当然并不意味着你的奇怪感觉是错误的。也许这个应用程序真的是以一种奇怪的方式实现的（我也见过这个）。
当您有一个多步骤流程，其中只有几个步骤可以解决商店问题时，是否应该将整个流程建模为操作和效果
直到一定程度。如果您发现自己对长命令链进行了硬编码，我肯定会审查您的方法。
由于调度操作和状态更改列表有些松散耦合，因此向操作引入唯一的 id 是否是侦听特定操作已完成的常见方法？
坦白说，我不明白这个问题。每个动作都必须有一个唯一的 ID，否则整个减速器/效果逻辑将无法工作。
这里有一个关于 NGRX 的精彩视频：https://www.youtube.com/watch?v=JP4dEM4bjE8