如果您过去或曾经在电子商务应用程序中工作过，您可能会遇到必须处理产品显示页面的情况。这是用户决定是否将产品添加到购物车之前看到的页面。与任何其他页面一样，此页面必须快速加载，并且还必须显示有关产品的重要信息，例如描述、图片和可用选项。
可用选项是产品的不同可用变体。例如，男士衬衫通常有不同尺码，但有时商店可能会缺货。对于这种情况，禁用该选择是有益的，以便用户提前知道此变体不适用于该给定产品。
解决此问题的两种方法之一是使用当前选择对后端进行 api 调用，以根据这些选择确定哪些选项可用。例如，如果我选择绿色，我应该只会看到该特定颜色可用的尺寸。如果中号尺寸不提供绿色，则只要之前选择了绿色，则应禁用选择中号的选项。使用第一种方法，将查询数据库以确定基于当前选择的选项哪些是剩余的可用选项。这将在数据库中查询 ProductSkus、ProductSkuOptions 和 ConfigurableOptions，并对这些表进行 10 个不同的查询。这将对每个用户的选择进行。
第二种方式是后端以 SKU 的形式返回可用变体的列表（'ZARA-001-RED-S'、'ZARA-001-BLUE-S'、'ZARA-001-GREEN- S'、'ZARA-001-RED-M'、'ZARA-001-BLUE-M'）。此 SKU 列表可以是产品详细信息 api 调用的一部分，它将添加一个数据库查询，即 ProductSkus.where(product_id:)。此查询 (ruby on Rails) 返回与产品相关的 sku 列表。
第一种方法需要在选择之间具有加载状态，这是可行的，但对于现代 Web 开发标准来说并不理想。第二种方法速度更快，几乎可以立即执行，不需要加载状态。第一种方法将繁重的工作委托给后端，而第二种方法则在前端完成所有繁重的工作，但是前端执行速度会快得多，因为不需要数据库通信。
这篇文章我将重点关注第二种方法。
const updateUIBasedOnSelection = () => {
const newAvailableOptions = filterAvailableOptions(
selectedOptions,
Object.keys(availableOptions),
product.available_skus
)
// Go through each selection and see what is available according to the other selections
Object.keys(availableOptions).forEach(type => {
const selectedOptionsCopy = { ...selectedOptions }
delete selectedOptionsCopy[type] // remove the current selection so we can see what is available according to the other selections
const newAvailableOptionsWithSelf = filterAvailableOptions(
selectedOptionsCopy,
Object.keys(availableOptions),
product.available_skus
)
newAvailableOptions[type] = new Set([...newAvailableOptions[type], ...newAvailableOptionsWithSelf[type]])
return newAvailableOptionsWithSelf
})
setAvailableOptions(newAvailableOptions)
}
此代码在监视 selectedOptions 更改的钩子上运行。此代码与 filterAvailableOptions 函数一起确定将禁用哪些选项。这里使用的数据结构是以变体名称为键的对象（例如“颜色”和“大小”）和 javascript 集（Set），类似于数组，但值是唯一的，值在 Set 中不能重复。
可用选项由所有可用的 sku 构造而成，并使用以下值进行初始化：
{
'color': new Set('RED', 'BLUE', 'GREEN'),
'size': new Set('S', 'M')
}
另一种更可行的方法是也使用变体 id 作为键而不是变体类型。
{
1: new Set('RED', 'BLUE', 'GREEN'),
2: new Set('S', 'M')
}
这样，代码就不会受到可能显示相同类型的变体的限制。例如，也许可以有两种颜色选择。
除了现有的 sku 之外，您可能还想对用户可以选择的所有可能选项进行库存检查，这样用户可以一眼看出某个选项是否可用。为此，您可以找到迄今为止与当前选择匹配的所有 sku。
如果用户已经选择了红色，则查找所有包含红色的 sku，并对所有与红色匹配的 sku 进行库存检查。这样您就可以判断下一个可能的选择选项是否可用。
但是，用户可能想要改变她/他的想法，而不是决定红色然后尺寸为 xs s/他可以选择红色，改变她/他的想法并更改为绿色。您的算法应该足够灵活，以便始终获取 sku。有时，当用户做出选择时，需要获取所有可用选项。例如，每当用户做出选择时，沃尔玛都会检查库存。
另一件事要记住是后端部分。有时即将到来的选择可能多达数百个。您的后端应该足够快速和准确，以处理如此数量的可能选择。一次快速的 GPT 聊天揭示了许多快速、准确的方法，其中许多方法包括使用事件驱动代码，在交易发生时更新库存。这很敏感，因为如果做得不正确，可能会不同步，请记住互斥并避免两个客户可能同时购买该商品的竞争条件。如果必须选择的话，我会选择 Kafka 的组合来处理事件，Redis 来缓存库存值。
就我个人而言，我不必选择其中任何一个，只需优化后端查询以确保它每 2 秒运行 20 个 sku。当用户做出选择时，我会缩小 sku 的范围，因此用户做出的选择越多，我需要检查库存的 sku 就越少，并且 api 调用的速度也越快。
无论如何，我仍然需要弄清楚是否应该获取所有 sku 匹配项或剩余等待选择的 sku。所有匹配的 sku 是与当前选择匹配的所有 sku，剩余的 sku 是用户未选择的 sku。
在电子商务中，提供高性能的代码非常重要，因为有些人依靠该服务从购买体验（有时从他们购买的商品）中获得情感安慰。使用写得不好的应用程序可能会导致情感需求得不到满足，从而毁掉某人的一天，进而导致决策能力不佳。
sku 检查只能在产品显示页面加载开始时进行，但库存检查可以在用户做出选择时进行。因此，本质上只需一次获取 sku，并多次获取库存检查。
很可能有多种方法可以实现此结果。这种方式几乎是瞬时的。同一产品只有这么多不同的变体，因此不需要进一步优化。我保留了部分代码，以免给我目前工作的公司带来麻烦，但我很乐意讨论您的预期方法。
长话短说，获取所有 sku（应该随着用户选择的变化而变化），并通过查看不同的 sku 选项来构建可用的选项选择元素。
以上是根据可用产品 SKU 确定可用选择的详细内容。更多信息请关注PHP中文网其他相关文章！
