Déterminer les sélections disponibles en fonction des SKU de produits disponibles

Si vous travaillez ou avez travaillé dans une application de commerce électronique dans le passé, vous avez probablement dû gérer la page de présentation du produit. Il s'agit de la page que l'utilisateur voit avant de décider d'ajouter ou non un produit au panier. Comme toute autre page, cette page doit se charger rapidement et doit également afficher des informations cruciales sur le produit telles que la description, les images et les options disponibles.

Les options disponibles sont les différentes variantes disponibles d'un produit. Par exemple, une chemise pour homme est généralement disponible en différentes tailles, mais il arrive parfois que le magasin manque d'une taille donnée. Pour des situations comme celle-ci, il est avantageux de désactiver la sélection afin que l'utilisateur sache à l'avance que cette variation n'est pas disponible pour ce produit donné.

L'une des deux façons d'aborder ce problème consiste à effectuer un appel API au backend avec les sélections actuelles pour déterminer quelles options sont disponibles en fonction de ces sélections. Par exemple, si je sélectionne la couleur verte, je ne devrais voir que les tailles disponibles pour cette couleur spécifique. Si la taille moyenne n'est pas disponible en vert, l'option permettant de sélectionner la taille moyenne doit être désactivée tant que le vert est préalablement sélectionné. Avec cette première approche, la base de données serait interrogée pour déterminer quelles sont les autres options disponibles en fonction des options actuellement sélectionnées. Cela interrogerait la base de données pour ProductSkus, ProductSkuOptions et ConfigurableOptions ainsi que 10 requêtes différentes sur ces tables. Cela serait fait pour chaque sélection d'utilisateur effectuée.

La deuxième méthode consiste pour le backend à renvoyer une liste des variantes disponibles sous forme de SKU ("ZARA-001-RED-S", "ZARA-001-BLUE-S", "ZARA-001-GREEN- S', ​​'ZARA-001-ROUGE-M', 'ZARA-001-BLEU-M'). Cette liste de SKU peut faire partie de l'appel de l'API des détails du produit et ajouterait une seule requête de base de données qui est ProductSkus.where (product_id :). Cette requête (ruby on rails) renvoie la liste des références liées à un produit.

La première approche implique de devoir avoir un état de chargement entre les sélections, ce qui est faisable mais pas idéal pour les normes de développement Web modernes. La deuxième approche est plus rapide et s’exécute pratiquement instantanément, sans nécessiter de chargement d’états. La première approche délègue le gros travail au backend tandis que la seconde approche effectue tout le gros travail dans le frontend, cependant le frontend s'exécutera beaucoup plus rapidement puisqu'il n'y a pas besoin de communication avec la base de données.

Je me concentrerai sur la deuxième approche pour cet article.

  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)
  }

Ce code s'exécute sur un hook qui surveille les modifications des options sélectionnées. Ce code ainsi que la fonction filterAvailableOptions déterminent quelles options seront désactivées. Les structures de données utilisées ici sont des objets avec des noms de variantes comme clé (par exemple, « couleur » et « taille ») et des ensembles javascript (Set), similaires aux tableaux mais les valeurs sont uniques, les valeurs ne peuvent pas se répéter dans un ensemble.

Les options disponibles sont construites à partir de tous les références disponibles et s'initialisent avec les valeurs :

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

Une autre approche plus réalisable consiste à utiliser également l'identifiant de variante comme clé au lieu du type de variante.

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

De cette façon le code n'est pas contraint d'avoir une variante pouvant afficher le même type. Peut-être qu'il peut y avoir deux sélections de couleurs par exemple.

Inventaire

En plus du SKU existant, vous souhaiterez peut-être également faire une vérification des stocks de toutes les options possibles que l'utilisateur peut sélectionner, de cette façon, l'utilisateur peut savoir en un coup d'œil si une option est disponible ou non. Pour cela vous pouvez retrouver tous les skus qui correspondent à la sélection actuelle jusqu'à présent.

Si l'utilisateur a déjà choisi la couleur rouge, recherchez tous les références qui contiennent la couleur rouge et effectuez une vérification des stocks de toutes les références qui correspondent à la couleur rouge. De cette façon, vous pourrez savoir si la prochaine option choisie possible est disponible ou non.

Cependant, l'utilisateur peut vouloir changer d'avis et au lieu de choisir la couleur rouge puis la taille xs, il peut choisir la couleur rouge, changer d'avis et passer à la couleur verte. Votre algorithme doit être suffisamment flexible pour récupérer toujours le SKU. Parfois, il serait nécessaire de récupérer toutes les options disponibles au fur et à mesure que l'utilisateur effectue sa sélection. Walmart, par exemple, effectue une vérification des stocks chaque fois que l'utilisateur effectue une sélection.

Une autre chose à garder à l’esprit est la partie backend de ceci. Parfois, les sélections à venir peuvent atteindre des centaines. Votre backend doit être suffisamment rapide et précis pour gérer un tel nombre de sélections possibles. Une discussion rapide sur GPT a révélé de nombreuses façons de rendre cela rapide et précis, dont beaucoup consistaient à utiliser un code événementiel qui met à jour l'inventaire chaque fois qu'une transaction a lieu. Ceci est sensible car il peut être désynchronisé s'il n'est pas effectué correctement, n'oubliez pas le mutex et évitez les conditions de concurrence où deux clients peuvent acheter l'article en même temps. Si je devais choisir, je choisirais une combinaison de Kafka pour les événements et de Redis pour la mise en cache des valeurs d'inventaire.

Dans mon cas personnel, je n'ai eu à choisir ni l'un ni l'autre, j'ai seulement dû optimiser une requête backend pour m'assurer qu'elle exécutait 20 skus toutes les 2 secondes. J'affine les références au fur et à mesure que l'utilisateur effectue des sélections, donc plus l'utilisateur a effectué de sélections, moins je dois vérifier l'inventaire de références et plus l'appel API est rapide.

Quoi qu'il en soit, je dois encore déterminer si je dois récupérer tous les SKU correspondants ou les SKU restants en attente d'être sélectionnés. Tous les références correspondantes sont tous les références qui correspondent à la sélection actuelle et les références restantes sont celles qui manquent pour être sélectionnées par l'utilisateur.

Dans le commerce électronique, il est très important de fournir un code performant, car certaines personnes comptent sur le service pour bénéficier du confort émotionnel de l'expérience d'achat et parfois de l'article qu'elles achètent. L'utilisation d'une application mal écrite peut gâcher la journée de quelqu'un en empêchant la satisfaction d'un besoin émotionnel, ce qui peut entraîner de mauvaises capacités de prise de décision.

La vérification du SKU ne peut être effectuée qu'au début du chargement de la page d'exposition du produit, mais la vérification des stocks peut être effectuée au fur et à mesure que l'utilisateur effectue des sélections. Donc, en substance, une seule récupération pour les skus et plusieurs récupérations pour les contrôles de stock.

Conclusion

Il existe probablement plusieurs façons d’obtenir ce résultat. Cette méthode est pratiquement instantanée. Il n’existe qu’un nombre limité de variantes différentes du même produit, il ne devrait donc pas être nécessaire de l’optimiser davantage. J'ai gardé une partie du code pour moi pour ne pas avoir de problèmes avec l'entreprise pour laquelle je travaille actuellement, mais je serais heureux de discuter de votre approche envisagée.

Pour faire court, récupérez tous les sku (qui devraient changer à mesure que la sélection de l'utilisateur change) et créez les éléments de sélection d'options disponibles en examinant les différentes options de sku.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!