咱们应用 NgRx 存储来治理 Spartacus 性能中的全局应用程序状态。应用 NgRx 在性能、更好的可测试性和易于故障排除、方面具备显著的劣势。
除非有令人信服的理由不这样做，否则在某项 feature 的开发里，请总是应用 Rgrx 来治理状态。
应用 Store 并不意味着咱们须要缓存所有内容。缓存应该有目标的应用，并在有意义的中央应用。通常，CMS 数据是缓存的良好候选者，而应用程序数据则不是。
如果要从 UI 组件调用应用 NgRx 逻辑的性能，则应实现外观服务性能以公开性能并将 NgRx 代码封装在外围库中。
NgRx 的复杂性被封装在外围库中。门面服务可从外围库中取得。外观服务公开了外围库性能，但它们在其实现中暗藏了 NgRx 逻辑。
内置 Spartacus UI 组件不应蕴含 NgRx 逻辑。相同，UI 组件应该调用外观服务函数。
上面是 unit Component 里应用 service 类的一个例子：
能够为每个页面更改站点上下文。对于不同的站点上下文，响应数据可能不同。
此外，登录用户和匿名用户可能会看到不同的响应数据。在页面上工作时，请思考到用户能够通过登录或登记更改其登录状态。
尽量放弃模块尽可能小。在大多数状况下，一个模块只有一个组件。此外，咱们应该始终尝试缩小模块依赖性。
单元测试必须笼罩所有代码。
对于端到端测试，根本的 UI 端到端测试以及可拜访性端到端测试必须始终涵盖面向 UI 的新性能。测试的文件名应以 e2e-spec.ts 结尾。能够重复使用的公共函数应该被提取到不同的文件中，并且应该位于名为 helpers 的子目录中。这些文件应以文件扩展名 .ts 结尾。
如果开发人员有多个用户流测试，请将它们分成独自的文件，以便它们能够并行运行。咱们还倡议将测试分组到具备相干名称的子目录中。