‫Conférencier : Et maintenant, pour terminer ce
‫projet, terminons cette intégration de Stripe avec des webhooks.
‫Commençons par nous rappeler comment notre
‫intégration Stripe fonctionne actuellement.
‫Nous avons ce point de terminaison de
‫session de paiement, qui est appelé depuis notre front-end.
‫Cela appellera ensuite la fonction getCheckoutSession, donc
‫essentiellement celle-ci ici,
‫qui créera une session de paiement sur le
‫serveur en utilisant toutes ces informations
‫ici, puis la renverra au client.
‫Puis une fois que le traitement du
‫paiement est effectué avec succès par
‫Stripe, redirigez ensuite l'utilisateur vers cette URL de réussite, donc celle-ci
‫que nous avons créée.
‫N'oubliez pas que sur cette URL, nous avons ajouté l'identifiant de la
‫tournée, l'identifiant de l'utilisateur et également le prix.
‫Nous avons fait cela pour qu'une fois cette URL ici appelée, notre
‫application crée un nouveau document de réservation dans
‫notre base de données.
‫Comment cela a-t-il fonctionné ?
‫Dans l'itinéraire my-tours, nous avons un middleware pour cela.
‫Rappelez-vous, ici dans viewRoutes, dans my-tours, nous
‫avons ce createBookingCheckout.
‫Cette fonction ici, qui, à partir de la requête, prend essentiellement le
‫tour, l'utilisateur et le prix, et crée une
‫entrée dans la base de données à l'aide de ces données.
‫Fondamentalement, nous mettons ces données sur l'URL
‫chaque fois que Stripe traite avec succès un paiement.
‫Et puis cette fonction middleware que nous avons
‫ici récupère les données et crée une nouvelle réservation dans notre système
‫en utilisant ces données.
‫Et puis après cela, nous redirigeons essentiellement
‫ici sur l'URL d'origine sans la chaîne de requête.
‫Le problème, c'est que ce n'est pas vraiment sécurisé.
‫Ainsi, tous ceux qui connaissent cette structure
‫d'URL, donc celle-ci ici, quel tour, utilisateur et prix dans
‫la chaîne de requête, peuvent créer une réservation dans
‫notre système sans réellement payer.
‫Donc, tout ce que nous avons à faire est
‫d'ouvrir cette URL
‫avec des données, puis de créer automatiquement une réservation
‫sans passer par le processus Stripe.
‫Rappelez-vous comment à l'époque j'ai dit que nous allions résoudre ce
‫problème en utilisant quelque chose appelé webhooks.
‫Donc, nous le faisons maintenant.
‫Car pour cela,
‫nous avons en fait besoin que notre site web soit déployé.
‫Maintenant, à ce stade, c'est effectivement le cas.
‫Et donc, maintenant nous pouvons implémenter ces webhooks.
‫Pour cela, direction notre tableau de bord Stripe.
‫Et en fait, je l'ai déjà ouvert ici.
‫Et puis allez ici aux développeurs, puis choisissez des webhooks, et
‫ici, ajoutez un nouveau point de terminaison.
‫Maintenant, quel est ce point de terminaison ici et ce webhook ?
‫Fondamentalement, nous allons spécifier ici une URL à
‫laquelle Stripe enverra automatiquement une demande POST chaque fois qu'une session
‫de paiement s'est terminée avec succès, donc en gros
‫chaque fois qu'un paiement a réussi.
‫Avec cette requête POST, Stripe renverra ensuite les données de session d'origine que
‫nous avons créées lors de la première étape lors de
‫la création de cette session de paiement.
‫C'est la raison pour laquelle nous avions en fait
‫besoin que notre site Web soit déployé ici, car nous devons
‫maintenant spécifier cette URL réelle ici.
‫Prenons cela à
‫partir d'ici, puis ajoutons notre itinéraire ici essentiellement.
‫Je vais appeler cela un webhook-checkout.
‫Ce n'est pas dans l'API, et ce n'est pas dans les réservations.
‫Vous verrez dans un instant pourquoi.
‫Encore une fois, lorsqu'un paiement a
‫réussi, Stripe publiera automatiquement les
‫données de session d'origine sur cette URL.
‫Maintenant, nous devons également sélectionner l'événement.
‫Et vous voyez qu'il y a des tonnes d'événements que nous pourrions utiliser ici.
‫Celui que nous utilisons est checkout_session_completed.
‫Ajoutez ça.
‫Vous devez maintenant saisir à nouveau votre mot de passe ici.
‫Et puis on y va.
‫Ce webhook a donc aussi un secret ici.
‫Celui-ci, nous en aurons également besoin dans une seconde
‫lorsque nous créerons réellement notre route pour cette URL ici.
‫En fait, c'est exactement ce que nous allons faire ensuite.
‫Fondamentalement, dans notre système bien
‫sûr, nous avons maintenant besoin d'un itinéraire pour cela ici,
‫de sorte que lorsque Stripe publie ensuite les données dans notre application,
‫nous pouvons alors réellement en faire quelque chose.
‫Revenons ici et ouvrons notre application.
‫Nous allons en fait ajouter cet itinéraire ici.
‫Encore une fois, je vais vous expliquer pourquoi dans une seconde.
‫Alors, app. post
‫et route standard et bien sûr, nous avons
‫besoin d'une fonction de gestionnaire pour cela.
‫Créons-le rapidement ici dans notre bookingController.
‫Permettez-moi d'appeler cela l'exportation. webhookCheckout.
‫Maintenant, je vais devoir importer ce contrôleur dans l'application. js.
‫Faisons cela juste après le bookingRouter en fait,
‫donc celui-ci et celui-ci, contrôleur
‫et ici aussi contrôleur.
‫Très bien.
‫Maintenant, ici, c'est bookingController. webhookCheckout.
‫Maintenant, pourquoi définissons-nous réellement ce webhook-checkout ici
‫dans l'application. js au lieu de
‫le faire par exemple dans bookingRouter.
‫La raison en est que dans cette fonction de gestionnaire, lorsque
‫nous recevons le corps de Stripe, la fonction Stripe
‫que nous allons ensuite utiliser pour
‫lire le corps a besoin de ce corps sous une forme brute, donc
‫essentiellement sous forme de chaîne et non de JSON.
‫Encore une fois, dans cet itinéraire ici, nous
‫avons besoin que le corps venant avec la demande ne soit
‫pas en JSON, sinon cela ne fonctionnera pas du tout.
‫Maintenant, le fait est que dès qu'une requête
‫atteint ce middleware ici, le corps sera analysé
‫et converti en JSON.
‫Il sera alors mis sur demande. body comme un simple objet JSON.
‫Encore une fois avec cela, ce gestionnaire de route
‫ici ne fonctionnerait alors pas.
‫C'est la seule raison pour laquelle nous devons mettre cette
‫route ici avant d'appeler l'analyseur corporel.
‫Maintenant, nous devons encore analyser le corps, mais
‫dans un format dit brut.
‫Au moment où j'enregistrais cette vidéo, nous ne pouvions
‫pas le faire avec Express prêt à l'emploi.
‫Et donc, dans cette vidéo, nous téléchargeons l'analyseur corporel de npm et l'utilisons
‫comme je le montre dans la vidéo.
‫Cependant, comme cinq jours après l'enregistrement de cette
‫vidéo, Express a également ajouté l'analyseur brut à Express.
‫Maintenant, nous pouvons utiliser express. raw au lieu d'avoir à installer
‫l'analyseur corporel ou le middleware à partir de npm.
‫Encore une fois, dans cette vidéo, je vais maintenant installer l'analyseur corporel, mais vous
‫n'en avez pas vraiment besoin.
‫Vous pouvez simplement utiliser express. cru à la place.
‫Npm installe l'analyseur
‫de corps.
‫Tout cela semble probablement un peu concentré, et je
‫le comprends parfaitement, mais c'est exactement
‫comme cela que la documentation Stripe fonctionne et nous oblige
‫à le faire, vraiment.
‫Revenons ici à notre itinéraire.
‫Dans cette voie, nous avons besoin que le corps soit dans un format brut.
‫Nous pouvons ajouter cela en tant que middleware ici entre la route
‫et le gestionnaire final.
‫Ici, nous disons bodyParser. raw,
‫et nous devons également spécifier
‫ici le type très rapidement comme application/json.
‫Nous avons maintenant ajouté cette analyse de corps en tant que corps brut ici dans
‫cette pile de middleware.
‫Tout cela commencera vraiment à se mettre en
‫place une fois que nous aurons commencé à implémenter cette fonction.
‫En fait, faisons-le maintenant,
‫alors ici.
‫Mais avant de faire cela,
‫débarrassons-nous de tout le code que nous avons écrit
‫afin de le faire fonctionner dès maintenant.
‫Donc, fondamentalement, cette fonction middleware, nous
‫n'en avons plus besoin.
‫Ici aussi dans les
‫viewRoutes, nous n'en avons plus besoin ici non plus.
‫Et enfin, dans le bookingController,
‫rétablissons également notre URL à la normale.
‫Je vais juste laisser tout cela ici pour
‫que vous puissiez le garder comme référence.
‫Mais maintenant, l'URL de réussite devrait en fait être celle-ci.
‫En gros après une réservation réussie,
‫on veut toujours revenir sur my-tours mais sans
‫tous ces paramètres de requête
‫car maintenant ce n'est plus cette fonction ici, qui
‫va s'occuper de créer la réservation mais à
‫la place c'est cette fonction là,
‫qui est de bien sûr celui
‫qui est appelé une fois que Stripe appelle notre webhook.
‫Implémentons maintenant ceci.
‫La première chose que
‫nous devons faire est de supprimer cette signature Stripe de
‫nos en-têtes, donc signature, puis demande. en-têtes, puis
‫à partir de là, signature de bande.
‫Fondamentalement, lorsque Stripe appelle notre webhook,
‫il ajoute un en-tête à
‫cette demande contenant une signature spéciale pour notre webhook.
‫Si vous pensez que vous suivez aveuglément ce
‫que je fais ici, eh
‫bien, (rires) c'est en fait exactement ce que j'ai
‫fait à partir des documentations de Stripe.
‫Encore une fois, c'est vraiment comme ça que Stripe fonctionne,
‫et nous ne pouvons rien faire contre cela.
‫Quoi qu'il en soit, créons ensuite
‫un événement Stripe, donc l'événement const est égal à stripe.
‫Pour cela bien sûr, nous devons installer la bibliothèque
‫Stripe, que nous avons ici.
‫Alors, bande. webhooks. contructEvent.
‫Maintenant, voici où finalement ce corps entre
‫en jeu, alors demandez. corps.
‫Et rappelez-vous que ce corps ici
‫doit être sous sa forme brute,
‫donc essentiellement disponible sous forme de chaîne.
‫Encore une fois, c'est pourquoi nous avons mis cette route
‫avant toutes nos autres
‫routes et surtout avant que l'analyseur de corps puisse faire son
‫travail de conversion de notre corps en un objet JSON.
‫Ensuite, en plus de ce corps, pour l'événement, nous avons besoin d'une signature, donc
‫essentiellement la signature qui a été
‫envoyée avec l'en-tête, puis enfin notre secret de webhook.
‫Récupérons cela d'ici, copiez-le.
‫Comme c'est un secret, nous devrions, comme toujours, l'ajouter
‫ici à notre
‫fichier de configuration, donc STRIPE_WEBHOOK_SECRET.
‫Et puis plus tard bien sûr, n'oubliez pas d'ajouter
‫également cela à notre configuration Heroku.
‫Utilisons maintenant cela.
‫Ajouter un processus. env.
‫J'aurais dû copier ça
‫ici.
‫Donc, vous voyez, tout cela est vraiment pour rendre
‫le processus super, super sécurisé.
‫Nous avons besoin de toutes ces données
‫comme la signature et aussi le secret afin de valider essentiellement
‫les données qui entrent dans le
‫corps afin que personne ne puisse réellement les manipuler.
‫Or lors de la création de cet événement,
‫il peut y
‫avoir des erreurs, par exemple si la
‫signature est erronée ou si le secret est erroné.
‫Et donc, enveloppons cela dans un bloc try-catch.
‫D'accord.
‫Bien sûr, nous avons maintenant besoin de la prise.
‫En cas
‫d'erreur, nous souhaitons renvoyer une erreur
‫à Stripe, alors retournez res. status 400, puis utilisez simplement
‫l'erreur d'envoi de
‫webhook, puis ajoutons simplement l'erreur. message.
‫C'est donc Stripe qui va recevoir cette réponse ici car
‫encore une fois c'est Stripe qui va effectivement appeler l'URL, donc
‫notre webhook, qui va ensuite appeler cette fonction.
‫Maintenant, nous devons bien sûr également déclarer cet événement ici
‫en dehors du bloc try-catch
‫car sinon nous ne pourrons pas l'utiliser là-bas.
‫Alors, laissez l'événement, puis réaffectez-le ici, car rappelez-vous que les
‫const et let ES6 sont
‫à portée de bloc.
‫Et donc, cette variable ne serait pas disponible en dehors
‫de ce bloc.
‫Utilisons maintenant cet événement.
‫Tout d'abord, nous devons tester si c'est vraiment l'événement que
‫nous voulons.
‫Donc, nous pouvons faire l'événement. type est égal à
‫la caisse. session. Achevée.
‫N'oubliez pas que dans notre tableau
‫de bord Stripe, c'est exactement le type que nous avons défini ici.
‫C'est donc le type d'événement.
‫Maintenant, nous vérifions si c'est vraiment l'événement
‫que nous recevons ici juste pour être sûr à 100%.
‫Si c'est le cas, nous souhaitons alors réellement utiliser l'événement pour créer
‫notre réservation dans notre base de données.
‫En fait, faisons cela dans une fonction
‫distincte et non à l'intérieur de tout ce gâchis.
‫Pour cela, je vais créer une fonction.
‫En fait, permettez-moi
‫de lui donner exactement le même nom, alors créezBookingCheckout.
‫C'était en fait un joli nom, mais
‫maintenant il ne s'agit plus d'un
‫middleware mais d'une simple fonction.
‫Cette fonction acceptera les données de session.
‫Et rappelez-vous que les données de session sont exactement cette session que nous
‫avons créée ici en premier lieu.
‫S'il s'agit du bon événement, appelons
‫en fait cette fonction,
‫donc créezBookingCheckout avec la session, qui est
‫à l'événement. Les données. objet.
‫Et
‫enfin, renvoyons simplement une réponse à Stripe.
‫Donc, le statut
‫200, puis disons que certains
‫json reçoivent la valeur true.
‫Logique?
‫Une fois de plus, tout ce
‫code ici s'exécutera chaque fois qu'un paiement sera réussi.
‫Stripe appellera alors notre webhook, qui est l'URL, qui
‫va appeler cette fonction.
‫Et ainsi, cette fonction reçoit un corps de la
‫demande, puis, avec la signature et/ou le secret du webhook, crée
‫un événement qui contiendra la session.
‫Et puis en utilisant ces données de session,
‫nous pouvons créer notre nouvelle réservation dans la base de données.
‫Et donc, ce sera en fait assez similaire
‫à ce que nous avions ici auparavant.
‫Nous aurons donc à nouveau besoin de cette ligne de code.
‫Donc, ce sera également une fonction asynchrone.
‫Et donc, c'est exactement la même chose.
‫Maintenant, ce dont nous avons
‫besoin ici bien sûr, c'est d'avoir accès à la visite, à l'utilisateur et au prix.
‫Mais ces données sont à nouveau stockées dans cette session.
‫Alors, commençons par la tournée.
‫Et rappelez-vous que lorsque nous avons créé
‫cette fonction de gestionnaire pour
‫la première fois, j'ai spécifié ce champ client_reference_id
‫et ajouté le tourId à cela.
‫Vous vous en souvenez ?
‫Je l'ai fait parce qu'à l'époque,
‫je savais déjà que nous aurions besoin de cet identifiant de tournée un peu plus tard.
‫Maintenant, c'est à ce moment-là que nous avons réellement besoin
‫de l'identifiant de la tournée afin de pouvoir créer cette nouvelle réservation.
‫Et donc, maintenant, l'ID de tournée dont
‫nous avons besoin est l'ID de référence du client de point de session.
‫Alors, copions ceci et disons
‫session.
‫Et bien sûr, ici, nous devons dire tournée.
‫Donc, c'est l'ID de la tournée.
‫Ensuite, nous avons besoin de l'ID utilisateur.
‫Maintenant, les informations que nous avons
‫dans notre session sur l'utilisateur sont l'e-mail de l'utilisateur.
‫Et donc, maintenant, ce
‫que nous devons faire, c'est essentiellement obtenir l'ID de l'utilisateur.
‫Pour cela, nous interrogerons par e-mail.
‫Ce n'est pas un problème car l'e-mail est également unique.
‫Sur cette base, nous pouvons alors trouver l'ID unique.
‫Donc, l'utilisateur const est en attente.
‫Et je pense que nous avons déjà l'utilisateur ici.
‫Non?
‫Non, en fait, je ne le fais pas.
‫Alors, faisons-le ici.
‫Et l'utilisateur ici aussi.
‫D'accord.
‫Alors, Utilisateur. findOne, puis interrogez par e-mail, qui est dans
‫le point de session, et je pense que c'est l'e-mail du
‫client ou quelque chose du genre.
‫C'est client_email.
‫D'accord.
‫Mais cela renverra alors l'intégralité du document, mais
‫nous voulons en fait l'ID.
‫Alors, enveloppons tout cela ici entre
‫parenthèses, puis appelons l'ID là-bas ou lisons réellement l'ID.
‫Donc c'est tout.
‫Et enfin, le prix.
‫Où est stocké le prix ?
‫Eh bien, c'est ici dans line_items.
‫C'est un tableau, donc à l'élément
‫zéro, puis le montant divisé par 100.
‫Donc, nous l'avons multiplié ici par 100 pour obtenir des centimes,
‫mais maintenant, bien sûr, nous voulons le récupérer en dollars.
‫Donc, nous devons essentiellement diviser cela.
‫Et donc, séance. line_items, puis
‫le montant du premier élément si j'ai raison.
‫Ouais.
‫Donc, montant divisé par 100.
‫Ça devrait être ça en fait.
‫Engageons maintenant nos modifications dans le dépôt
‫et transférons-les vers Stripe.
‫Donc, git add all, bien
‫sûr, puis git commit message
‫Implémentation améliorée de
‫stripe, puis git push heroku master.
‫Encore une fois, cela prendra du temps.
‫Je te verrai quand ce sera fait.
‫Très bien.
‫Maintenant, n'oubliez pas de définir cette nouvelle variable d'environnement.
‫Donc, c'est le jeu de deux-points de la configuration heroku, puis
‫copiez-le simplement à partir d'ici.
‫D'accord.
‫Cela redémarre ensuite l'application.
‫Et c'est tout.
‫Alors, allons-y maintenant et testons-le.
‫Très bien.
‫Nous sommes toujours là dans notre application.
‫Voyons quelles visites Laura a déjà réservées.
‫Elle a le Forest Hiker.
‫Cette réservation était toujours effectuée selon l'ancienne méthode.
‫Mais cette ancienne méthode ne fonctionne plus.
‫Maintenant, si nous effectuons une autre réservation
‫et que cela fonctionne, eh bien,
‫cela signifiera bien sûr que notre nouvelle implémentation fonctionne.
‫Testons cela ici.
‫Comme toujours, 4242.
‫Attendons maintenant.
‫Eh bien, cela ne s'est apparemment pas très bien
‫passé car sinon notre deuxième nouvelle tournée devrait
‫déjà être ici dans nos réservations.
‫Voyons ici dans notre tableau de bord.
‫Si nous rechargeons
‫maintenant cela, nous voyons en fait qu'il y a eu un événement réussi.
‫Donc, c'est l'événement que nous venons de créer
‫et qui a envoyé ce corps ici et
‫a ensuite reçu cette réponse.
‫Donc, cette réception définie sur true est
‫exactement ce que nous avons fait ici dans notre code,
‫donc ceci ici.
‫Donc, c'est la réponse que nous
‫avons envoyée et le corps que nous avons reçu était toutes ces données.
‫Et donc, on peut voir ici la
‫séance avec le prix, avec l'email, avec la tournée.
‫Et donc, je ne sais pas pourquoi cela n'a pas fonctionné.
‫Alors, rechargeons rapidement ceci ici.
‫Donc, en fait, notre implémentation Stripe devrait être correcte, mais, pour une
‫raison quelconque, notre nouvelle réservation n'a pas été créée.
‫Vérifions cela également ici dans Compass.
‫Et effectivement, il n'y est pas.
‫Alors, revenons à notre code ici.
‫Oh et une erreur que je vois tout de suite est ici.
‫Donc, il devrait être terminé comme ceci.
‫Alors, c'est une erreur stupide.
‫Voyons simplement s'il peut y
‫avoir une autre erreur ici dans createBookingCheckout.
‫Ici, nous
‫avons line_items.
‫Voyons si c'est correct.
‫Et oui, il semble être.
‫Nous pouvons également le confirmer ici encore dans notre Stripe.
‫En fait, ici, cela s'appelle display_items.
‫C'est bizarre.
‫Juste pour être sûr, appelons-le également display_items ici
‫dans notre code ici.
‫Maintenant, une autre chose que j'ai remarquée
‫alors que je jetais un autre
‫coup d'œil ici, c'est que nous avons toujours cette image codée en dur
‫pour cet autre natours. dév.
‫Maintenant, corrigeons cela car à ce stade, bien sûr, notre
‫site Web est déjà en ligne et déployé.
‫Et donc, nous pouvons essentiellement remplacer cela par le
‫même que nous avons ici.
‫Donc, nous utilisons cette partie ici plusieurs fois.
‫Et donc, il est temps de l'utiliser à nouveau ici.
‫Ouais.
‫Essayons de redéployer cela.
‫Alors, git ajoute tout à nouveau.
‫Et appelons simplement cela
‫ici Implémentation de bande améliorée deux.
‫Et puis poussez-le à nouveau vers Heroku.
‫D'accord.
‫Essayons encore une fois.
‫Revenons ici.
‫Essayons maintenant de réserver à nouveau à Park Camper.
‫Très bien.
‫Vous devriez voir l'image apparaître ici sur le côté gauche.
‫Cela signifie que notre nouvelle intégration d'images a
‫également très bien fonctionné.
‫Maintenant, c'est le traitement.
‫Ah maintenant c'est ici.
‫Super.
‫C'est beau.
‫Maintenant, nous avons vraiment une implémentation
‫Stripe sécurisée et beaucoup plus professionnelle dans
‫notre application.
‫C'est génial.
‫Bien sûr, si vous
‫rechargez ici, alors vous devriez voir ce nouvel événement ici, donc
‫ce nouvel appel à notre webhook, qui
‫bien sûr a encore une fois réussi.
‫C'est juste génial.
‫Maintenant, il y a juste une dernière chose que je
‫veux faire, qui est essentiellement de donner à l'utilisateur des commentaires sous la
‫forme d'un de ces messages verts que nous utilisons
‫également par exemple dans la connexion.
‫À l'heure actuelle, notre application ne
‫donne pas vraiment de retour lorsqu'une nouvelle visite a été réservée.
‫Maintenant, je veux changer cela.
‫Cependant, faire cela n'est pas vraiment simple car
‫rappelez-vous que ces messages
‫sont en fait affichés par JavaScript.
‫Donc, dans les autres cas, nous avons fait un appel HTTP à notre API.
‫Et puis, lorsque cela a été fait, nous avons utilisé JavaScript
‫pour afficher une sorte de message.
‫Mais maintenant, nous ne le faisons pas de cette façon.
‫Et donc, le message devrait déjà se trouver quelque part dans le
‫HTML dès que la page
‫se charge afin que notre JavaScript puisse alors récupérer
‫ce message dans le HTML et l'afficher joliment là-haut dans l'une
‫de ces bannières.
‫Et donc, la façon dont je vais mettre ces alertes
‫dans le HTML est encore une fois en utilisant une propriété de données.
‫Commençons par implémenter cette fonctionnalité directement dans notre
‫modèle principal.
‫C'est ici dans les vues, base.
‫Je vais en fait ajouter ce message
‫d'alerte directement sur l'élément body.
‫Ici, nous aurons une propriété d'alerte de données, qui
‫ne devrait en fait être définie
‫que si la variable d'alerte est disponible ici.
‫Alors, utilisons ES6, donc une chaîne de modèle, et
‫disons s'il y a une alerte, alors
‫utilisons alert ici, et sinon, une chaîne vide.
‫Et donc, cette alerte ici sera le message
‫d'alerte que JavaScript va ensuite récupérer et afficher sur la page.
‫Maintenant, comment ce message d'alerte se retrouve-t-il alors en tant que
‫variable d'alerte ici dans notre modèle ?
‫Eh bien, j'ai trouvé une solution réutilisable afin que
‫nous puissions l'utiliser dans toute notre application.
‫C'est-à-dire que sur la chaîne de requête, nous
‫ajouterons un mot-clé d'alerte, puis nous
‫aurons un middleware, qui prendra
‫ce mot-clé de l'URL et, selon le mot-clé que
‫nous y avons mis, mettra alors tout
‫un message d'alerte en réponse. . des locaux.
‫Et donc, rappelez-vous que tout ce qui est en réponse. locaux est alors disponible
‫en tant que variable dans tous nos modèles.
‫Donc, nous l'avons utilisé auparavant dans
‫notre authController, je crois.
‫Très rapidement, permettez-moi de vous le montrer.
‫Ici, nous avons dit réponse. local. user et
‫y mettre l'utilisateur actuel.
‫Ensuite, automatiquement dans tous les modèles, nous
‫avons accès à cette variable utilisateur.
‫Alors, implémentons maintenant ce que je viens
‫de dire et commençons par l'URL.
‫Ce que je vais faire ici, c'est en fait ajouter cette chaîne de
‫requête ici à l'URL de réussite.
‫Ici, je dirai alerte égale réservation.
‫Maintenant, je pourrais, dans toutes les autres URL, également ajouter une alerte, puis
‫avec un mot-clé différent ici, bien sûr.
‫Et nous allons le faire ici vraiment pour cette réservation.
‫Mais encore une fois, j'ai créé une sorte de solution réutilisable ici.
‫Quoi qu'il en soit, maintenant dans nos routes, nous avons besoin essentiellement d'un
‫middleware, qui fonctionnera pour toutes les requêtes.
‫Et c'est ce middleware, qui va récupérer l'alerte
‫de la chaîne de requête et mettre un message d'alerte
‫sur notre réponse. des locaux.
‫Alors, routeur.
‫utilisez viewsController. alertes.
‫Et donc, il s'agit d'une fonction
‫middleware, qui s'exécutera essentiellement pour chaque demande unique qui entre dans
‫ce routeur, donc essentiellement
‫pour toutes les demandes adressées à notre site Web.
‫Créons maintenant ce middleware dans
‫notre viewsController.
‫Donc, les exportations. demande
‫d'alertes, réponse et suivant.
‫Et donc,
‫l'alerte est demande. requete. alerte.
‫Et donc, utilisons encore une fois cette structuration.
‫Et puis disons que si l'alerte est égale à la réservation, donc l'alerte
‫que nous mettons ici dans la chaîne de requête, eh
‫bien, dans ce
‫cas, disons la réponse. des locaux. alerte
‫sera votre réservation réussie,
‫veuillez vérifier votre e-mail pour une confirmation.
‫Et nous devrions également ajouter une
‫autre phrase, qui est celle-ci, si votre réservation ne le fait
‫pas, sélectionnez-la, n'apparaît pas ici immédiatement, veuillez revenir
‫plus tard.
‫Et cette
‫dernière partie est due au fait que Stripe
‫dit très spécifiquement dans sa documentation que parfois le webhook est
‫appelé un peu après l'appel de l'URL de réussite.
‫Dans ce cas, cette URL de réussite afficherait alors
‫toutes les visites en cours, mais seulement après cela,
‫le webhook serait appelé
‫et la visite serait créée dans notre base de données.
‫Par conséquent, la nouvelle réservation n'apparaîtrait pas immédiatement
‫sur la page Mes réservations.
‫Mais bien sûr, tout fonctionnait encore bien dans ce cas.
‫Et donc, je recharge simplement, mais plus tard, nous réglerons ce problème.
‫Il ne nous reste plus qu'à appeler le prochain middleware.
‫Et c'est en fait ça.
‫Encore une fois, nous n'avons fait cela ici que pour une alerte égale
‫à une réservation, mais nous pouvons maintenant l'utiliser
‫partout sur notre site Web en définissant différents mots-clés
‫d'alerte et chaînes de requête.
‫Avec cela, nous mettons ce message ici sur res. des locaux. alerte.
‫Encore une fois, notre modèle de base le
‫récupérera et l'affichera ici dans cette propriété d'alerte de données.
‫Et donc, il ne reste plus qu'à aller dans notre index. js et lisez
‫l'alerte à partir d'ici, puis affichez-la.
‫Et donc, cela devrait être assez facile.
‫Ici en public, faisons-le correctement dans l'index.
‫Et la première chose est que nous devons en fait importer la
‫fonction d'alertes.
‫Ce n'est pas une application.
‫C'est ici dans l'index.
‫D'accord.
‫Et puis ici, lisons essentiellement cette alerte.
‫Ainsi, const alertMessage, disons, est un
‫document. querySelector, puis l'élément body,
‫ensemble de données de points. alerte.
‫Et donc, seulement s'il y a
‫une alerte, bien sûr, alors affichez
‫l'alerte avec
‫succès et le message d'alerte.
‫Et maintenant, cette petite chose que je veux
‫faire est de changer un peu cette fonction showAlert ici parce que nous
‫avons en fait beaucoup de texte maintenant.
‫Et l'heure standard à laquelle l'alerte est
‫affichée ne serait pas suffisante pour réellement lire tout le texte.
‫Donc, vous voyez ici qu'au bout de cinq
‫secondes, l'alerte est masquée.
‫Permettons en fait à l'utilisateur de
‫spécifier le nombre de secondes pendant lesquelles l'alerte est affichée.
‫Nous le ferons par défaut de cinq secondes.
‫Ici, nous faisons simplement le temps multiplié par 1 000 pour
‫le convertir en millisecondes.
‫Ainsi, toutes les fonctions fonctionneront partout
‫en cinq secondes.
‫Faisons en fait sept secondes si
‫nous ne spécifions rien.
‫Mais si nous le voulons, nous pouvons alors outrepasser ce sept.
‫Et donc, je vais le faire
‫maintenant ici et le mettre en fait 20 secondes sur l'écran.
‫Très bien.
‫Je pense que ça devrait être ça.
‫J'espère que cela avait du sens.
‫Compilons maintenant très rapidement notre bundle.
‫C'est npm run build, puis appuyez sur la saisie semi-automatique.
‫Cela prend aussi un peu de temps.
‫Mais maintenant c'est fait.
‫Déployons-le maintenant une dernière fois en espérant
‫qu'il fonctionne réellement.
‫Alors, git commit.
‫Alors, les messages Stripe.
‫Et une dernière fois, git push heroku master.
‫Testons-le maintenant en achetant encore une autre tournée ici.
‫Prenons le City Wanderer cette fois.
‫Oh je viens de voir qu'il y a déjà un message ici.
‫Ce n'est pas bon.
‫Et vous voyez qu'il a disparu au bout de 20 secondes.
‫Donc, il semble que maintenant,
‫par défaut, il mettra toujours cette classe d'alerte ici.
‫(rires)
‫Ouais.
‫C'est parce qu'ici il devrait être alertMessage et
‫pas seulement alert.
‫Mais de toute façon, testons maintenant si le message
‫est correct lorsque nous réservons la visite.
‫D'accord.
‫Attendons maintenant.
‫Nous y voilà.
‫En effet, il y a notre message.
‫Si beau.
‫De plus, notre tournée apparaît ici.
‫Et vous voyez qu'il reste vraiment ici pendant beaucoup de temps.
‫Donc, ça marche aussi.
‫Allons très vite...
‫Et d'abord, nous devons en fait reconstruire le bundle ici.
‫Ensuite, nous pouvons tout ajouter à
‫notre zone de transit, correction de bogue d'alerte de message.
‫Donc, ce
‫sont déjà (rires) des messages à consonance vraiment professionnelle ici.
‫Maintenant, une dernière poussée vers Heroku.
‫Maintenant, lorsque nous chargeons notre page, nous ne
‫devrions voir aucun message d'alerte.
‫Et en effet, maintenant tout est propre.
‫Et donc, je peux maintenant dire qu'au moins pour
‫l'instant, ce projet est vraiment terminé.
‫Encore une fois, excellent travail, félicitations et bravo
‫d'être probablement l'une des rares personnes à aller jusqu'au bout du
‫projet et à vraiment construire ce magnifique
‫site Web et également une API que vous pouvez
‫maintenant mettre sur votre portfolio et montrer
‫au monde.