R3.01 - dev. web - côté client (vuejs)

   TP n°4 : DrMad - une boutique

Imprimer
Détails
Catégorie : R3.01 - dev. Web côté client (vuejs)
Affichages : 1009

Préambule

L'objectif principal de ce TP est d'implémenter une pseudo boutique en ligne, afin de mettre en oeuvre de façon plus poussée les principes de vuex et de vue-router.  Le scénario à implémenter est le suivant :

NB : pour simplifier l'exercice et notamment la gestion du panier, on part du principe que des boutons ne vont apparaître que si l'utilisateur est authentifié via la page de login.

 

 

 

 

 

0°/ Mise en place

La structuration générale reste la même que pour les TPs précédents. De plus, certains composants vont être réutilisés. La mise en place initiale la plus simple consiste donc à :

En revanche, pour suivre et tester ces les scénarios proposés, le fichier source de données utilisés dans les TPs précédents (c.a.d. datasource/data.js) a été modifié. Vous devez télécharger la nouvelle version [ ici ] et l'utiliser pour ce TP.

 

1°/ Modularisation du store

Comme l'application DrMad aura à terme des fonctionnalités bien séparées, il est important de modulariser le store. Pour cela :

Pour les exercices suivants, il va falloir modifier le module shop afin d'implémenter les fonctionnalités demandées.

 

2°/ Le composant racine de la boutique

<template>
  <div>
    <h1>Boutique</h1>
    <router-view name="shopmain"></router-view>
  </div>
</template>

 

3°/ L'accueil

 

4°/ Acheter des items

L'objectif est de permettre de sélectionner des virus et de les ajouter à un "panier d'achat", en plus ou moins grand nombre. (NB : cela impose de modifier les composant CheckedList.vue créé dans le TP précédent.)

4.1°/ Le composant racine des achats

4.2°/ Les items à acheter

 

 

{
  name: {type: String, required: true},
  login: {type: String, required: true},
  email: {type: String, required: true},
  session: {type: String}, 
  basket: BasketSchema,
}
{
  items: [{  
    item: {type: Schema.Types.ObjectId, required: true, ref: 'Item'},
    amount: {type: Number, required: true, min:0}, 
  }]
}
  • La solution à suivre est donc d'ajouter des mutations/actions dans le store permettant de mettre à jour directement l'objet basket de l'utilisateur courant (avec la structure ci-dessus), plutôt que d'ajouter une variable dans le state.
  • NB : normalement, à chaque modification du panier, celles-ci doivent être enregistrée dans la BdD. Dans le cas présent, on ne peut pas modifier le fichier source de données. On se contentera donc de créer une action appelant un service qui simule la requête de mise à jour mais qui se contente d'afficher les informations à envoyer (c.a.d. l'id de l'utilisateur + l'objet basket)

 

4.3°/ Le panier

  • Dans le répertoire components, créer un composant BasketList.vue.
  • Ce composant doit utiliser la version modifié de CheckedList.vue pour :
    • afficher chaque item du panier avec un bouton supprimer après,
    • afficher un bouton "vider le panier" après cette liste,
    • quand l'événement clic sur le bouton d'item est reçu, supprimer cet item du panier de l'utilisateur.
    • quand l'événement clic sur le bouton après la liste est reçu, supprimer le contenu du panier.
  • De plus, le composant doit afficher un bouton "Acheter" permettant de valider la commande. Quand on clique sur ce bouton, il faut normalement envoyer une requête à l'API (avec l'id utilisateur comme donnée) et recevoir en retour un objet représentant la commande. Dans la BdD cette commande est représentée par le schéma OrderSchema suivant  :
{
  items: [{    
    item: {
      name: {type: String, required: true},
      description: {type: String},
      price: {type: Number, required: true, min: 0}, 
      promotion: [{
        discount: {type: Number, required: true, min: 0}, 
        amount: {type: Number, required: true, min: 0}, 
      }],
      object: {type: String, required: true}
    },
    amount: {type: Number, required: true, min:0}, 
  }],
  date: {type: Date, default: Date.now},
  total: {type: Number, required: true, min:0}, 
  status: {type: String, require: true, enum: ['waiting_payment', 'finalized', 'cancelled']},
  uuid: {type: String, required: true }, // value MUST BE an unique uuid v4
}
  • Dans ce TP, la solution la plus simple consiste à créer une fonction de service qui va créer un objet avec cette structure à partir de ce qu'il y a stocké dans le panier.
  • Cette fonction est appelée par une action du store, qui stocke l'objet dans le champ orders de l'utilisateur courant (ce qui implique également de créer les mutations pour ce faire). En effet, dans la BdD, le schéma d'un utilisateur contient un champ orders contenant toutes ses commandes. Il est donc logique de suivre le même système plutôt que d'utiliser une nouvelle variable dans le state.

Problème : les fonctions de service utilisant le fichier source de données se trouvent dans controller.js, donc "hors" de vuejs. Il faut donc trouver un moyen d'accéder au store dans controller.js afin de pouvoir récupérer le panier courant.

 

5°/ Payer une commande

  • Dans le répertoire views, créer un composant ShopPay.vue.
  • Ce composant prend en props l'id d'une commande et affiche :
    • un champ texte pour saisir l'id d'une commande. Si la props mentionnée ci-dessus est définie, alors ce champ de saisie est initialisé avec la valeur de la props.
    • un bouton "Payer". Quand on clique sur celui-ci, on appelle une action du store qui va :
      • en premier lieu, vérifier si l'id de la commande correspond à une commande existante dans le champ orders de l'utilisateur courant, et dans ce cas, récupérer l'objet représentant la commande,
      • sinon, appeler une fonction de service de shop.service.js, qui vérifie que l'id de la commande correspond bien à une commande existante pour l'utilisateur courant, en cherchant dans le fichier de source de données, et dans ce cas, récupérer l'objet représentant la commande,
      • si l'id est invalide, l'action du store s'arrête et le composant doit afficher un dialogue d'erreur
      • sinon, on passe la commande à l'état "finalized", considérant qu'elle est effectivement payée.

NB : dans le TP suivant, la gestion d'un compte bancaire sera ajoutée, ce qui permettra de vérifier si le montant de la commande correspond effectivement à une transaction bancaire de paiement.

 

6°/ Authentification

Cette partie a déjà été implémentée dans les TPs précédents. Il suffit donc de reprendre le composant déjà écrit., et en faisant quelques modifications

La première concerne le fichier datasource/controller.js. En effet, dans la solution proposée, la fonction qui recherche un utilisateur dans le fichier source de données data.js se contente :

  • de vérifier le login mais pas le mot de passe : il faut également faire cette vérification.
  • de renvoyer TOUT l'objet utilisateur : il faut retourner uniquement les champs qui seraient renvoyés par l'API (cf. schéma mongoose en 4.2)

La deuxième consiste à afficher un dialogue d'erreur si le login/mot de passe n'est pas valide.

Enfin, si l’authentification est correcte, on doit suivre la route /shop/buy.

 

7°/ Commandes passées

  • Dans le répertoire views, créer un composant ShopOrders.vue.
  • Ce composant utilise CheckedList.vue pour afficher (sans case à cocher) la liste des commandes de l'utilisateur courant, donc se trouvant dans le champ orders (cf. ci-dessus)
  • Chaque élément de la liste affiche son montant, son état (c.a.d. champ status), et est suivi par des boutons "Payer" et "Annuler" si la commande est dans l'état "waiting_payment".
  • Quand on clique sur "Payer", on suit la route /shop/pay/:idcmd, en mettant comme valeur d'idcmd l'id de la commande que l'on veut payer.
  • Quand on clique sur "Annuler", la commande doit passer à l'état "cancelled".

Pour réaliser ces opérations, il faut écrire des action/mutation dans le store, notamment :

  • une action qui récupère les commandes passées de l'utilisateur courant, grâce à une fonction de service dans shop.service.js (à écrire), qui elle même fait appel à une fonction de datasource/controller.js (à écrire).
  • une mutation qui met à jour le champ orders de l'utilisateur courant avec une liste de commande,
  • une mutation qui met à jour l'état d'une commande de l'utilisateur courant.

Afin d'aller chercher une première fois les commandes passées, il est possible d'appeler l'action du store dans la fonction mounted() du composant.