사용 가능한 제품 SKU에 따라 사용 가능한 선택 사항 결정

과거에 전자상거래 애플리케이션에서 일했거나 일한 적이 있다면 아마도 제품 표시 페이지를 처리해야 하는 상황에 직면했을 것입니다. 이는 사용자가 장바구니에 제품을 추가할지 여부를 결정하기 전에 표시되는 페이지입니다. 다른 페이지와 마찬가지로 이 페이지도 빠르게 로드되어야 하며 설명, 사진, 사용 가능한 옵션 등 제품에 대한 중요한 정보를 표시해야 합니다.

사용 가능한 옵션은 제품의 다양한 변형입니다. 예를 들어, 남성용 셔츠는 일반적으로 다양한 사이즈로 제공되지만 때로는 매장에 지정된 사이즈가 부족할 수도 있습니다. 이와 같은 상황에서는 해당 제품에 해당 변형을 사용할 수 없다는 것을 사용자가 미리 알 수 있도록 선택을 비활성화하는 것이 좋습니다.

이 문제에 접근하는 두 가지 방법 중 하나는 현재 선택 사항으로 백엔드에 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 목록을 반환합니다.

첫 번째 접근 방식은 실행 가능하지만 최신 웹 개발 표준에 적합하지 않은 선택 항목 사이에 로드 상태를 가져야 한다는 것입니다. 두 번째 접근 방식은 더 빠르고 사실상 즉각적으로 실행되므로 상태를 로드할 필요가 없습니다. 첫 번째 접근 방식은 무거운 작업을 백엔드에 위임하고 두 번째 접근 방식은 모든 무거운 작업을 프런트엔드에서 수행하지만 데이터베이스 통신이 필요하지 않기 때문에 프런트엔드가 훨씬 빠르게 실행됩니다.

이번 포스팅에서는 두 번째 접근 방식에 집중하겠습니다.

  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 함수와 함께 이 코드는 비활성화할 옵션을 결정합니다. 여기에 사용된 데이터 구조는 변형 이름을 키(예: '색상' 및 '크기')로 갖는 객체와 자바스크립트 세트(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를 가져올 수 있을 만큼 유연해야 합니다. 사용자가 선택할 때 사용 가능한 모든 옵션을 가져와야 하는 경우도 있습니다. 예를 들어 Walmart는 사용자가 선택할 때마다 재고를 확인합니다.

또 한 가지 염두에 두어야 할 점은 백엔드 부분입니다. 때로는 다가오는 선택 항목이 수백 개에 달할 수도 있습니다. 백엔드는 이러한 가능한 선택 사항을 처리할 수 있을 만큼 빠르고 정확해야 합니다. 빠른 GPT 채팅을 통해 이를 빠르고 정확하게 수행할 수 있는 여러 가지 방법이 밝혀졌으며, 그 중 다수는 거래가 발생할 때마다 인벤토리를 업데이트하는 이벤트 중심 코드를 사용하는 것으로 구성되었습니다. 이는 올바르게 수행되지 않으면 동기화되지 않을 수 있으므로 민감합니다. 뮤텍스를 기억하고 두 고객이 동시에 항목을 구매할 수 있는 경쟁 조건을 피하십시오. 굳이 선택해야 한다면 이벤트용 Kafka와 인벤토리 값 캐싱용 Redis의 조합을 선택하겠습니다.

개인적인 경우에는 둘 중 하나를 선택할 필요가 없었고 백엔드 쿼리를 최적화하여 2초당 20 SKU가 실행되도록 하기만 하면 되었습니다. 사용자가 선택함에 따라 SKU 범위를 좁히므로 사용자가 더 많은 선택을 할수록 인벤토리를 확인해야 하는 SKU가 줄어들고 API 호출이 더 빨라집니다.

어쨌든 모든 SKU 일치 항목을 가져와야 하는지 아니면 선택 대기 중인 나머지 SKU를 가져와야 하는지 알아내야 합니다. 일치하는 모든 SKU는 현재 선택과 일치하는 모든 SKU이고 나머지 SKU는 사용자가 선택할 수 없는 SKU입니다.

전자상거래에서는 성능이 뛰어난 코드를 전달하는 것이 매우 중요합니다. 일부 사람들은 구매 경험에서, 때로는 구매하는 품목에서 정서적 위안을 받기 위해 서비스에 의존하기 때문입니다. 제대로 작성되지 않은 앱을 사용하면 정서적 욕구가 충족되지 않아 누군가의 하루를 망칠 수 있으며, 결과적으로 의사결정 능력이 저하될 수 있습니다.

SKU 확인은 제품 표시 페이지 로드 시작 시에만 수행할 수 있지만 재고 확인은 사용자가 선택하면서 수행할 수 있습니다. 따라서 본질적으로 SKU에 대해서는 한 번만 가져오고 재고 확인에는 여러 번 가져옵니다.

결론

이 결과를 얻는 방법에는 여러 가지가 있을 수 있습니다. 이 방법은 사실상 즉각적입니다. 동일한 제품에는 너무 많은 변형이 있으므로 더 이상 최적화할 필요가 없습니다. 현재 제가 일하고 있는 회사에 문제가 생기지 않도록 코드의 일부를 비밀로 유지했지만 귀하가 의도한 접근 방식에 대해 기꺼이 논의하겠습니다.

긴 이야기에서는 모든 SKU(사용자 선택 변경에 따라 변경되어야 함)를 가져오고 다양한 SKU 옵션을 확인하여 사용 가능한 옵션 선택 요소를 구축합니다.

위 내용은 사용 가능한 제품 SKU에 따라 사용 가능한 선택 사항 결정의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!