1
00:00:01,010 --> 00:00:03,730
‫Conférencier : Et maintenant, pour terminer ce

2
00:00:03,730 --> 00:00:06,593
‫projet, terminons cette intégration de Stripe avec des webhooks.

3
00:00:09,310 --> 00:00:12,040
‫Commençons par nous rappeler comment notre

4
00:00:12,040 --> 00:00:14,210
‫intégration Stripe fonctionne actuellement.

5
00:00:14,210 --> 00:00:16,750
‫Nous avons ce point de terminaison de

6
00:00:16,750 --> 00:00:19,540
‫session de paiement, qui est appelé depuis notre front-end.

7
00:00:19,540 --> 00:00:22,293
‫Cela appellera ensuite la fonction getCheckoutSession, donc

8
00:00:23,440 --> 00:00:25,100
‫essentiellement celle-ci ici,

9
00:00:25,100 --> 00:00:28,180
‫qui créera une session de paiement sur le

10
00:00:28,180 --> 00:00:30,300
‫serveur en utilisant toutes ces informations

11
00:00:30,300 --> 00:00:32,750
‫ici, puis la renverra au client.

12
00:00:32,750 --> 00:00:35,170
‫Puis une fois que le traitement du

13
00:00:35,170 --> 00:00:37,280
‫paiement est effectué avec succès par

14
00:00:37,280 --> 00:00:40,990
‫Stripe, redirigez ensuite l'utilisateur vers cette URL de réussite, donc celle-ci

15
00:00:40,990 --> 00:00:42,483
‫que nous avons créée.

16
00:00:44,210 --> 00:00:48,120
‫N'oubliez pas que sur cette URL, nous avons ajouté l'identifiant de la

17
00:00:48,120 --> 00:00:50,920
‫tournée, l'identifiant de l'utilisateur et également le prix.

18
00:00:50,920 --> 00:00:55,040
‫Nous avons fait cela pour qu'une fois cette URL ici appelée, notre

19
00:00:55,040 --> 00:00:57,920
‫application crée un nouveau document de réservation dans

20
00:00:57,920 --> 00:00:59,680
‫notre base de données.

21
00:00:59,680 --> 00:01:01,047
‫Comment cela a-t-il fonctionné ?

22
00:01:01,047 --> 00:01:04,743
‫Dans l'itinéraire my-tours, nous avons un middleware pour cela.

23
00:01:06,040 --> 00:01:09,940
‫Rappelez-vous, ici dans viewRoutes, dans my-tours, nous

24
00:01:09,940 --> 00:01:12,467
‫avons ce createBookingCheckout.

25
00:01:14,770 --> 00:01:18,628
‫Cette fonction ici, qui, à partir de la requête, prend essentiellement le

26
00:01:18,628 --> 00:01:21,440
‫tour, l'utilisateur et le prix, et crée une

27
00:01:21,440 --> 00:01:25,023
‫entrée dans la base de données à l'aide de ces données.

28
00:01:26,350 --> 00:01:29,160
‫Fondamentalement, nous mettons ces données sur l'URL

29
00:01:29,160 --> 00:01:32,500
‫chaque fois que Stripe traite avec succès un paiement.

30
00:01:32,500 --> 00:01:34,990
‫Et puis cette fonction middleware que nous avons

31
00:01:34,990 --> 00:01:38,570
‫ici récupère les données et crée une nouvelle réservation dans notre système

32
00:01:38,570 --> 00:01:39,960
‫en utilisant ces données.

33
00:01:39,960 --> 00:01:42,790
‫Et puis après cela, nous redirigeons essentiellement

34
00:01:42,790 --> 00:01:45,763
‫ici sur l'URL d'origine sans la chaîne de requête.

35
00:01:46,770 --> 00:01:50,150
‫Le problème, c'est que ce n'est pas vraiment sécurisé.

36
00:01:50,150 --> 00:01:52,963
‫Ainsi, tous ceux qui connaissent cette structure

37
00:01:54,010 --> 00:01:57,670
‫d'URL, donc celle-ci ici, quel tour, utilisateur et prix dans

38
00:01:57,670 --> 00:02:00,700
‫la chaîne de requête, peuvent créer une réservation dans

39
00:02:01,761 --> 00:02:03,850
‫notre système sans réellement payer.

40
00:02:03,850 --> 00:02:07,120
‫Donc, tout ce que nous avons à faire est

41
00:02:07,120 --> 00:02:08,500
‫d'ouvrir cette URL

42
00:02:08,500 --> 00:02:11,680
‫avec des données, puis de créer automatiquement une réservation

43
00:02:11,680 --> 00:02:14,193
‫sans passer par le processus Stripe.

44
00:02:15,540 --> 00:02:18,630
‫Rappelez-vous comment à l'époque j'ai dit que nous allions résoudre ce

45
00:02:18,630 --> 00:02:20,853
‫problème en utilisant quelque chose appelé webhooks.

46
00:02:22,090 --> 00:02:23,120
‫Donc, nous le faisons maintenant.

47
00:02:23,120 --> 00:02:24,090
‫Car pour cela,

48
00:02:24,090 --> 00:02:27,140
‫nous avons en fait besoin que notre site web soit déployé.

49
00:02:27,140 --> 00:02:29,350
‫Maintenant, à ce stade, c'est effectivement le cas.

50
00:02:29,350 --> 00:02:31,833
‫Et donc, maintenant nous pouvons implémenter ces webhooks.

51
00:02:33,240 --> 00:02:35,663
‫Pour cela, direction notre tableau de bord Stripe.

52
00:02:37,400 --> 00:02:39,750
‫Et en fait, je l'ai déjà ouvert ici.

53
00:02:39,750 --> 00:02:43,903
‫Et puis allez ici aux développeurs, puis choisissez des webhooks, et

54
00:02:45,070 --> 00:02:47,970
‫ici, ajoutez un nouveau point de terminaison.

55
00:02:47,970 --> 00:02:52,149
‫Maintenant, quel est ce point de terminaison ici et ce webhook ?

56
00:02:52,149 --> 00:02:55,380
‫Fondamentalement, nous allons spécifier ici une URL à

57
00:02:55,380 --> 00:02:59,500
‫laquelle Stripe enverra automatiquement une demande POST chaque fois qu'une session

58
00:02:59,500 --> 00:03:02,800
‫de paiement s'est terminée avec succès, donc en gros

59
00:03:02,800 --> 00:03:05,740
‫chaque fois qu'un paiement a réussi.

60
00:03:05,740 --> 00:03:09,920
‫Avec cette requête POST, Stripe renverra ensuite les données de session d'origine que

61
00:03:09,920 --> 00:03:13,230
‫nous avons créées lors de la première étape lors de

62
00:03:13,230 --> 00:03:15,623
‫la création de cette session de paiement.

63
00:03:17,540 --> 00:03:20,130
‫C'est la raison pour laquelle nous avions en fait

64
00:03:20,130 --> 00:03:23,010
‫besoin que notre site Web soit déployé ici, car nous devons

65
00:03:23,010 --> 00:03:24,923
‫maintenant spécifier cette URL réelle ici.

66
00:03:27,170 --> 00:03:28,573
‫Prenons cela à

67
00:03:31,290 --> 00:03:34,150
‫partir d'ici, puis ajoutons notre itinéraire ici essentiellement.

68
00:03:34,150 --> 00:03:36,930
‫Je vais appeler cela un webhook-checkout.

69
00:03:41,620 --> 00:03:45,350
‫Ce n'est pas dans l'API, et ce n'est pas dans les réservations.

70
00:03:45,350 --> 00:03:47,593
‫Vous verrez dans un instant pourquoi.

71
00:03:49,130 --> 00:03:51,210
‫Encore une fois, lorsqu'un paiement a

72
00:03:51,210 --> 00:03:53,280
‫réussi, Stripe publiera automatiquement les

73
00:03:53,280 --> 00:03:55,503
‫données de session d'origine sur cette URL.

74
00:03:58,060 --> 00:04:00,380
‫Maintenant, nous devons également sélectionner l'événement.

75
00:04:00,380 --> 00:04:04,740
‫Et vous voyez qu'il y a des tonnes d'événements que nous pourrions utiliser ici.

76
00:04:04,740 --> 00:04:09,667
‫Celui que nous utilisons est checkout_session_completed.

77
00:04:11,767 --> 00:04:12,650
‫Ajoutez ça.

78
00:04:12,650 --> 00:04:15,083
‫Vous devez maintenant saisir à nouveau votre mot de passe ici.

79
00:04:17,100 --> 00:04:19,110
‫Et puis on y va.

80
00:04:19,110 --> 00:04:22,665
‫Ce webhook a donc aussi un secret ici.

81
00:04:22,665 --> 00:04:25,850
‫Celui-ci, nous en aurons également besoin dans une seconde

82
00:04:25,850 --> 00:04:29,063
‫lorsque nous créerons réellement notre route pour cette URL ici.

83
00:04:29,980 --> 00:04:32,430
‫En fait, c'est exactement ce que nous allons faire ensuite.

84
00:04:33,750 --> 00:04:35,600
‫Fondamentalement, dans notre système bien

85
00:04:35,600 --> 00:04:38,840
‫sûr, nous avons maintenant besoin d'un itinéraire pour cela ici,

86
00:04:39,960 --> 00:04:43,840
‫de sorte que lorsque Stripe publie ensuite les données dans notre application,

87
00:04:43,840 --> 00:04:46,233
‫nous pouvons alors réellement en faire quelque chose.

88
00:04:48,120 --> 00:04:52,233
‫Revenons ici et ouvrons notre application.

89
00:04:54,740 --> 00:04:57,743
‫Nous allons en fait ajouter cet itinéraire ici.

90
00:04:59,610 --> 00:05:03,100
‫Encore une fois, je vais vous expliquer pourquoi dans une seconde.

91
00:05:03,100 --> 00:05:04,350
‫Alors, app. post

92
00:05:06,320 --> 00:05:08,850
‫et route standard et bien sûr, nous avons

93
00:05:08,850 --> 00:05:10,810
‫besoin d'une fonction de gestionnaire pour cela.

94
00:05:10,810 --> 00:05:14,720
‫Créons-le rapidement ici dans notre bookingController.

95
00:05:14,720 --> 00:05:19,013
‫Permettez-moi d'appeler cela l'exportation. webhookCheckout.

96
00:05:31,360 --> 00:05:36,360
‫Maintenant, je vais devoir importer ce contrôleur dans l'application. js.

97
00:05:39,210 --> 00:05:42,110
‫Faisons cela juste après le bookingRouter en fait,

98
00:05:45,150 --> 00:05:47,133
‫donc celui-ci et celui-ci, contrôleur

99
00:05:49,440 --> 00:05:51,383
‫et ici aussi contrôleur.

100
00:05:54,580 --> 00:05:56,050
‫Très bien.

101
00:05:56,050 --> 00:06:01,050
‫Maintenant, ici, c'est bookingController. webhookCheckout.

102
00:06:04,800 --> 00:06:08,820
‫Maintenant, pourquoi définissons-nous réellement ce webhook-checkout ici

103
00:06:08,820 --> 00:06:12,410
‫dans l'application. js au lieu de

104
00:06:12,410 --> 00:06:14,440
‫le faire par exemple dans bookingRouter.

105
00:06:14,440 --> 00:06:17,950
‫La raison en est que dans cette fonction de gestionnaire, lorsque

106
00:06:17,950 --> 00:06:20,677
‫nous recevons le corps de Stripe, la fonction Stripe

107
00:06:20,677 --> 00:06:22,850
‫que nous allons ensuite utiliser pour

108
00:06:22,850 --> 00:06:26,780
‫lire le corps a besoin de ce corps sous une forme brute, donc

109
00:06:26,780 --> 00:06:29,633
‫essentiellement sous forme de chaîne et non de JSON.

110
00:06:31,370 --> 00:06:34,140
‫Encore une fois, dans cet itinéraire ici, nous

111
00:06:34,140 --> 00:06:37,555
‫avons besoin que le corps venant avec la demande ne soit

112
00:06:37,555 --> 00:06:40,600
‫pas en JSON, sinon cela ne fonctionnera pas du tout.

113
00:06:40,600 --> 00:06:43,700
‫Maintenant, le fait est que dès qu'une requête

114
00:06:43,700 --> 00:06:46,710
‫atteint ce middleware ici, le corps sera analysé

115
00:06:46,710 --> 00:06:48,563
‫et converti en JSON.

116
00:06:49,700 --> 00:06:54,650
‫Il sera alors mis sur demande. body comme un simple objet JSON.

117
00:06:54,650 --> 00:06:57,520
‫Encore une fois avec cela, ce gestionnaire de route

118
00:06:57,520 --> 00:06:59,180
‫ici ne fonctionnerait alors pas.

119
00:06:59,180 --> 00:07:02,520
‫C'est la seule raison pour laquelle nous devons mettre cette

120
00:07:02,520 --> 00:07:04,557
‫route ici avant d'appeler l'analyseur corporel.

121
00:07:05,580 --> 00:07:08,260
‫Maintenant, nous devons encore analyser le corps, mais

122
00:07:08,260 --> 00:07:10,120
‫dans un format dit brut.

123
00:07:10,120 --> 00:07:13,690
‫Au moment où j'enregistrais cette vidéo, nous ne pouvions

124
00:07:13,690 --> 00:07:17,220
‫pas le faire avec Express prêt à l'emploi.

125
00:07:17,220 --> 00:07:21,500
‫Et donc, dans cette vidéo, nous téléchargeons l'analyseur corporel de npm et l'utilisons

126
00:07:21,500 --> 00:07:24,220
‫comme je le montre dans la vidéo.

127
00:07:24,220 --> 00:07:28,340
‫Cependant, comme cinq jours après l'enregistrement de cette

128
00:07:28,340 --> 00:07:32,770
‫vidéo, Express a également ajouté l'analyseur brut à Express.

129
00:07:32,770 --> 00:07:37,000
‫Maintenant, nous pouvons utiliser express. raw au lieu d'avoir à installer

130
00:07:37,000 --> 00:07:39,523
‫l'analyseur corporel ou le middleware à partir de npm.

131
00:07:40,530 --> 00:07:44,610
‫Encore une fois, dans cette vidéo, je vais maintenant installer l'analyseur corporel, mais vous

132
00:07:44,610 --> 00:07:46,440
‫n'en avez pas vraiment besoin.

133
00:07:46,440 --> 00:07:49,293
‫Vous pouvez simplement utiliser express. cru à la place.

134
00:07:51,590 --> 00:07:52,700
‫Npm installe l'analyseur

135
00:07:54,480 --> 00:07:55,403
‫de corps.

136
00:07:58,950 --> 00:08:02,120
‫Tout cela semble probablement un peu concentré, et je

137
00:08:02,120 --> 00:08:04,350
‫le comprends parfaitement, mais c'est exactement

138
00:08:04,350 --> 00:08:08,050
‫comme cela que la documentation Stripe fonctionne et nous oblige

139
00:08:08,890 --> 00:08:10,893
‫à le faire, vraiment.

140
00:08:15,210 --> 00:08:17,100
‫Revenons ici à notre itinéraire.

141
00:08:17,100 --> 00:08:20,453
‫Dans cette voie, nous avons besoin que le corps soit dans un format brut.

142
00:08:21,460 --> 00:08:25,330
‫Nous pouvons ajouter cela en tant que middleware ici entre la route

143
00:08:25,330 --> 00:08:26,673
‫et le gestionnaire final.

144
00:08:28,654 --> 00:08:31,013
‫Ici, nous disons bodyParser. raw,

145
00:08:34,830 --> 00:08:37,490
‫et nous devons également spécifier

146
00:08:39,450 --> 00:08:43,127
‫ici le type très rapidement comme application/json.

147
00:08:48,130 --> 00:08:52,660
‫Nous avons maintenant ajouté cette analyse de corps en tant que corps brut ici dans

148
00:08:52,660 --> 00:08:54,183
‫cette pile de middleware.

149
00:08:55,964 --> 00:08:58,150
‫Tout cela commencera vraiment à se mettre en

150
00:08:58,150 --> 00:09:00,970
‫place une fois que nous aurons commencé à implémenter cette fonction.

151
00:09:00,970 --> 00:09:02,543
‫En fait, faisons-le maintenant,

152
00:09:03,820 --> 00:09:05,210
‫alors ici.

153
00:09:05,210 --> 00:09:07,100
‫Mais avant de faire cela,

154
00:09:07,100 --> 00:09:09,780
‫débarrassons-nous de tout le code que nous avons écrit

155
00:09:09,780 --> 00:09:11,680
‫afin de le faire fonctionner dès maintenant.

156
00:09:11,680 --> 00:09:14,420
‫Donc, fondamentalement, cette fonction middleware, nous

157
00:09:14,420 --> 00:09:16,350
‫n'en avons plus besoin.

158
00:09:16,350 --> 00:09:18,480
‫Ici aussi dans les

159
00:09:18,480 --> 00:09:21,980
‫viewRoutes, nous n'en avons plus besoin ici non plus.

160
00:09:21,980 --> 00:09:24,770
‫Et enfin, dans le bookingController,

161
00:09:24,770 --> 00:09:28,153
‫rétablissons également notre URL à la normale.

162
00:09:31,080 --> 00:09:33,180
‫Je vais juste laisser tout cela ici pour

163
00:09:33,180 --> 00:09:35,233
‫que vous puissiez le garder comme référence.

164
00:09:37,390 --> 00:09:40,863
‫Mais maintenant, l'URL de réussite devrait en fait être celle-ci.

165
00:09:43,090 --> 00:09:45,400
‫En gros après une réservation réussie,

166
00:09:45,400 --> 00:09:48,090
‫on veut toujours revenir sur my-tours mais sans

167
00:09:48,090 --> 00:09:50,350
‫tous ces paramètres de requête

168
00:09:51,350 --> 00:09:54,580
‫car maintenant ce n'est plus cette fonction ici, qui

169
00:09:54,580 --> 00:09:57,430
‫va s'occuper de créer la réservation mais à

170
00:09:57,430 --> 00:09:59,770
‫la place c'est cette fonction là,

171
00:09:59,770 --> 00:10:02,060
‫qui est de bien sûr celui

172
00:10:02,060 --> 00:10:05,633
‫qui est appelé une fois que Stripe appelle notre webhook.

173
00:10:07,140 --> 00:10:08,470
‫Implémentons maintenant ceci.

174
00:10:08,470 --> 00:10:10,140
‫La première chose que

175
00:10:10,140 --> 00:10:13,763
‫nous devons faire est de supprimer cette signature Stripe de

176
00:10:15,780 --> 00:10:19,840
‫nos en-têtes, donc signature, puis demande. en-têtes, puis

177
00:10:21,500 --> 00:10:26,373
‫à partir de là, signature de bande.

178
00:10:28,220 --> 00:10:30,710
‫Fondamentalement, lorsque Stripe appelle notre webhook,

179
00:10:30,710 --> 00:10:32,830
‫il ajoute un en-tête à

180
00:10:32,830 --> 00:10:36,280
‫cette demande contenant une signature spéciale pour notre webhook.

181
00:10:38,480 --> 00:10:40,700
‫Si vous pensez que vous suivez aveuglément ce

182
00:10:40,700 --> 00:10:42,590
‫que je fais ici, eh

183
00:10:42,590 --> 00:10:45,070
‫bien, (rires) c'est en fait exactement ce que j'ai

184
00:10:45,070 --> 00:10:47,050
‫fait à partir des documentations de Stripe.

185
00:10:47,050 --> 00:10:50,320
‫Encore une fois, c'est vraiment comme ça que Stripe fonctionne,

186
00:10:50,320 --> 00:10:52,973
‫et nous ne pouvons rien faire contre cela.

187
00:10:54,350 --> 00:10:57,453
‫Quoi qu'il en soit, créons ensuite

188
00:10:59,310 --> 00:11:03,690
‫un événement Stripe, donc l'événement const est égal à stripe.

189
00:11:03,690 --> 00:11:07,410
‫Pour cela bien sûr, nous devons installer la bibliothèque

190
00:11:07,410 --> 00:11:09,573
‫Stripe, que nous avons ici.

191
00:11:12,650 --> 00:11:14,350
‫Alors, bande. webhooks. contructEvent.

192
00:11:20,378 --> 00:11:23,210
‫Maintenant, voici où finalement ce corps entre

193
00:11:23,210 --> 00:11:26,520
‫en jeu, alors demandez. corps.

194
00:11:26,520 --> 00:11:28,370
‫Et rappelez-vous que ce corps ici

195
00:11:28,370 --> 00:11:30,220
‫doit être sous sa forme brute,

196
00:11:30,220 --> 00:11:32,083
‫donc essentiellement disponible sous forme de chaîne.

197
00:11:33,130 --> 00:11:36,340
‫Encore une fois, c'est pourquoi nous avons mis cette route

198
00:11:36,340 --> 00:11:38,110
‫avant toutes nos autres

199
00:11:38,110 --> 00:11:41,580
‫routes et surtout avant que l'analyseur de corps puisse faire son

200
00:11:41,580 --> 00:11:44,863
‫travail de conversion de notre corps en un objet JSON.

201
00:11:46,170 --> 00:11:51,050
‫Ensuite, en plus de ce corps, pour l'événement, nous avons besoin d'une signature, donc

202
00:11:51,050 --> 00:11:53,370
‫essentiellement la signature qui a été

203
00:11:53,370 --> 00:11:56,763
‫envoyée avec l'en-tête, puis enfin notre secret de webhook.

204
00:11:57,710 --> 00:12:00,653
‫Récupérons cela d'ici, copiez-le.

205
00:12:01,585 --> 00:12:05,610
‫Comme c'est un secret, nous devrions, comme toujours, l'ajouter

206
00:12:05,610 --> 00:12:07,143
‫ici à notre

207
00:12:10,460 --> 00:12:12,737
‫fichier de configuration, donc STRIPE_WEBHOOK_SECRET.

208
00:12:16,650 --> 00:12:19,380
‫Et puis plus tard bien sûr, n'oubliez pas d'ajouter

209
00:12:19,380 --> 00:12:21,663
‫également cela à notre configuration Heroku.

210
00:12:26,100 --> 00:12:27,330
‫Utilisons maintenant cela.

211
00:12:27,330 --> 00:12:28,767
‫Ajouter un processus. env.

212
00:12:30,330 --> 00:12:31,830
‫J'aurais dû copier ça

213
00:12:35,690 --> 00:12:36,573
‫ici.

214
00:12:37,752 --> 00:12:41,200
‫Donc, vous voyez, tout cela est vraiment pour rendre

215
00:12:41,200 --> 00:12:43,450
‫le processus super, super sécurisé.

216
00:12:43,450 --> 00:12:45,970
‫Nous avons besoin de toutes ces données

217
00:12:45,970 --> 00:12:49,450
‫comme la signature et aussi le secret afin de valider essentiellement

218
00:12:49,450 --> 00:12:51,640
‫les données qui entrent dans le

219
00:12:51,640 --> 00:12:54,433
‫corps afin que personne ne puisse réellement les manipuler.

220
00:12:55,870 --> 00:12:58,050
‫Or lors de la création de cet événement,

221
00:12:58,050 --> 00:12:59,280
‫il peut y

222
00:12:59,280 --> 00:13:01,420
‫avoir des erreurs, par exemple si la

223
00:13:01,420 --> 00:13:03,900
‫signature est erronée ou si le secret est erroné.

224
00:13:03,900 --> 00:13:07,813
‫Et donc, enveloppons cela dans un bloc try-catch.

225
00:13:16,290 --> 00:13:17,850
‫D'accord.

226
00:13:17,850 --> 00:13:19,500
‫Bien sûr, nous avons maintenant besoin de la prise.

227
00:13:22,150 --> 00:13:23,410
‫En cas

228
00:13:23,410 --> 00:13:26,053
‫d'erreur, nous souhaitons renvoyer une erreur

229
00:13:27,880 --> 00:13:32,450
‫à Stripe, alors retournez res. status 400, puis utilisez simplement

230
00:13:33,756 --> 00:13:35,657
‫l'erreur d'envoi de

231
00:13:40,140 --> 00:13:44,023
‫webhook, puis ajoutons simplement l'erreur. message.

232
00:13:45,714 --> 00:13:49,220
‫C'est donc Stripe qui va recevoir cette réponse ici car

233
00:13:49,220 --> 00:13:53,230
‫encore une fois c'est Stripe qui va effectivement appeler l'URL, donc

234
00:13:53,230 --> 00:13:56,603
‫notre webhook, qui va ensuite appeler cette fonction.

235
00:13:58,520 --> 00:14:02,420
‫Maintenant, nous devons bien sûr également déclarer cet événement ici

236
00:14:02,420 --> 00:14:04,610
‫en dehors du bloc try-catch

237
00:14:04,610 --> 00:14:07,623
‫car sinon nous ne pourrons pas l'utiliser là-bas.

238
00:14:08,660 --> 00:14:13,160
‫Alors, laissez l'événement, puis réaffectez-le ici, car rappelez-vous que les

239
00:14:13,160 --> 00:14:15,430
‫const et let ES6 sont

240
00:14:15,430 --> 00:14:17,450
‫à portée de bloc.

241
00:14:17,450 --> 00:14:20,480
‫Et donc, cette variable ne serait pas disponible en dehors

242
00:14:20,480 --> 00:14:21,473
‫de ce bloc.

243
00:14:23,180 --> 00:14:25,830
‫Utilisons maintenant cet événement.

244
00:14:25,830 --> 00:14:29,090
‫Tout d'abord, nous devons tester si c'est vraiment l'événement que

245
00:14:29,090 --> 00:14:29,923
‫nous voulons.

246
00:14:30,810 --> 00:14:34,240
‫Donc, nous pouvons faire l'événement. type est égal à

247
00:14:34,240 --> 00:14:38,973
‫la caisse. session. Achevée.

248
00:14:42,080 --> 00:14:44,370
‫N'oubliez pas que dans notre tableau

249
00:14:44,370 --> 00:14:48,090
‫de bord Stripe, c'est exactement le type que nous avons défini ici.

250
00:14:48,090 --> 00:14:49,260
‫C'est donc le type d'événement.

251
00:14:49,260 --> 00:14:52,183
‫Maintenant, nous vérifions si c'est vraiment l'événement

252
00:14:52,183 --> 00:14:56,287
‫que nous recevons ici juste pour être sûr à 100%.

253
00:14:56,287 --> 00:14:59,780
‫Si c'est le cas, nous souhaitons alors réellement utiliser l'événement pour créer

254
00:14:59,780 --> 00:15:02,053
‫notre réservation dans notre base de données.

255
00:15:03,860 --> 00:15:06,280
‫En fait, faisons cela dans une fonction

256
00:15:06,280 --> 00:15:08,983
‫distincte et non à l'intérieur de tout ce gâchis.

257
00:15:10,517 --> 00:15:12,590
‫Pour cela, je vais créer une fonction.

258
00:15:12,590 --> 00:15:13,640
‫En fait, permettez-moi

259
00:15:13,640 --> 00:15:15,990
‫de lui donner exactement le même nom, alors créezBookingCheckout.

260
00:15:17,487 --> 00:15:19,490
‫C'était en fait un joli nom, mais

261
00:15:19,490 --> 00:15:21,450
‫maintenant il ne s'agit plus d'un

262
00:15:21,450 --> 00:15:23,250
‫middleware mais d'une simple fonction.

263
00:15:26,080 --> 00:15:28,823
‫Cette fonction acceptera les données de session.

264
00:15:31,080 --> 00:15:35,310
‫Et rappelez-vous que les données de session sont exactement cette session que nous

265
00:15:35,310 --> 00:15:37,513
‫avons créée ici en premier lieu.

266
00:15:41,404 --> 00:15:43,730
‫S'il s'agit du bon événement, appelons

267
00:15:43,730 --> 00:15:45,743
‫en fait cette fonction,

268
00:15:46,680 --> 00:15:49,500
‫donc créezBookingCheckout avec la session, qui est

269
00:15:49,500 --> 00:15:53,057
‫à l'événement. Les données. objet.

270
00:15:57,447 --> 00:15:58,320
‫Et

271
00:15:58,320 --> 00:16:01,333
‫enfin, renvoyons simplement une réponse à Stripe.

272
00:16:02,450 --> 00:16:03,840
‫Donc, le statut

273
00:16:05,780 --> 00:16:07,480
‫200, puis disons que certains

274
00:16:10,300 --> 00:16:11,823
‫json reçoivent la valeur true.

275
00:16:13,200 --> 00:16:14,033
‫Logique?

276
00:16:16,000 --> 00:16:18,490
‫Une fois de plus, tout ce

277
00:16:18,490 --> 00:16:21,390
‫code ici s'exécutera chaque fois qu'un paiement sera réussi.

278
00:16:21,390 --> 00:16:25,380
‫Stripe appellera alors notre webhook, qui est l'URL, qui

279
00:16:25,380 --> 00:16:27,420
‫va appeler cette fonction.

280
00:16:27,420 --> 00:16:30,600
‫Et ainsi, cette fonction reçoit un corps de la

281
00:16:30,600 --> 00:16:34,330
‫demande, puis, avec la signature et/ou le secret du webhook, crée

282
00:16:34,330 --> 00:16:37,110
‫un événement qui contiendra la session.

283
00:16:37,110 --> 00:16:39,190
‫Et puis en utilisant ces données de session,

284
00:16:39,190 --> 00:16:41,963
‫nous pouvons créer notre nouvelle réservation dans la base de données.

285
00:16:43,987 --> 00:16:45,660
‫Et donc, ce sera en fait assez similaire

286
00:16:45,660 --> 00:16:47,143
‫à ce que nous avions ici auparavant.

287
00:16:48,400 --> 00:16:51,790
‫Nous aurons donc à nouveau besoin de cette ligne de code.

288
00:16:51,790 --> 00:16:53,923
‫Donc, ce sera également une fonction asynchrone.

289
00:16:58,497 --> 00:17:00,530
‫Et donc, c'est exactement la même chose.

290
00:17:00,530 --> 00:17:02,260
‫Maintenant, ce dont nous avons

291
00:17:02,260 --> 00:17:06,690
‫besoin ici bien sûr, c'est d'avoir accès à la visite, à l'utilisateur et au prix.

292
00:17:06,690 --> 00:17:10,550
‫Mais ces données sont à nouveau stockées dans cette session.

293
00:17:10,550 --> 00:17:12,400
‫Alors, commençons par la tournée.

294
00:17:12,400 --> 00:17:14,780
‫Et rappelez-vous que lorsque nous avons créé

295
00:17:14,780 --> 00:17:17,100
‫cette fonction de gestionnaire pour

296
00:17:17,100 --> 00:17:20,040
‫la première fois, j'ai spécifié ce champ client_reference_id

297
00:17:20,040 --> 00:17:22,370
‫et ajouté le tourId à cela.

298
00:17:22,370 --> 00:17:23,840
‫Vous vous en souvenez ?

299
00:17:23,840 --> 00:17:25,700
‫Je l'ai fait parce qu'à l'époque,

300
00:17:25,700 --> 00:17:29,840
‫je savais déjà que nous aurions besoin de cet identifiant de tournée un peu plus tard.

301
00:17:29,840 --> 00:17:32,490
‫Maintenant, c'est à ce moment-là que nous avons réellement besoin

302
00:17:32,490 --> 00:17:35,333
‫de l'identifiant de la tournée afin de pouvoir créer cette nouvelle réservation.

303
00:17:36,732 --> 00:17:38,490
‫Et donc, maintenant, l'ID de tournée dont

304
00:17:38,490 --> 00:17:41,670
‫nous avons besoin est l'ID de référence du client de point de session.

305
00:17:41,670 --> 00:17:44,770
‫Alors, copions ceci et disons

306
00:17:47,870 --> 00:17:48,703
‫session.

307
00:17:49,660 --> 00:17:53,823
‫Et bien sûr, ici, nous devons dire tournée.

308
00:17:55,670 --> 00:17:57,040
‫Donc, c'est l'ID de la tournée.

309
00:17:57,040 --> 00:17:59,150
‫Ensuite, nous avons besoin de l'ID utilisateur.

310
00:17:59,150 --> 00:18:01,240
‫Maintenant, les informations que nous avons

311
00:18:01,240 --> 00:18:03,973
‫dans notre session sur l'utilisateur sont l'e-mail de l'utilisateur.

312
00:18:05,630 --> 00:18:07,170
‫Et donc, maintenant, ce

313
00:18:07,170 --> 00:18:10,500
‫que nous devons faire, c'est essentiellement obtenir l'ID de l'utilisateur.

314
00:18:10,500 --> 00:18:12,793
‫Pour cela, nous interrogerons par e-mail.

315
00:18:13,720 --> 00:18:16,810
‫Ce n'est pas un problème car l'e-mail est également unique.

316
00:18:16,810 --> 00:18:19,353
‫Sur cette base, nous pouvons alors trouver l'ID unique.

317
00:18:20,370 --> 00:18:24,183
‫Donc, l'utilisateur const est en attente.

318
00:18:25,570 --> 00:18:27,660
‫Et je pense que nous avons déjà l'utilisateur ici.

319
00:18:27,660 --> 00:18:28,493
‫Non?

320
00:18:29,520 --> 00:18:30,570
‫Non, en fait, je ne le fais pas.

321
00:18:31,890 --> 00:18:33,290
‫Alors, faisons-le ici.

322
00:18:35,490 --> 00:18:37,973
‫Et l'utilisateur ici aussi.

323
00:18:41,070 --> 00:18:41,903
‫D'accord.

324
00:18:41,903 --> 00:18:46,890
‫Alors, Utilisateur. findOne, puis interrogez par e-mail, qui est dans

325
00:18:47,990 --> 00:18:51,330
‫le point de session, et je pense que c'est l'e-mail du

326
00:18:51,330 --> 00:18:53,780
‫client ou quelque chose du genre.

327
00:18:55,200 --> 00:18:56,200
‫C'est client_email.

328
00:18:59,860 --> 00:19:00,693
‫D'accord.

329
00:19:02,070 --> 00:19:04,970
‫Mais cela renverra alors l'intégralité du document, mais

330
00:19:04,970 --> 00:19:06,910
‫nous voulons en fait l'ID.

331
00:19:06,910 --> 00:19:09,780
‫Alors, enveloppons tout cela ici entre

332
00:19:10,730 --> 00:19:14,743
‫parenthèses, puis appelons l'ID là-bas ou lisons réellement l'ID.

333
00:19:16,620 --> 00:19:17,960
‫Donc c'est tout.

334
00:19:17,960 --> 00:19:19,233
‫Et enfin, le prix.

335
00:19:22,350 --> 00:19:24,023
‫Où est stocké le prix ?

336
00:19:25,320 --> 00:19:26,833
‫Eh bien, c'est ici dans line_items.

337
00:19:27,880 --> 00:19:30,610
‫C'est un tableau, donc à l'élément

338
00:19:30,610 --> 00:19:33,553
‫zéro, puis le montant divisé par 100.

339
00:19:34,580 --> 00:19:38,210
‫Donc, nous l'avons multiplié ici par 100 pour obtenir des centimes,

340
00:19:38,210 --> 00:19:41,590
‫mais maintenant, bien sûr, nous voulons le récupérer en dollars.

341
00:19:41,590 --> 00:19:44,700
‫Donc, nous devons essentiellement diviser cela.

342
00:19:44,700 --> 00:19:48,550
‫Et donc, séance. line_items, puis

343
00:19:49,460 --> 00:19:54,460
‫le montant du premier élément si j'ai raison.

344
00:19:55,950 --> 00:19:56,783
‫Ouais.

345
00:19:56,783 --> 00:20:01,710
‫Donc, montant divisé par 100.

346
00:20:01,710 --> 00:20:04,010
‫Ça devrait être ça en fait.

347
00:20:04,010 --> 00:20:06,630
‫Engageons maintenant nos modifications dans le dépôt

348
00:20:06,630 --> 00:20:08,740
‫et transférons-les vers Stripe.

349
00:20:08,740 --> 00:20:12,840
‫Donc, git add all, bien

350
00:20:12,840 --> 00:20:16,600
‫sûr, puis git commit message

351
00:20:18,090 --> 00:20:21,633
‫Implémentation améliorée de

352
00:20:24,960 --> 00:20:29,960
‫stripe, puis git push heroku master.

353
00:20:31,190 --> 00:20:33,273
‫Encore une fois, cela prendra du temps.

354
00:20:33,273 --> 00:20:35,263
‫Je te verrai quand ce sera fait.

355
00:20:36,200 --> 00:20:37,033
‫Très bien.

356
00:20:37,033 --> 00:20:40,323
‫Maintenant, n'oubliez pas de définir cette nouvelle variable d'environnement.

357
00:20:41,610 --> 00:20:46,610
‫Donc, c'est le jeu de deux-points de la configuration heroku, puis

358
00:20:46,750 --> 00:20:49,433
‫copiez-le simplement à partir d'ici.

359
00:20:53,590 --> 00:20:54,720
‫D'accord.

360
00:20:54,720 --> 00:20:56,800
‫Cela redémarre ensuite l'application.

361
00:20:56,800 --> 00:20:58,173
‫Et c'est tout.

362
00:20:59,570 --> 00:21:02,723
‫Alors, allons-y maintenant et testons-le.

363
00:21:04,980 --> 00:21:05,813
‫Très bien.

364
00:21:07,050 --> 00:21:09,480
‫Nous sommes toujours là dans notre application.

365
00:21:09,480 --> 00:21:12,883
‫Voyons quelles visites Laura a déjà réservées.

366
00:21:14,100 --> 00:21:15,370
‫Elle a le Forest Hiker.

367
00:21:15,370 --> 00:21:19,823
‫Cette réservation était toujours effectuée selon l'ancienne méthode.

368
00:21:21,050 --> 00:21:24,240
‫Mais cette ancienne méthode ne fonctionne plus.

369
00:21:24,240 --> 00:21:27,047
‫Maintenant, si nous effectuons une autre réservation

370
00:21:27,047 --> 00:21:29,490
‫et que cela fonctionne, eh bien,

371
00:21:29,490 --> 00:21:32,773
‫cela signifiera bien sûr que notre nouvelle implémentation fonctionne.

372
00:21:34,730 --> 00:21:35,780
‫Testons cela ici.

373
00:21:39,760 --> 00:21:41,493
‫Comme toujours, 4242.

374
00:21:50,420 --> 00:21:51,683
‫Attendons maintenant.

375
00:21:52,730 --> 00:21:55,740
‫Eh bien, cela ne s'est apparemment pas très bien

376
00:21:55,740 --> 00:21:58,520
‫passé car sinon notre deuxième nouvelle tournée devrait

377
00:21:58,520 --> 00:22:00,743
‫déjà être ici dans nos réservations.

378
00:22:02,230 --> 00:22:04,203
‫Voyons ici dans notre tableau de bord.

379
00:22:05,860 --> 00:22:06,983
‫Si nous rechargeons

380
00:22:12,150 --> 00:22:15,893
‫maintenant cela, nous voyons en fait qu'il y a eu un événement réussi.

381
00:22:17,407 --> 00:22:20,320
‫Donc, c'est l'événement que nous venons de créer

382
00:22:20,320 --> 00:22:23,170
‫et qui a envoyé ce corps ici et

383
00:22:23,170 --> 00:22:25,380
‫a ensuite reçu cette réponse.

384
00:22:25,380 --> 00:22:27,560
‫Donc, cette réception définie sur true est

385
00:22:27,560 --> 00:22:30,663
‫exactement ce que nous avons fait ici dans notre code,

386
00:22:31,670 --> 00:22:32,633
‫donc ceci ici.

387
00:22:34,060 --> 00:22:36,000
‫Donc, c'est la réponse que nous

388
00:22:36,000 --> 00:22:39,770
‫avons envoyée et le corps que nous avons reçu était toutes ces données.

389
00:22:39,770 --> 00:22:42,810
‫Et donc, on peut voir ici la

390
00:22:42,810 --> 00:22:46,460
‫séance avec le prix, avec l'email, avec la tournée.

391
00:22:46,460 --> 00:22:49,483
‫Et donc, je ne sais pas pourquoi cela n'a pas fonctionné.

392
00:22:51,000 --> 00:22:53,163
‫Alors, rechargeons rapidement ceci ici.

393
00:22:55,780 --> 00:22:59,050
‫Donc, en fait, notre implémentation Stripe devrait être correcte, mais, pour une

394
00:22:59,050 --> 00:23:02,013
‫raison quelconque, notre nouvelle réservation n'a pas été créée.

395
00:23:03,120 --> 00:23:05,020
‫Vérifions cela également ici dans Compass.

396
00:23:07,460 --> 00:23:09,970
‫Et effectivement, il n'y est pas.

397
00:23:09,970 --> 00:23:12,123
‫Alors, revenons à notre code ici.

398
00:23:13,410 --> 00:23:17,360
‫Oh et une erreur que je vois tout de suite est ici.

399
00:23:17,360 --> 00:23:20,393
‫Donc, il devrait être terminé comme ceci.

400
00:23:22,090 --> 00:23:24,480
‫Alors, c'est une erreur stupide.

401
00:23:24,480 --> 00:23:26,950
‫Voyons simplement s'il peut y

402
00:23:26,950 --> 00:23:30,050
‫avoir une autre erreur ici dans createBookingCheckout.

403
00:23:30,050 --> 00:23:30,883
‫Ici, nous

404
00:23:32,750 --> 00:23:33,583
‫avons line_items.

405
00:23:33,583 --> 00:23:35,093
‫Voyons si c'est correct.

406
00:23:36,110 --> 00:23:38,170
‫Et oui, il semble être.

407
00:23:38,170 --> 00:23:41,123
‫Nous pouvons également le confirmer ici encore dans notre Stripe.

408
00:23:43,110 --> 00:23:45,290
‫En fait, ici, cela s'appelle display_items.

409
00:23:46,590 --> 00:23:47,423
‫C'est bizarre.

410
00:23:48,367 --> 00:23:52,140
‫Juste pour être sûr, appelons-le également display_items ici

411
00:23:52,140 --> 00:23:54,363
‫dans notre code ici.

412
00:23:55,980 --> 00:23:57,580
‫Maintenant, une autre chose que j'ai remarquée

413
00:23:58,750 --> 00:24:00,350
‫alors que je jetais un autre

414
00:24:00,350 --> 00:24:03,510
‫coup d'œil ici, c'est que nous avons toujours cette image codée en dur

415
00:24:03,510 --> 00:24:05,763
‫pour cet autre natours. dév.

416
00:24:07,587 --> 00:24:11,380
‫Maintenant, corrigeons cela car à ce stade, bien sûr, notre

417
00:24:11,380 --> 00:24:14,580
‫site Web est déjà en ligne et déployé.

418
00:24:14,580 --> 00:24:16,600
‫Et donc, nous pouvons essentiellement remplacer cela par le

419
00:24:16,600 --> 00:24:18,100
‫même que nous avons ici.

420
00:24:20,900 --> 00:24:23,430
‫Donc, nous utilisons cette partie ici plusieurs fois.

421
00:24:23,430 --> 00:24:25,480
‫Et donc, il est temps de l'utiliser à nouveau ici.

422
00:24:32,672 --> 00:24:33,505
‫Ouais.

423
00:24:33,505 --> 00:24:35,353
‫Essayons de redéployer cela.

424
00:24:36,380 --> 00:24:38,113
‫Alors, git ajoute tout à nouveau.

425
00:24:40,420 --> 00:24:42,070
‫Et appelons simplement cela

426
00:24:42,070 --> 00:24:44,430
‫ici Implémentation de bande améliorée deux.

427
00:24:44,430 --> 00:24:47,693
‫Et puis poussez-le à nouveau vers Heroku.

428
00:24:51,580 --> 00:24:52,560
‫D'accord.

429
00:24:52,560 --> 00:24:54,253
‫Essayons encore une fois.

430
00:24:55,830 --> 00:24:57,023
‫Revenons ici.

431
00:25:00,630 --> 00:25:04,063
‫Essayons maintenant de réserver à nouveau à Park Camper.

432
00:25:15,760 --> 00:25:16,683
‫Très bien.

433
00:25:17,920 --> 00:25:21,530
‫Vous devriez voir l'image apparaître ici sur le côté gauche.

434
00:25:21,530 --> 00:25:24,200
‫Cela signifie que notre nouvelle intégration d'images a

435
00:25:24,200 --> 00:25:25,753
‫également très bien fonctionné.

436
00:25:27,220 --> 00:25:28,283
‫Maintenant, c'est le traitement.

437
00:25:29,382 --> 00:25:31,380
‫Ah maintenant c'est ici.

438
00:25:31,380 --> 00:25:32,320
‫Super.

439
00:25:32,320 --> 00:25:33,533
‫C'est beau.

440
00:25:34,420 --> 00:25:36,850
‫Maintenant, nous avons vraiment une implémentation

441
00:25:36,850 --> 00:25:39,940
‫Stripe sécurisée et beaucoup plus professionnelle dans

442
00:25:39,940 --> 00:25:41,173
‫notre application.

443
00:25:42,070 --> 00:25:43,520
‫C'est génial.

444
00:25:43,520 --> 00:25:45,570
‫Bien sûr, si vous

445
00:25:45,570 --> 00:25:49,500
‫rechargez ici, alors vous devriez voir ce nouvel événement ici, donc

446
00:25:49,500 --> 00:25:52,050
‫ce nouvel appel à notre webhook, qui

447
00:25:52,050 --> 00:25:54,593
‫bien sûr a encore une fois réussi.

448
00:25:55,840 --> 00:25:57,690
‫C'est juste génial.

449
00:25:57,690 --> 00:26:00,740
‫Maintenant, il y a juste une dernière chose que je

450
00:26:00,740 --> 00:26:04,420
‫veux faire, qui est essentiellement de donner à l'utilisateur des commentaires sous la

451
00:26:04,420 --> 00:26:06,980
‫forme d'un de ces messages verts que nous utilisons

452
00:26:06,980 --> 00:26:09,123
‫également par exemple dans la connexion.

453
00:26:10,650 --> 00:26:12,930
‫À l'heure actuelle, notre application ne

454
00:26:12,930 --> 00:26:16,476
‫donne pas vraiment de retour lorsqu'une nouvelle visite a été réservée.

455
00:26:16,476 --> 00:26:18,650
‫Maintenant, je veux changer cela.

456
00:26:18,650 --> 00:26:21,900
‫Cependant, faire cela n'est pas vraiment simple car

457
00:26:21,900 --> 00:26:23,990
‫rappelez-vous que ces messages

458
00:26:23,990 --> 00:26:26,750
‫sont en fait affichés par JavaScript.

459
00:26:26,750 --> 00:26:30,280
‫Donc, dans les autres cas, nous avons fait un appel HTTP à notre API.

460
00:26:30,280 --> 00:26:33,070
‫Et puis, lorsque cela a été fait, nous avons utilisé JavaScript

461
00:26:33,070 --> 00:26:34,840
‫pour afficher une sorte de message.

462
00:26:34,840 --> 00:26:36,970
‫Mais maintenant, nous ne le faisons pas de cette façon.

463
00:26:36,970 --> 00:26:40,710
‫Et donc, le message devrait déjà se trouver quelque part dans le

464
00:26:40,710 --> 00:26:42,380
‫HTML dès que la page

465
00:26:42,380 --> 00:26:45,400
‫se charge afin que notre JavaScript puisse alors récupérer

466
00:26:45,400 --> 00:26:49,070
‫ce message dans le HTML et l'afficher joliment là-haut dans l'une

467
00:26:49,070 --> 00:26:50,463
‫de ces bannières.

468
00:26:51,610 --> 00:26:54,510
‫Et donc, la façon dont je vais mettre ces alertes

469
00:26:54,510 --> 00:26:58,223
‫dans le HTML est encore une fois en utilisant une propriété de données.

470
00:26:59,450 --> 00:27:03,000
‫Commençons par implémenter cette fonctionnalité directement dans notre

471
00:27:03,000 --> 00:27:04,363
‫modèle principal.

472
00:27:06,610 --> 00:27:09,273
‫C'est ici dans les vues, base.

473
00:27:11,160 --> 00:27:13,630
‫Je vais en fait ajouter ce message

474
00:27:13,630 --> 00:27:15,663
‫d'alerte directement sur l'élément body.

475
00:27:17,110 --> 00:27:19,963
‫Ici, nous aurons une propriété d'alerte de données, qui

476
00:27:21,860 --> 00:27:24,000
‫ne devrait en fait être définie

477
00:27:24,000 --> 00:27:26,563
‫que si la variable d'alerte est disponible ici.

478
00:27:27,480 --> 00:27:31,460
‫Alors, utilisons ES6, donc une chaîne de modèle, et

479
00:27:31,460 --> 00:27:35,060
‫disons s'il y a une alerte, alors

480
00:27:35,060 --> 00:27:38,713
‫utilisons alert ici, et sinon, une chaîne vide.

481
00:27:39,980 --> 00:27:43,370
‫Et donc, cette alerte ici sera le message

482
00:27:43,370 --> 00:27:47,230
‫d'alerte que JavaScript va ensuite récupérer et afficher sur la page.

483
00:27:47,230 --> 00:27:50,230
‫Maintenant, comment ce message d'alerte se retrouve-t-il alors en tant que

484
00:27:50,230 --> 00:27:52,513
‫variable d'alerte ici dans notre modèle ?

485
00:27:53,360 --> 00:27:56,448
‫Eh bien, j'ai trouvé une solution réutilisable afin que

486
00:27:56,448 --> 00:27:59,250
‫nous puissions l'utiliser dans toute notre application.

487
00:27:59,250 --> 00:28:01,840
‫C'est-à-dire que sur la chaîne de requête, nous

488
00:28:01,840 --> 00:28:03,890
‫ajouterons un mot-clé d'alerte, puis nous

489
00:28:03,890 --> 00:28:05,820
‫aurons un middleware, qui prendra

490
00:28:05,820 --> 00:28:08,560
‫ce mot-clé de l'URL et, selon le mot-clé que

491
00:28:08,560 --> 00:28:10,910
‫nous y avons mis, mettra alors tout

492
00:28:10,910 --> 00:28:15,050
‫un message d'alerte en réponse. . des locaux.

493
00:28:15,050 --> 00:28:19,000
‫Et donc, rappelez-vous que tout ce qui est en réponse. locaux est alors disponible

494
00:28:19,000 --> 00:28:22,483
‫en tant que variable dans tous nos modèles.

495
00:28:23,450 --> 00:28:25,630
‫Donc, nous l'avons utilisé auparavant dans

496
00:28:25,630 --> 00:28:27,563
‫notre authController, je crois.

497
00:28:29,480 --> 00:28:32,567
‫Très rapidement, permettez-moi de vous le montrer.

498
00:28:33,530 --> 00:28:37,060
‫Ici, nous avons dit réponse. local. user et

499
00:28:37,060 --> 00:28:39,074
‫y mettre l'utilisateur actuel.

500
00:28:39,074 --> 00:28:41,720
‫Ensuite, automatiquement dans tous les modèles, nous

501
00:28:41,720 --> 00:28:44,283
‫avons accès à cette variable utilisateur.

502
00:28:47,430 --> 00:28:50,070
‫Alors, implémentons maintenant ce que je viens

503
00:28:50,070 --> 00:28:52,597
‫de dire et commençons par l'URL.

504
00:28:54,330 --> 00:28:57,540
‫Ce que je vais faire ici, c'est en fait ajouter cette chaîne de

505
00:28:57,540 --> 00:28:59,097
‫requête ici à l'URL de réussite.

506
00:28:59,970 --> 00:29:04,573
‫Ici, je dirai alerte égale réservation.

507
00:29:05,970 --> 00:29:10,310
‫Maintenant, je pourrais, dans toutes les autres URL, également ajouter une alerte, puis

508
00:29:10,310 --> 00:29:12,863
‫avec un mot-clé différent ici, bien sûr.

509
00:29:14,350 --> 00:29:18,100
‫Et nous allons le faire ici vraiment pour cette réservation.

510
00:29:18,100 --> 00:29:21,793
‫Mais encore une fois, j'ai créé une sorte de solution réutilisable ici.

511
00:29:23,340 --> 00:29:27,470
‫Quoi qu'il en soit, maintenant dans nos routes, nous avons besoin essentiellement d'un

512
00:29:27,470 --> 00:29:29,920
‫middleware, qui fonctionnera pour toutes les requêtes.

513
00:29:29,920 --> 00:29:32,270
‫Et c'est ce middleware, qui va récupérer l'alerte

514
00:29:32,270 --> 00:29:35,240
‫de la chaîne de requête et mettre un message d'alerte

515
00:29:35,240 --> 00:29:37,453
‫sur notre réponse. des locaux.

516
00:29:41,457 --> 00:29:42,624
‫Alors, routeur.

517
00:29:45,040 --> 00:29:48,233
‫utilisez viewsController. alertes.

518
00:29:50,290 --> 00:29:52,320
‫Et donc, il s'agit d'une fonction

519
00:29:52,320 --> 00:29:56,200
‫middleware, qui s'exécutera essentiellement pour chaque demande unique qui entre dans

520
00:29:56,200 --> 00:29:58,130
‫ce routeur, donc essentiellement

521
00:29:58,130 --> 00:30:01,063
‫pour toutes les demandes adressées à notre site Web.

522
00:30:02,370 --> 00:30:04,870
‫Créons maintenant ce middleware dans

523
00:30:04,870 --> 00:30:06,020
‫notre viewsController.

524
00:30:10,460 --> 00:30:12,380
‫Donc, les exportations. demande

525
00:30:14,480 --> 00:30:17,283
‫d'alertes, réponse et suivant.

526
00:30:19,650 --> 00:30:20,730
‫Et donc,

527
00:30:22,760 --> 00:30:26,300
‫l'alerte est demande. requete. alerte.

528
00:30:26,300 --> 00:30:29,873
‫Et donc, utilisons encore une fois cette structuration.

529
00:30:32,020 --> 00:30:36,553
‫Et puis disons que si l'alerte est égale à la réservation, donc l'alerte

530
00:30:39,030 --> 00:30:42,653
‫que nous mettons ici dans la chaîne de requête, eh

531
00:30:44,670 --> 00:30:46,070
‫bien, dans ce

532
00:30:46,070 --> 00:30:50,970
‫cas, disons la réponse. des locaux. alerte

533
00:30:52,830 --> 00:30:57,970
‫sera votre réservation réussie,

534
00:30:59,850 --> 00:31:06,883
‫veuillez vérifier votre e-mail pour une confirmation.

535
00:31:10,330 --> 00:31:13,090
‫Et nous devrions également ajouter une

536
00:31:13,090 --> 00:31:17,960
‫autre phrase, qui est celle-ci, si votre réservation ne le fait

537
00:31:24,070 --> 00:31:27,743
‫pas, sélectionnez-la, n'apparaît pas ici immédiatement, veuillez revenir

538
00:31:33,270 --> 00:31:34,523
‫plus tard.

539
00:31:36,140 --> 00:31:37,230
‫Et cette

540
00:31:37,230 --> 00:31:39,920
‫dernière partie est due au fait que Stripe

541
00:31:39,920 --> 00:31:43,620
‫dit très spécifiquement dans sa documentation que parfois le webhook est

542
00:31:43,620 --> 00:31:46,880
‫appelé un peu après l'appel de l'URL de réussite.

543
00:31:46,880 --> 00:31:49,810
‫Dans ce cas, cette URL de réussite afficherait alors

544
00:31:49,810 --> 00:31:52,677
‫toutes les visites en cours, mais seulement après cela,

545
00:31:52,677 --> 00:31:54,300
‫le webhook serait appelé

546
00:31:54,300 --> 00:31:57,270
‫et la visite serait créée dans notre base de données.

547
00:31:57,270 --> 00:32:00,040
‫Par conséquent, la nouvelle réservation n'apparaîtrait pas immédiatement

548
00:32:00,040 --> 00:32:01,953
‫sur la page Mes réservations.

549
00:32:02,850 --> 00:32:06,220
‫Mais bien sûr, tout fonctionnait encore bien dans ce cas.

550
00:32:06,220 --> 00:32:09,583
‫Et donc, je recharge simplement, mais plus tard, nous réglerons ce problème.

551
00:32:12,340 --> 00:32:15,080
‫Il ne nous reste plus qu'à appeler le prochain middleware.

552
00:32:15,080 --> 00:32:17,160
‫Et c'est en fait ça.

553
00:32:17,160 --> 00:32:21,390
‫Encore une fois, nous n'avons fait cela ici que pour une alerte égale

554
00:32:21,390 --> 00:32:24,090
‫à une réservation, mais nous pouvons maintenant l'utiliser

555
00:32:24,090 --> 00:32:27,070
‫partout sur notre site Web en définissant différents mots-clés

556
00:32:27,070 --> 00:32:28,982
‫d'alerte et chaînes de requête.

557
00:32:28,982 --> 00:32:33,982
‫Avec cela, nous mettons ce message ici sur res. des locaux. alerte.

558
00:32:35,600 --> 00:32:38,940
‫Encore une fois, notre modèle de base le

559
00:32:38,940 --> 00:32:42,320
‫récupérera et l'affichera ici dans cette propriété d'alerte de données.

560
00:32:42,320 --> 00:32:46,440
‫Et donc, il ne reste plus qu'à aller dans notre index. js et lisez

561
00:32:46,440 --> 00:32:49,890
‫l'alerte à partir d'ici, puis affichez-la.

562
00:32:49,890 --> 00:32:52,100
‫Et donc, cela devrait être assez facile.

563
00:32:52,100 --> 00:32:56,230
‫Ici en public, faisons-le correctement dans l'index.

564
00:32:56,230 --> 00:33:00,260
‫Et la première chose est que nous devons en fait importer la

565
00:33:00,260 --> 00:33:01,343
‫fonction d'alertes.

566
00:33:06,480 --> 00:33:08,160
‫Ce n'est pas une application.

567
00:33:08,160 --> 00:33:09,343
‫C'est ici dans l'index.

568
00:33:10,920 --> 00:33:12,090
‫D'accord.

569
00:33:12,090 --> 00:33:15,883
‫Et puis ici, lisons essentiellement cette alerte.

570
00:33:17,290 --> 00:33:22,133
‫Ainsi, const alertMessage, disons, est un

571
00:33:23,250 --> 00:33:25,320
‫document. querySelector, puis l'élément body,

572
00:33:28,742 --> 00:33:31,327
‫ensemble de données de points. alerte.

573
00:33:35,350 --> 00:33:37,673
‫Et donc, seulement s'il y a

574
00:33:39,760 --> 00:33:42,020
‫une alerte, bien sûr, alors affichez

575
00:33:43,160 --> 00:33:44,250
‫l'alerte avec

576
00:33:45,840 --> 00:33:48,000
‫succès et le message d'alerte.

577
00:33:48,000 --> 00:33:50,640
‫Et maintenant, cette petite chose que je veux

578
00:33:50,640 --> 00:33:54,630
‫faire est de changer un peu cette fonction showAlert ici parce que nous

579
00:33:54,630 --> 00:33:57,210
‫avons en fait beaucoup de texte maintenant.

580
00:33:57,210 --> 00:33:59,780
‫Et l'heure standard à laquelle l'alerte est

581
00:33:59,780 --> 00:34:03,163
‫affichée ne serait pas suffisante pour réellement lire tout le texte.

582
00:34:04,210 --> 00:34:06,880
‫Donc, vous voyez ici qu'au bout de cinq

583
00:34:06,880 --> 00:34:08,373
‫secondes, l'alerte est masquée.

584
00:34:10,126 --> 00:34:11,760
‫Permettons en fait à l'utilisateur de

585
00:34:11,760 --> 00:34:14,253
‫spécifier le nombre de secondes pendant lesquelles l'alerte est affichée.

586
00:34:16,810 --> 00:34:20,320
‫Nous le ferons par défaut de cinq secondes.

587
00:34:20,320 --> 00:34:24,810
‫Ici, nous faisons simplement le temps multiplié par 1 000 pour

588
00:34:24,810 --> 00:34:26,483
‫le convertir en millisecondes.

589
00:34:27,976 --> 00:34:30,690
‫Ainsi, toutes les fonctions fonctionneront partout

590
00:34:30,690 --> 00:34:32,270
‫en cinq secondes.

591
00:34:32,270 --> 00:34:34,790
‫Faisons en fait sept secondes si

592
00:34:34,790 --> 00:34:36,600
‫nous ne spécifions rien.

593
00:34:36,600 --> 00:34:39,980
‫Mais si nous le voulons, nous pouvons alors outrepasser ce sept.

594
00:34:39,980 --> 00:34:42,040
‫Et donc, je vais le faire

595
00:34:42,040 --> 00:34:45,370
‫maintenant ici et le mettre en fait 20 secondes sur l'écran.

596
00:34:45,370 --> 00:34:46,203
‫Très bien.

597
00:34:47,360 --> 00:34:49,240
‫Je pense que ça devrait être ça.

598
00:34:49,240 --> 00:34:51,060
‫J'espère que cela avait du sens.

599
00:34:51,060 --> 00:34:53,993
‫Compilons maintenant très rapidement notre bundle.

600
00:34:55,360 --> 00:35:00,343
‫C'est npm run build, puis appuyez sur la saisie semi-automatique.

601
00:35:03,480 --> 00:35:05,990
‫Cela prend aussi un peu de temps.

602
00:35:05,990 --> 00:35:07,373
‫Mais maintenant c'est fait.

603
00:35:12,030 --> 00:35:14,340
‫Déployons-le maintenant une dernière fois en espérant

604
00:35:15,580 --> 00:35:17,083
‫qu'il fonctionne réellement.

605
00:35:18,250 --> 00:35:19,083
‫Alors, git commit.

606
00:35:25,840 --> 00:35:27,513
‫Alors, les messages Stripe.

607
00:35:29,670 --> 00:35:34,670
‫Et une dernière fois, git push heroku master.

608
00:35:37,451 --> 00:35:41,403
‫Testons-le maintenant en achetant encore une autre tournée ici.

609
00:35:42,830 --> 00:35:44,963
‫Prenons le City Wanderer cette fois.

610
00:35:46,490 --> 00:35:49,683
‫Oh je viens de voir qu'il y a déjà un message ici.

611
00:35:50,810 --> 00:35:51,783
‫Ce n'est pas bon.

612
00:35:54,530 --> 00:35:58,500
‫Et vous voyez qu'il a disparu au bout de 20 secondes.

613
00:35:58,500 --> 00:36:00,240
‫Donc, il semble que maintenant,

614
00:36:00,240 --> 00:36:02,993
‫par défaut, il mettra toujours cette classe d'alerte ici.

615
00:36:06,028 --> 00:36:06,861
‫(rires)

616
00:36:06,861 --> 00:36:07,694
‫Ouais.

617
00:36:07,694 --> 00:36:09,990
‫C'est parce qu'ici il devrait être alertMessage et

618
00:36:09,990 --> 00:36:11,063
‫pas seulement alert.

619
00:36:12,810 --> 00:36:16,800
‫Mais de toute façon, testons maintenant si le message

620
00:36:16,800 --> 00:36:20,433
‫est correct lorsque nous réservons la visite.

621
00:36:24,410 --> 00:36:25,243
‫D'accord.

622
00:36:32,470 --> 00:36:34,880
‫Attendons maintenant.

623
00:36:34,880 --> 00:36:36,330
‫Nous y voilà.

624
00:36:36,330 --> 00:36:39,163
‫En effet, il y a notre message.

625
00:36:40,130 --> 00:36:41,460
‫Si beau.

626
00:36:41,460 --> 00:36:44,420
‫De plus, notre tournée apparaît ici.

627
00:36:44,420 --> 00:36:48,510
‫Et vous voyez qu'il reste vraiment ici pendant beaucoup de temps.

628
00:36:48,510 --> 00:36:49,853
‫Donc, ça marche aussi.

629
00:36:51,532 --> 00:36:52,832
‫Allons très vite...

630
00:36:55,840 --> 00:36:59,383
‫Et d'abord, nous devons en fait reconstruire le bundle ici.

631
00:37:03,877 --> 00:37:07,170
‫Ensuite, nous pouvons tout ajouter à

632
00:37:13,580 --> 00:37:18,490
‫notre zone de transit, correction de bogue d'alerte de message.

633
00:37:18,490 --> 00:37:19,670
‫Donc, ce

634
00:37:19,670 --> 00:37:23,500
‫sont déjà (rires) des messages à consonance vraiment professionnelle ici.

635
00:37:23,500 --> 00:37:26,313
‫Maintenant, une dernière poussée vers Heroku.

636
00:37:29,670 --> 00:37:32,580
‫Maintenant, lorsque nous chargeons notre page, nous ne

637
00:37:32,580 --> 00:37:34,740
‫devrions voir aucun message d'alerte.

638
00:37:34,740 --> 00:37:37,250
‫Et en effet, maintenant tout est propre.

639
00:37:37,250 --> 00:37:40,470
‫Et donc, je peux maintenant dire qu'au moins pour

640
00:37:40,470 --> 00:37:42,977
‫l'instant, ce projet est vraiment terminé.

641
00:37:42,977 --> 00:37:46,490
‫Encore une fois, excellent travail, félicitations et bravo

642
00:37:46,490 --> 00:37:51,100
‫d'être probablement l'une des rares personnes à aller jusqu'au bout du

643
00:37:51,100 --> 00:37:54,350
‫projet et à vraiment construire ce magnifique

644
00:37:54,350 --> 00:37:58,370
‫site Web et également une API que vous pouvez

645
00:37:58,370 --> 00:38:01,780
‫maintenant mettre sur votre portfolio et montrer

646
00:38:01,780 --> 00:38:02,923
‫au monde.