如果您過去曾在電子商務應用程式中工作過，您可能會遇到必須處理產品顯示頁面的情況。這是用戶決定是否將產品添加到購物車之前看到的頁面。與任何其他頁面一樣，此頁面必須快速加載，並且還必須顯示有關產品的重要信息，例如描述、圖片和可用選項。
可用選項是產品的不同可用變體。例如，男士襯衫通常有不同尺碼，但有時商店可能會缺貨。對於這種情況，停用該選擇是有益的，以便使用者提前知道此變體不適用於該給定產品。
解決此問題的兩種方法之一是使用當前選擇對後端進行 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中文網其他相關文章！
