Customizing CMS Components
Spartacus 店面是基于 JavaScript 的，因此它由大量细粒度的 JavaScript 组件组成。 但是，有一种特殊的组件来呈现 CMS 内容。 CMS 组件在运行时动态添加。 由后端提供的 CMS 组件类型映射到等效的 JavaScript 组件。 映射以可定制的配置提供。 这允许您配置自定义组件以呈现特定的 CMS 组件。
此外，可以定制特定于组件的业务逻辑。 这需要额外的配置，其中自定义服务可以提供给（默认）组件。
通过此设置，可以通过以下方式自定义 CMS 组件：
您可以向 ConfigModule 或直接向 B2cStorefrontModule 提供 CMS 组件配置。 下面的配置展示了如何为 CMS BannerComponent 配置一个自定义的 Angular 组件：
为代码拆分解析块是在构建时完成的，并且取决于代码的导入方式。 如果主块中至少有一个静态导入可用，则代码将被静态捆绑，并且不会生成单独的块。
Accessing CMS Data in CMS Components
与组件相关的 CMS 数据在实例化期间由 CmsComponentData 服务提供给组件。 CmsComponentData 服务包含组件 uid 和 data$，它是组件有效负载的可观察对象。 通过使用 Angular 依赖注入 (DI) 系统，组件和特定于组件的服务可以使用 CmsComponentData。
Customizing Services
使用（复杂）业务逻辑的 Spartacus CMS 组件会将其委托给服务。 这简化了可扩展性，并且出于以下原因也被推荐：
组件仅依赖于单个服务
该服务可能有其他依赖项
可以为自定义业务逻辑提供自定义服务
组件服务被设计为非 singleton 服务，范围限定于组件，因此它们可以直接访问组件范围中提供的 CmsComponentData。 这种设计不适用于 Angular DI 系统，因为 DI 系统没有提供在不更改组件的情况下 overwrite 组件服务的机制。
但是，要配置自定义组件服务，您可以以类似的方式提供服务。 配置是根据组件配置完成的。 在以下示例中，SearchComponent 提供了一个自定义 SearchBoxComponentService：
Guarding Components
通常情况下，某些路线应仅在特定条件下才可访问（即，个人详细信息页面应仅为登录用户打开）。 为此，我们可以使用 Angular Route Guards 在进入路由之前执行一些逻辑（即从后端获取数据或检查用户是否通过身份验证）并决定是否可以打开它或我们应该重定向到其他页面。
页面的内容通常是 CMS 驱动的，因此在 Spartacus 中提出了为每个 CMS 组件配置守卫。 在从后端加载页面的 CMS 组件后，这些组件的所有 Guard 都会被执行。 如果至少有一个守卫决定（即由于缺少身份验证），它允许重定向到其他页面。
注意：当同一页面的多个组件有相同的guard（即AuthGuard）时，只会执行一次。
下面是如何为 CMS 组件配置守卫的示例：
Controlling Server Side Rendering (SSR)
您可能不想在服务器中呈现所有 CMS 组件。 以下是一些何时不在服务器中呈现 CMS 组件的示例：
CMS 组件需要个性化的输入，并且不应该或不能在没有它的情况下呈现
SSR 输出不需要 CMS 组件，出于性能原因，它将从渲染过程中删除
CMS 组件与外部服务交互（延迟）并且与索引和社交共享无关
虽然可以在组件中添加条件逻辑以在 SSR 中呈现（部分）视图，但 Spartacus 为组件提供了一种配置，使其更通用，并避免组件中的任何特定逻辑。 下面是一个例子：
