SAP Spartacus 的工作原理与 Hybris Accelerator 不同。SAP 不建议直接复制 Spartacus library 的源代码并在源代码级别上进行修改，这会破坏 Spartacus 的可升级性。 正确的做法，应该将 Spartacus 用作库并使用其他方式（例如依赖注入、组件映射、outlet）来更改其行为。 正确的做法示例
按照这个链接的步骤安装。 新建一个 Angular 应用，取名 mystore，待所有 package 安装完毕后： ng new mystore --style=scss 进入 mystore 文件夹，使用命令行：ng add @spartacus/schematics@3.4 遇到错误消息： Cannot find module '@angular-devkit/core/src/terminal' 原因是我使
默认路由的配置数据定义在 default-routing-config.ts 文件内： 一些例子： login: { paths: ['login'], protected: false, authFlow: true, }, register: { paths: ['login/register'], protected: false, authFlow: true, }, RoutingModule
要编写与 ASM 兼容的代码，开发人员需要使用 UserIdService 中的 takeUserId() 函数来确定 OCC 调用中使用的 userId。 这通常在一个服务中完成，该服务调度一个在有效负载中包含 userId 的 Action. 在 Spartacus 官方支持 ASM 场景之前，在代表经过身份验证的用户发送的请求中，OCC userI
辅助服务模块 (ASM) 使客户服务人员能够使用 Spartacus 店面提供实时客户销售和服务支持。 Spartacus 中的辅助服务模块功能需要 SAP Commerce Cloud 版本 1905.5 或更高版本。 在 assistedservicewebservices 端点中启用 CORS 需要最低版本 1905.5。 Spartacus 中的 ASM 需要以下
Angular 的 TransferState 类使服务器端渲染 (SSR) 和预渲染 (Prerendered-SSR) Angular 应用程序能够使用从服务器获取的数据并且有效地在浏览器中渲染。 如果您使用的是 SSR 或预渲染应用程序策略，那么该过程大致是这样的： 在服务器上预渲染或渲染应用程序 浏览器获取呈现的 HTML
@目录site-context.module.tsinitSiteContextConfigforRootconfigconfig-loader/site-context-config-initializer.jsresolveConfiggetConfigisCurrentBaseSitegetUrlParamssite-context-config.ts (SiteContextConfig 类)context-config-utils.ts (两个工具函数)getContextParame
Spartacus是一个基于 Angular 的店面，是为SAP Hybris Commerce/ SAP Commerce Cloud设计的。它使用REST API与Hybris Commerce交互。在初始阶段，它就提供了Hybris店面的大部分核心功能。Spartacus 是可扩展和可定制的。 Spartacus有一个解耦的架构，这意味着店面本身作为一个独立的实
大多数客户使用标签管理系统 (TMS) 向Storefront 添加额外的标签。添加这些标签以集成到其他系统，例如搜索或社交爬虫、分析解决方案、销售系统等。使用 TMS 将为应用程序生命周期带来敏捷性，因为无需经过开发周期即可应用更改。 Spartacus 的目标是支持各种 TMS 供应商解决方案。最
Node Express server listening on http://localhost:4200 SSR rendering exceeded timeout 2000, fallbacking to CSR for / SSR rendering exceeded timeout 2000, fallbacking to CSR for /xyz SSR rendering exceeded timeout 2000, fallbacking to CSR for /p/xyz Render
JavaScript 店面通过快速、响应式和交互式页面提供更具吸引力的客户体验。 它允许通过进行更小、更频繁的更改来提供更高的可靠性。使用 JavaScript 技术栈的 Storefront 创新速度更快，因为可以一次向所有体验推出新功能，同时通过提供可重用的业务功能来降低创新成本。 可以克隆 Com
(1) yarn build:libs 这个命令行是完成本地 library 的构建。需要将近10分钟。 (2) 这个命令是完成 shell app 的构建。 yarn build --prod 命令行里出现的 40.76 来自 .env-cmdrc 文件： 需要将近3分钟。 (3) 使用如下命令进行服务器端 shell 应用的构建： yarn build:ssr
首先执行命令行 yarn build:libs, 将所有的 libraries 进行构建，大概需要花费 10 分钟时间。 然后再使用命令行 yarn build 构建 storefrontapp： 全部成功之后，storefrontapp 文件夹： 将文件夹下全部资源文件，拷贝到 tomcat webapps 文件夹下。 访问 url localhost:8080/spa/index
在 Chrome 开发者工具 console 里，输入 gigya(就是 SAP Customer Data Cloud，简称 CDC，被收购之前的名称)，能看到下列信息： account 节点下的 api： localinfo： 在 SAP Spartacus cdc integration library 里面定义了 GigyaLoginPageTemplate 和对应的 content slot：BodyContent 和 Bott
我们知道在 SAP 电商云 Spartacus UI 里，用户可以通过下拉菜单更改当前访问 site 的语言： 监控语言变化的代码： this.subscription.add( this.languageService .getActive() .subscribe((isoCode: string) => this.setDirection(
如下图所示，SAP 电商云 UI，用户的购物车 ID，持久化在浏览器的 local storage 里： 运行时，通过封装好的函数 getStorage 读取： 为什么会触发 State module 的加载？ 并没有直接用到 StateModule： 默认使用 local storage： 新建一个 subscription，自执行： 上图代码的逻辑： unsubscrib
Reference App Structure 这个推荐的 Spartacus 应用程序结构旨在作为您设置自己的 Spartacus 应用程序时的参考。 Spartacus 是一个 Angular 库，这意味着它可以在 Angular 应用程序中单独使用，也可以集成到现有的 Angular 项目中。相反，您可以将任何其他 Angular 解决方案或库添加到
这个 resolver 只针对 Proxy Facade，根据 feature 名称和 FacadeClass，获取对应的 resolver. 该 resolver 知道怎样将函数调用，投递到该 facade 的具体实现类去。 featureName：cartQuickOrderCore 最后得到实际值：cartQuickOrder 返回 resolver 的逻辑放在一个 defer 函数块里了：
下列代码第 126 行，通过来自 Angular/core 的 Injector，手动注入一个 QuickOrderFacade 的实例： 调用这个 facade 的 get 方法，在执行实际被代理类的业务逻辑之前，需要先延迟加载包含该业务类实现的 core module： 只有当类型为 Observable 的方法才会被处理： 这里我们调用 Rxjs 标准的
因为 SAP Spartacus UI 是基于 CMS 驱动的，因此流程是：我们首先在 SAP Commerce Cloud Backoffice 创建新的 content page, CMS Component 以及相关内容，然后再到 SAP Spartacus 层，新建一个 Angular Component，映射到之前 Commerce Cloud Backoffice 里创建的 CMS Component. 步骤1 -
最后的效果： 请求的方法类型和 url 都被记录了下来，同响应一起。 设置断点来观察自定义 HTTP interceptor 运行时原理： 我们自定义的 intercept 也是通过依赖注入的方式被注入到 httpInterceptor 的调度器里。 首先把 method 和 urlWithParams 从 request 里提取出来： 返回的 Obs
首先渲染若干个 div button，个数等于 TabContainer 里包含的 Component 元素个数。 然后是利用 cxComponentWrapper 加载真实的 Component. integration lib 提供的 CMS mapping 没有生效。 但我看到已经配置进去了？ 这不是调用了吗？ 我查过了，无论 this.staticCmsConfig
我们以前介绍过，经过 SAP Spartacus 路由配置后的 routes 数组，其 route 数据结构的 Component 属性，清一色指向 generic 的 PageLayoutComponent，那么后者怎么知道自己应该加载哪些 Angular Component 的数据呢？ 我们首先看看是哪些 template 调用了 PageLayoutComponent 的 selector
CMS page API 负责确定 template 显示哪些 slots，slots 显示哪些 Component： [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OtPqTaxm-1635227915586)(https://upload-images.jianshu.io/upload_images/2085791-10b538921bcb2566.png?imageMogr2/auto-or
准则 content page routes 来自后台，而 product，category 的配置位于 Spartacus 层。 无论如何，都允许在 Spartacus 层修改。 例如 product route 配置，位于 default-routing-config.ts: 以 myCompany 为例： http://localhost:4299/powertools-spa/en/USD/organization 请求 url： htt
