利用可能な製品 SKU に応じて利用可能な選択肢を決定する

電子商取引アプリケーションで働いているか、過去に働いていたことがある場合は、おそらく製品表示ページを処理しなければならないことに遭遇したことがあるでしょう。これは、ユーザーが商品をカートに追加するかどうかを決定する前に表示されるページです。他のページと同様に、このページも高速に読み込まれる必要があり、説明、写真、利用可能なオプションなどの製品に関する重要な情報も表示する必要があります。

利用可能なオプションは、製品の利用可能なさまざまなバリエーションです。たとえば、男性用のシャツには通常、さまざまなサイズがありますが、場合によっては、店舗で指定されたサイズが在庫切れになることがあります。このような状況では、この特定の製品ではこのバリエーションが利用できないことをユーザーが事前に認識できるように、選択を無効にすることが有益です。

これにアプローチする 2 つの方法のうちの 1 つは、現在の選択を使用してバックエンドへの API 呼び出しを行い、これらの選択に基づいてどのオプションが使用可能かを判断することです。たとえば、緑色を選択した場合、その特定の色で利用可能なサイズのみが表示されます。サイズ媒体が緑色で利用できない場合は、事前に緑色が選択されている限り、媒体を選択するオプションを無効にする必要があります。この最初のアプローチでは、現在選択されているオプションに基づいて、残りの利用可能なオプションがどれであるかを判断するためにデータベースが照会されます。これにより、データベースに対して ProductSkus、ProductSkuOptions、ConfigurableOptions をクエリするとともに、これらのテーブルに対する 10 個の異なるクエリを実行します。これは、ユーザーが選択したすべての項目に対して実行されます。

2 番目の方法は、バックエンドが利用可能なバリエーションのリストを 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 開発標準には理想的ではありません。 2 番目のアプローチはより高速で、事実上瞬時に実行され、状態をロードする必要がありません。最初のアプローチは重い作業をバックエンドに委任し、2 番目のアプローチはすべての重い作業をフロントエンドで実行しますが、データベース通信の必要がないため、フロントエンドははるかに高速に実行されます。

この投稿では 2 番目のアプローチに焦点を当てます。

  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 関数は、どのオプションを無効にするかを決定します。ここで使用されるデータ構造は、キーとしてバリアント名 (例: 「color」や「size」) を持つオブジェクトと JavaScript セット (Set) です。配列に似ていますが、値は一意であり、値は Set 内で繰り返すことができません。

利用可能なオプションは、利用可能なすべての SKU から構築され、次の値で初期化されます。

{
 'color': new Set('RED', 'BLUE', 'GREEN'),
 'size': new Set('S', 'M')
}

もう 1 つのより実現可能なアプローチは、バリアント タイプの代わりにバリアント ID をキーとして使用することです。

{
  1: new Set('RED', 'BLUE', 'GREEN'),
  2: new Set('S', 'M')
}

この方法では、コードは同じ型を表示する可能性のあるバリアントを持つという制約を受けません。たとえば、2 つの色の選択がある可能性があります。

在庫

既存の SKU に加えて、ユーザーが選択できるすべてのオプションの在庫チェックを実行することもできます。これにより、ユーザーはオプションが利用可能かどうかを一目で知ることができます。このため、これまでの現在の選択に一致するすべての SKU を見つけることができます。

ユーザーがすでに赤色を選択している場合は、赤色を含むすべての SKU を探し、赤色に一致するすべての SKU の在庫チェックを実行します。こうすることで、次に選択可能なオプションが利用可能かどうかを知ることができます。

ただし、ユーザーは気が変わり、色を赤にしてからサイズ xs を決める代わりに、赤を選択し、気が変わって緑に変更することもできます。アルゴリズムは、常に SKU をフェッチできるように十分に柔軟である必要があります。場合によっては、ユーザーが選択するときに利用可能なすべてのオプションを取得することが必要になることがあります。たとえば、ウォルマートはユーザーが商品を選択するたびに在庫チェックを行います。

もう 1 つ留意すべき点は、このバックエンド部分です。場合によっては、今後の選択が数百にも及ぶ可能性があります。バックエンドは、このような量の可能な選択を処理できるほど高速かつ正確である必要があります。簡単な GPT チャットにより、これを高速かつ正確に行うための多くの方法が明らかになりました。その多くは、トランザクションが発生するたびに在庫を更新するイベント駆動型コードを使用することで構成されていました。これは正しく行わないと同期が失われる可能性があるため、慎重に行う必要があります。ミューテックスを覚えておいて、2 人の顧客が同時に商品を購入する可能性がある競合状態を避けてください。選択しなければならないとしたら、イベントには Kafka を、在庫値のキャッシュには Redis を組み合わせて選択します。

私の個人的なケースでは、どちらかを選択する必要はなく、バックエンド クエリを最適化して 2 秒あたり 20 skus が確実に実行されるようにするだけで済みました。ユーザーが選択するにつれて SKU を絞り込みます。そのため、ユーザーが選択した数が多いほど、在庫をチェックする必要がある SKU が減り、API 呼び出しが速くなります。

とにかく、一致するすべての SKU を取得する必要があるのか​​、それとも選択を待っている残りの SKU を取得する必要があるのか​​を判断する必要があります。すべての一致する sku は、現在の選択に一致するすべての sku であり、残りの sku は、ユーザーが選択できないものです。

e コマースでは、パフォーマンスの高いコードを提供することが非常に重要です。購入体験や、場合によっては購入する商品から精神的な安らぎを得るためにサービスに依存している人もいるからです。不適切に作成されたアプリを使用すると、感情的なニーズが満たされず、その結果、意思決定スキルが低下する可能性があり、誰かの一日を台無しにする可能性があります。

SKU チェックは製品表示ページの読み込みの開始時にのみ実行できますが、在庫チェックはユーザーが選択するときに実行できます。つまり、本質的には、Skus のフェッチは 1 回だけで、在庫チェックのフェッチは複数回になります。

結論

この結果を達成するには、おそらく複数の方法があります。この方法は事実上瞬時に行われます。同じ製品には非常に多くのバリエーションがあるため、さらに最適化する必要はありません。現在働いている会社とトラブルにならないようにコードの一部を秘密にしましたが、あなたの意図するアプローチについて喜んで議論させていただきます。

簡単に言えば、すべての SKU を取得し (ユーザーの選択が変わると変更されるはずです)、さまざまな SKU オプションを確認して、利用可能なオプション選択要素を構築します。

以上が利用可能な製品 SKU に応じて利用可能な選択肢を決定するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。