问题描述
对于我们的 Spartacus 项目，我们需要在 checkout 中引入额外的 Data 属性： 我们有这样一种情况，即用户需要为每个产品选择一种交付方式。
在理想情况下，选择后，所选的交付模式将保存在 NGRX 商店和后端中，以符合此处定义的数据绑定原则：https://sap.github.io/spartacus-docs/connecting-to-other-systems/#component-data-binding
预期数据/用户流：
- 用户转到结帐和交付模式步骤
- 自定义 OCC 调用是为了加载每个产品支持的交付模式（取决于产品类型和进一步的客户特定逻辑）
- 显示购物车项目，并通过包含可用交付模式的下拉菜单进行增强
- 用户选择交付方式
- 选择的交付模式存储在 NGRX 商店内的购物车条目中并保存在后端
- 新的购物车总计是根据所选交付方式的成本计算的
- 新的购物车总数存储在 NGRX 商店内的购物车中并保存在后端
- 用户点击继续进入查看订单步骤
- 购物车商品与之前选择的交付方式一起列出
在对现有代码进行一些分析后，我们在 deliveryMode 上发现了一个属性 orderEntry。这似乎没有在斯巴达克斯的任何地方使用，但可以通过遵循此 stackoverflow answer 和 this one 来使第 9 步工作。
有关此流程的问题：
- 我们如何扩展 NGRX 商店？我们假设，可以只扩展外观（活动购物车服务），绕过商店并将信息保存在后端（Described here），然后从后端刷新商店。这个假设正确吗？如果是，那感觉很尴尬，因为我们需要重新加载整个存储区，以便在
deliveryMode 上包含新属性 - 我们如何挂钩购物车总计的价格计算，以根据所选的交付方式更新总计？再说一次，我们如何将新的总金额带入商店？
orderEntry
Slack 频道中似乎有几个答案，但围绕扩展 ngrx 存储的可用答案却很少，尽管对我们来说，这似乎是一项非常正常的任务.. :-/
任何想法、意见或支持将不胜感激。 :-)
解决方法
这似乎很难完成，因为斯巴达克斯不支持每种产品的交付模式。但有些想法：
-
您可以扩展 CartEntry 核心类（适配器、连接器、外观等）以包含添加到购物车的条目的交付模式。您可能需要更改所有内容以包括交付模式设置。所有这些都是公开的，因此您可以根据需要修改它们，包括商店。
-
使用多个购物车，每个购物车有一个产品，并以这种方式设置交付模式。但这在我看来会很麻烦。
就价格计算而言，我假设 OCC 调用返回总价格。对购物车条目的调用是否包括每次条目的交付方式成本？
,我们已经实施了以下解决方案，并且目前有效：
- 在后端增强购物车模型
- 添加新端点以加载每个产品的可用交付模式（绕过 NGRX 商店）
- 添加新端点以保存选定的交付模式（绕过 NGRX 商店）
- 在保存端点后，会触发购物车重新加载，它将在订单条目（通过类型扩充）上具有自定义属性的新购物车总数从后端加载到商店中