大多数客户使用标签管理系统 (TMS) 向Storefront 添加额外的标签。添加这些标签以集成到其他系统，例如搜索或社交爬虫、分析解决方案、销售系统等。使用 TMS 将为应用程序生命周期带来敏捷性，因为无需经过开发周期即可应用更改。

Spartacus 的[目标](https://github.com/SAP/spartacus/issues/5062)是支持各种 TMS 供应商解决方案。最流行的标签管理器似乎是 GTM，但我们不想将架构以及技术实现局限于 GTM。此外，CDS 也依赖于类似的概念。

TMS 解决方案可以通过所谓的数据层进行集成。尽管不存在官方的数据层标准，但核心原则是相同的：应用程序将数据推送到中央 JavaScript 对象。

谷歌标签管理器 (GTM) 支持窗口对象上的平面 dataLayer 数组，而 Adobe Launch 是由更复杂的 JavaScript 对象驱动的在窗口对象上调用 digitalData。这两种解决方案似乎都没有提供 API，因此我们不得不直接操作这些全局 JSO。

将 Spartacus 与多个标签管理器集成的高级架构如下图所示。 该示例描述了与 GTM 的集成，但其他标签管理器可以以类似的方式集成。

![](https://img-blog.csdnimg.cn/img_convert/edd29630c4ab1001f64392769652211f.png)

# event service

ngrx action 是事件系统的重要来源，典型的例子就是 Spartacus 购物车组件里对 EventService 的使用。感谢 Spartacus 中的通用事件系统，开发人员可以在其中轻松观察事件。

为了与现有的 ngrx action 解耦，我们将 ngrx action 在底层映射到公共 EventActions。 EventActions 很可能会成为 Spartacus 中的标准，而不是低级别的 ngrx action. 这主要是因为我们将来可能会考虑 `sunset`掉 Spartacus 中的 ngrx 实现。

虽然 Store 中有大量可用的 (ngrx) 操作，但这些操作主要由来自后端的数据集成驱动。还有许多其他事件也可以考虑在内，例如路由器事件、滚动事件、鼠标交互等。虽然我们可以从简单的 mvp 开始映射现有的存储操作，但设计不应仅限于单一事件源。可以使用多个 EventService（我们可以使用多个 EventService 注入令牌）。

我们可能需要考虑事件有效负载。事件有效负载可以为事件保留一些（元）数据。这对于事件系统非常有用且高效，因此事件订阅者不需要从头开始收集所有数据。

ITPub博客

SAP Spartacus 的 TMS 和 Event Service 实现的关联关系

最新文章