‫Instructeur : Dans
‫cette vidéo, nous allons implémenter la page mes réservations.
‫Donc, en gros, nous allons créer une
‫belle page contenant toutes les visites qu'un utilisateur a réservées.
‫Et commençons par ajouter une nouvelle route à nos viewRoutes.
‫D'accord, nous avons donc moi et créons
‫ensuite les my-tours.
‫Je duplique donc celui-ci, my-tours, alors aussi cet itinéraire doit être
‫protégé afin que seuls les
‫utilisateurs actuellement connectés
‫puissent accéder à cette page, bien sûr.
‫Et puis, dans notre
‫viewsController, nous aurons un contrôleur appelé getMyTours.
‫MyTours comme ça, d'accord ?
‫Et c'est en fait tout pour
‫l'instant, alors allons-y et créons ce contrôleur maintenant.
‫D'accord, nous avons donc tout cela ici,
‫obtenez une visite, obtenez un formulaire de connexion, obtenez un compte.
‫Mettons donc celui-ci ici aussi.
‫Et maintenant, ce que nous devons
‫faire ici, c'est trouver toutes les visites que l'utilisateur a réservées.
‫Donc, en gros, nous devons d'abord trouver toutes les réservations
‫pour les utilisateurs actuellement connectés, ce
‫qui nous donnera ensuite un tas d'identifiants de
‫tournée, puis nous devons trouver les tournées avec ces identifiants.
‫Donc, en gros, recherchez toutes les réservations, puis
‫recherchez les visites avec les identifiants renvoyés.
‫Donc, en gros, les identifiants des réservations pour l'utilisateur, n'est-ce pas ?
‫Maintenant, à la place, nous pourrions
‫également faire une population virtuelle sur les visites, et
‫ce serait formidable si vous mettiez
‫cela en œuvre vous-même exactement comme nous l'avons fait auparavant avec les visites
‫et les critiques, mais ici, dans cette
‫fonction, je voulais en fait pour vous montrer comment
‫nous pouvons le faire
‫manuellement, car je pense que c'est aussi assez important
‫et qu'en fait, une population virtuelle
‫devrait fonctionner de manière similaire à ce que nous allons faire ici.
‫Et donc vous voyez qu'en fait nous avons besoin
‫de deux requêtes pour vraiment
‫trouver les circuits correspondant aux réservations de l'utilisateur.
‫Quoi qu'il en soit, commençons maintenant,
‫créons donc une variable pour toutes les réservations,
‫attendez et maintenant je pense que nous n'avons pas encore les réservations ici, non.
‫Donc Réservations ici, et bookingModel.
‫Et ici, bien sûr, c'est juste la réservation, d'accord.
‫Attendez donc Booking. trouvez, et rappelez-vous maintenant que
‫chaque document de réservation a un identifiant d'utilisateur, n'est-ce pas ?
‫Donc ici, dans le schéma, rappelez-vous
‫que nous avons l'ID de la tournée,
‫l'ID utilisateur, puis toutes ces autres données,
‫et donc ce que
‫nous allons faire maintenant, c'est interroger essentiellement par l'ID utilisateur, d'accord ?
‫Et donc cela nous
‫rendra toutes les visites qui appartiennent à l'utilisateur actuel, d'accord ?
‫Donc pas celui-ci.
‫Donc, la tournée devrait être égale à req. utilisateur. identifiant.
‫Alors ici async, et comme toujours, catchAsync aussi.
‫Ainsi, ces réservations contiennent désormais tous les documents
‫de réservation pour l'utilisateur actuel, mais en
‫réalité, cela ne nous donne que les identifiants de tournée.
‫Et maintenant, nous voulons trouver les visites avec les identifiants retournés.
‫Et donc, la prochaine étape consiste
‫essentiellement à créer un tableau de tous
‫les identifiants, puis après cette requête pour
‫les visites qui ont l'un de ces identifiants, d'accord ?
‫Et cela aura un peu plus de sens une
‫fois que nous aurons réellement mis en œuvre ce que je viens d'expliquer.
‫Donc tourIDs est égal aux réservations et maintenant nous allons utiliser
‫une carte pour créer un
‫nouveau tableau basé sur une fonction de rappel
‫qui est celle-ci, donc
‫le el actuel. tour. identifiant.
‫Alors, qu'est-ce que cela va faire?
‫Eh bien, en gros, cela parcourt tout le tableau des réservations et
‫sur chaque élément, il saisira le el. tour.
‫Et en fait, nous n'avons même pas besoin de
‫l'ID ici parce que la tournée elle-même est déjà l'ID de la tournée, n'est-ce pas ?
‫Au final, nous avons un joli tableau avec
‫tous les identifiants de tournée ici et c'est parce que
‫nous avons utilisé une carte.
‫D'accord, alors en ayant tous les identifiants de
‫tournée, nous pouvons en fait obtenir les tournées correspondant à ces identifiants.
‫Attendez donc Tour. find et nous voulons réellement rechercher par ID, mais nous ne pouvons
‫pas utiliser le fichier . findbyid car ici,
‫nous aurons en fait besoin d'un nouvel opérateur.
‫Et cet opérateur, que je
‫ne sais pas si nous avons déjà utilisé
‫auparavant, est appelé.
‫Donc, dans tourIDs.
‫Donc, en gros, ce que
‫cela va faire à la place, il
‫sélectionnera toutes les visites qui ont un ID qui se trouve dans le tableau tourIDs, d'accord ?
‫C'est donc assez simple,
‫mais c'est très bien de savoir
‫que nous pouvons utiliser cet opérateur très pratique ici, d'accord ?
‫Et c'est en fait l'une des raisons pour
‫lesquelles je voulais le faire manuellement
‫au lieu de simplement faire une population virtuelle comme nous le faisions auparavant.
‫Mais encore une fois, ce serait bien si vous
‫pouviez aller de l'avant et implémenter
‫cela aussi juste pour le plaisir, vous savez.
‫D'accord, et avec cela,
‫nos tournées sont prêtes à être rendues.
‫Donc, rés. statut comme
‫toujours, puis les rendre, d'accord ?
‫Et en fait, nous n'avons même pas besoin d'un nouveau modèle pour cela.
‫Nous allons simplement réutiliser l'aperçu, d'accord ?
‫Nous allons donc nous
‫retrouver avec une page qui ressemble beaucoup
‫à l'aperçu, mais uniquement avec les visites que l'utilisateur a réservées.
‫Donc, ici et pour avoir une vue
‫d'ensemble, nous avons ensuite fait toutes les tournées, d'accord ?
‫Donc en gros tous.
‫Et donc maintenant, nous allons avoir quelque chose de
‫très similaire mais bien sûr ne passant que dans les visites réservées.
‫Alors, c'est où ?
‫D'accord, donc le titre sera My Tours, et encore
‫une fois en passant la variable tours.
‫D'accord et ça devrait être ça.
‫Maintenant, bien sûr, nous aurions également pu
‫créer une toute nouvelle carte pour ces librairies
‫avec des informations plus
‫pertinentes sur chacune des réservations,
‫mais dans ce cas, ce n'est pas vraiment important.
‫Maintenant, n'est-ce pas ?
‫Donc, nous sommes en fait prêts
‫à tester cela car nous avons déjà implémenté la route ici auparavant.
‫Et c'est donc mes tournées.
‫Oh, mais en fait, définissons ce lien ici, directement
‫sur la page du compte utilisateur.
‫Donc, ce my-tours devrait bien sûr
‫avoir son propre lien ici même dans le compte.
‫Donc dans cette
‫colonne de gauche, c'est donc ici dans Mes réservations,
‫donc nous avons ce premier
‫ici qui est pour le lien, souvenez-vous.
‫Et donc en ce moment, pratiquement tous ne pointent nulle part, mais maintenant pour
‫les réservations, nous avons en fait un lien.
‫Et c'est donc mes-tours.
‫Et nous aurions pu appeler cela des réservations aussi, mais
‫ce n'est pas vraiment important de toute façon.
‫Donc, maintenant nous sommes prêts à tester cela.
‫Déconnectons-nous en fait de cet utilisateur,
‫puis connectons-nous en tant que notre autre utilisateur, Laura.
‫Très bien, et voyons ce que nous obtenons ici et cela
‫prend beaucoup trop de temps,
‫alors jetons un coup d'œil à notre code, éditons notre terminal ici.
‫D'accord, il n'y a donc pas d'erreur ici, mais il
‫semble également que rien ne se passe vraiment ici.
‫Donc l'itinéraire my-tours ici n'apparaît même pas, d'accord.
‫Maintenant, pour trouver ce
‫bogue, j'ai dû faire du débogage en dehors
‫de cette vidéo car c'était vraiment difficile à trouver, d'accord.
‫Tout d'abord, il y a une petite erreur ici.
‫Donc, ceci ici devrait en fait être utilisateur et non tour.
‫Je l'ai donc expliqué correctement à
‫l'époque, où j'ai dit que nous devions filtrer par
‫utilisateur, donc des visites où l'utilisateur est
‫égal à l'utilisateur issu de la demande, mais
‫pour une raison quelconque, je me suis trompé ici, d'accord ?
‫Mais ce n'est pas le bug principal en fait.
‫Donc pas celui qui empêche la page de se charger réellement.
‫L'erreur qui provoque cela se
‫trouve ici en fait dans le modèle de réservation.
‫Et c'est ici dans ce middleware de pré-recherche.
‫Et le problème est
‫que nous n'appelons jamais le prochain middleware ici, n'est-ce pas ?
‫Encore une fois, il s'agit d'un pré-middleware.
‫Et tous les pré-middlewares ont accès à
‫la fonction suivante et donc, à
‫la fin de ces middlewares, nous
‫devons toujours appeler next.
‫Sinon, notre processus se bloque vraiment, d'accord ?
‫Alors, faites une sauvegarde, cela peut en fait fermer celui-ci.
‫Et maintenant, essayons à nouveau et
‫maintenant nous avons effectivement mes visites, mais
‫elles sont vides car cet utilisateur n'a jamais vraiment fait de réservation.
‫Alors, essayons cela maintenant et
‫réservons le randonneur forestier.
‫Cela devrait donc toujours fonctionner,
‫et en effet, c'est très bien.
‫Nous avons l'adresse e-mail pré-formatée et
‫maintenant, comme toujours 4242.
‫Nous avons donc fait la réservation auparavant avec cet utilisateur,
‫mais avant de mettre en œuvre le modèle de
‫réservation, nous n'avons donc jamais
‫vraiment créé de réservation dans notre système.
‫Très bien, donc paiement
‫accepté et maintenant voyons et c'est parti, super !
‫Donc, cette logique que nous venons d'implémenter a réellement
‫fonctionné et le seul problème
‫était qu'il manquait ensuite dans le middleware.
‫Et juste comme ça, nous avons terminé une autre
‫page de notre site Web dynamique.
‫Et donc ensuite, tout ce qu'il reste à faire à ce stade
‫est de terminer l'API de réservation.