1 00:00:01,010 --> 00:00:03,730 ‫Dosen: Dan sekarang untuk menyelesaikan proyek 2 00:00:03,730 --> 00:00:06,593 ‫ini, mari selesaikan integrasi Stripe ini dengan webhook. 3 00:00:09,310 --> 00:00:12,040 ‫Mari kita mulai mengingat bagaimana integrasi Stripe 4 00:00:12,040 --> 00:00:14,210 ‫kita bekerja saat ini. 5 00:00:14,210 --> 00:00:16,750 ‫Kami memiliki titik akhir sesi 6 00:00:16,750 --> 00:00:19,540 ‫checkout ini, yang dipanggil dari front-end kami. 7 00:00:19,540 --> 00:00:22,293 ‫Ini kemudian akan memanggil fungsi getCheckoutSession, jadi pada 8 00:00:23,440 --> 00:00:25,100 ‫dasarnya yang ini 9 00:00:25,100 --> 00:00:28,180 ‫di sini, yang akan membuat sesi checkout di server 10 00:00:28,180 --> 00:00:30,300 ‫menggunakan semua informasi ini di sini, 11 00:00:30,300 --> 00:00:32,750 ‫dan kemudian mengirimkannya kembali ke klien. 12 00:00:32,750 --> 00:00:35,170 ‫Kemudian setelah proses pembayaran berhasil 13 00:00:35,170 --> 00:00:37,280 ‫dilakukan oleh Stripe, kemudian redirect 14 00:00:37,280 --> 00:00:40,990 ‫pengguna ke URL sukses ini, jadi ini yang 15 00:00:40,990 --> 00:00:42,483 ‫kami buat. 16 00:00:44,210 --> 00:00:48,120 ‫Ingat bahwa ke URL ini, kami menambahkan ID tur, 17 00:00:48,120 --> 00:00:50,920 ‫ID pengguna, dan juga harganya. 18 00:00:50,920 --> 00:00:55,040 ‫Kami melakukannya sehingga setelah URL ini dipanggil, aplikasi 19 00:00:55,040 --> 00:00:57,920 ‫kami akan membuat dokumen pemesanan baru 20 00:00:57,920 --> 00:00:59,680 ‫di database kami. 21 00:00:59,680 --> 00:01:01,047 ‫Bagaimana itu berhasil? 22 00:01:01,047 --> 00:01:04,743 ‫Di rute my-tours, kami memiliki middleware untuk itu. 23 00:01:06,040 --> 00:01:09,940 ‫Ingat, di sini, di viewRoutes, di tur saya, 24 00:01:09,940 --> 00:01:12,467 ‫kami memiliki createBookingCheckout ini. 25 00:01:14,770 --> 00:01:18,628 ‫Fungsi ini di sini, yang pada dasarnya dari kueri 26 00:01:18,628 --> 00:01:21,440 ‫mengambil tur, pengguna, dan harga, 27 00:01:21,440 --> 00:01:25,023 ‫dan membuat entri dalam database menggunakan data tersebut. 28 00:01:26,350 --> 00:01:29,160 ‫Pada dasarnya kami menempatkan data ini 29 00:01:29,160 --> 00:01:32,500 ‫di URL setiap kali Stripe berhasil memproses pembayaran. 30 00:01:32,500 --> 00:01:34,990 ‫Dan kemudian fungsi middleware yang kami miliki 31 00:01:34,990 --> 00:01:38,570 ‫di sini mengambil data dan membuat pemesanan baru di sistem kami 32 00:01:38,570 --> 00:01:39,960 ‫menggunakan data tersebut. 33 00:01:39,960 --> 00:01:42,790 ‫Dan kemudian setelah itu, pada dasarnya kami mengarahkan 34 00:01:42,790 --> 00:01:45,763 ‫ulang ke sini ke URL asli tanpa string kueri. 35 00:01:46,770 --> 00:01:50,150 ‫Sekarang masalah dengan ini adalah bahwa itu tidak benar-benar aman. 36 00:01:50,150 --> 00:01:52,963 ‫Jadi, semua orang yang mengetahui struktur URL 37 00:01:54,010 --> 00:01:57,670 ‫ini, jadi yang ini, tur, pengguna, dan harga mana dalam 38 00:01:57,670 --> 00:02:00,700 ‫string kueri, pada dasarnya dapat membuat pemesanan di 39 00:02:01,761 --> 00:02:03,850 ‫sistem kami tanpa benar-benar membayar. 40 00:02:03,850 --> 00:02:07,120 ‫Jadi, yang harus kita lakukan adalah membuka URL ini 41 00:02:07,120 --> 00:02:08,500 ‫dengan beberapa data 42 00:02:08,500 --> 00:02:11,680 ‫di sana dan kemudian dari sana secara otomatis 43 00:02:11,680 --> 00:02:14,193 ‫membuat pemesanan tanpa melalui proses Stripe. 44 00:02:15,540 --> 00:02:18,630 ‫Ingat bagaimana saat itu saya mengatakan bahwa kami akan 45 00:02:18,630 --> 00:02:20,853 ‫memperbaikinya menggunakan sesuatu yang disebut webhooks. 46 00:02:22,090 --> 00:02:23,120 ‫Jadi, kita lakukan itu sekarang. 47 00:02:23,120 --> 00:02:24,090 ‫Karena untuk 48 00:02:24,090 --> 00:02:27,140 ‫itu, sebenarnya kita membutuhkan website kita untuk di-deploy. 49 00:02:27,140 --> 00:02:29,350 ‫Sekarang pada titik ini, itulah yang sebenarnya terjadi. 50 00:02:29,350 --> 00:02:31,833 ‫Jadi, sekarang kita bisa mengimplementasikan webhook ini. 51 00:02:33,240 --> 00:02:35,663 ‫Untuk itu, mari buka dasbor Stripe kami. 52 00:02:37,400 --> 00:02:39,750 ‫Dan saya sebenarnya sudah membukanya di sini. 53 00:02:39,750 --> 00:02:43,903 ‫Dan kemudian pergi ke sini untuk pengembang, lalu pilih webhook, dan 54 00:02:45,070 --> 00:02:47,970 ‫di sini, tambahkan titik akhir baru. 55 00:02:47,970 --> 00:02:52,149 ‫Sekarang apa titik akhir ini di sini dan webhook ini? 56 00:02:52,149 --> 00:02:55,380 ‫Pada dasarnya kita akan menentukan URL di 57 00:02:55,380 --> 00:02:59,500 ‫sini yang Stripe akan secara otomatis mengirim permintaan POST 58 00:02:59,500 --> 00:03:02,800 ‫setiap kali sesi checkout berhasil diselesaikan, jadi 59 00:03:02,800 --> 00:03:05,740 ‫pada dasarnya setiap kali pembayaran berhasil. 60 00:03:05,740 --> 00:03:09,920 ‫Dengan permintaan POST itu, Stripe kemudian akan mengirim kembali data sesi 61 00:03:09,920 --> 00:03:13,230 ‫asli yang kita buat di langkah pertama saat 62 00:03:13,230 --> 00:03:15,623 ‫kita membuat sesi checkout itu. 63 00:03:17,540 --> 00:03:20,130 ‫Itulah alasan mengapa kami benar-benar membutuhkan situs web kami 64 00:03:20,130 --> 00:03:23,010 ‫untuk digunakan di sini karena sekarang kami perlu menentukan 65 00:03:23,010 --> 00:03:24,923 ‫URL kehidupan nyata di sini. 66 00:03:27,170 --> 00:03:28,573 ‫Mari ambil itu dari 67 00:03:31,290 --> 00:03:34,150 ‫sini, lalu tambahkan rute kita di sini pada dasarnya. 68 00:03:34,150 --> 00:03:36,930 ‫Saya akan menyebutnya webhook-checkout. 69 00:03:41,620 --> 00:03:45,350 ‫Itu tidak ada di API, dan tidak ada di dalam pemesanan. 70 00:03:45,350 --> 00:03:47,593 ‫Anda akan melihat sebentar lagi mengapa demikian. 71 00:03:49,130 --> 00:03:51,210 ‫Sekali lagi, ketika pembayaran berhasil, Stripe 72 00:03:51,210 --> 00:03:53,280 ‫kemudian akan secara otomatis memposting 73 00:03:53,280 --> 00:03:55,503 ‫data sesi asli ke URL ini. 74 00:03:58,060 --> 00:04:00,380 ‫Sekarang kita juga perlu memilih acara. 75 00:04:00,380 --> 00:04:04,740 ‫Dan Anda lihat ada banyak sekali acara yang bisa kita gunakan di sini. 76 00:04:04,740 --> 00:04:09,667 ‫Salah satu yang kami gunakan adalah checkout_session_completed. 77 00:04:11,767 --> 00:04:12,650 ‫Tambahkan itu. 78 00:04:12,650 --> 00:04:15,083 ‫Sekarang Anda perlu memasukkan kata sandi Anda di sini lagi. 79 00:04:17,100 --> 00:04:19,110 ‫Dan kemudian di sana kita pergi. 80 00:04:19,110 --> 00:04:22,665 ‫Webhook ini kemudian juga memiliki rahasia di sini. 81 00:04:22,665 --> 00:04:25,850 ‫Yang ini, kita juga akan membutuhkannya sebentar lagi ketika 82 00:04:25,850 --> 00:04:29,063 ‫kita benar-benar membuat rute kita untuk URL ini di sini. 83 00:04:29,980 --> 00:04:32,430 ‫Sebenarnya itulah yang akan kita lakukan selanjutnya. 84 00:04:33,750 --> 00:04:35,600 ‫Pada dasarnya di sistem 85 00:04:35,600 --> 00:04:38,840 ‫kami, tentu saja, kami sekarang membutuhkan rute untuk ini 86 00:04:39,960 --> 00:04:43,840 ‫di sini sehingga ketika Stripe kemudian memposting data ke aplikasi kami, 87 00:04:43,840 --> 00:04:46,233 ‫kami kemudian benar-benar dapat melakukan sesuatu dengannya. 88 00:04:48,120 --> 00:04:52,233 ‫Mari kita kembali ke sini dan membuka aplikasi kita. 89 00:04:54,740 --> 00:04:57,743 ‫Kami benar-benar akan menambahkan rute ini di sini. 90 00:04:59,610 --> 00:05:03,100 ‫Sekali lagi, saya akan menjelaskan mengapa dalam satu detik. 91 00:05:03,100 --> 00:05:04,350 ‫Jadi, aplikasi. post 92 00:05:06,320 --> 00:05:08,850 ‫dan rute standar dan tentu saja kita 93 00:05:08,850 --> 00:05:10,810 ‫membutuhkan fungsi handler untuk itu. 94 00:05:10,810 --> 00:05:14,720 ‫Mari kita buat dengan cepat di sini di BookingController kami. 95 00:05:14,720 --> 00:05:19,013 ‫Izinkan saya menyebut ekspor itu. webhookCheckout. 96 00:05:31,360 --> 00:05:36,360 ‫Sekarang saya harus mengimpor pengontrol ini ke dalam aplikasi. js. 97 00:05:39,210 --> 00:05:42,110 ‫Mari kita lakukan di sini setelah bookingRouter sebenarnya, jadi 98 00:05:45,150 --> 00:05:47,133 ‫yang ini dan yang ini, pengontrol 99 00:05:49,440 --> 00:05:51,383 ‫dan di sini juga pengontrol. 100 00:05:54,580 --> 00:05:56,050 ‫Baiklah. 101 00:05:56,050 --> 00:06:01,050 ‫Sekarang di sini, itu bookingController. webhookCheckout. 102 00:06:04,800 --> 00:06:08,820 ‫Sekarang mengapa kita benar-benar mendefinisikan webhook-checkout ini di 103 00:06:08,820 --> 00:06:12,410 ‫sini di app. js alih-alih 104 00:06:12,410 --> 00:06:14,440 ‫melakukannya misalnya di bookingRouter. 105 00:06:14,440 --> 00:06:17,950 ‫Alasannya adalah bahwa dalam fungsi handler ini, ketika kita 106 00:06:17,950 --> 00:06:20,677 ‫menerima body dari Stripe, fungsi Stripe yang 107 00:06:20,677 --> 00:06:22,850 ‫akan kita gunakan untuk benar-benar 108 00:06:22,850 --> 00:06:26,780 ‫membaca body membutuhkan body ini dalam bentuk mentah, jadi pada 109 00:06:26,780 --> 00:06:29,633 ‫dasarnya sebagai string dan bukan sebagai JSON. 110 00:06:31,370 --> 00:06:34,140 ‫Sekali lagi, dalam rute ini di sini, kita 111 00:06:34,140 --> 00:06:37,555 ‫membutuhkan badan yang datang dengan permintaan untuk tidak berada di 112 00:06:37,555 --> 00:06:40,600 ‫JSON, jika tidak, ini tidak akan berfungsi sama sekali. 113 00:06:40,600 --> 00:06:43,700 ‫Sekarang masalahnya, segera setelah permintaan mengenai middleware 114 00:06:43,700 --> 00:06:46,710 ‫ini di sini, body akan diurai dan 115 00:06:46,710 --> 00:06:48,563 ‫dikonversi ke JSON. 116 00:06:49,700 --> 00:06:54,650 ‫Kemudian akan diajukan berdasarkan permintaan. body sebagai objek JSON sederhana. 117 00:06:54,650 --> 00:06:57,520 ‫Sekali lagi dengan itu, penangan rute ini di 118 00:06:57,520 --> 00:06:59,180 ‫sini tidak akan berfungsi. 119 00:06:59,180 --> 00:07:02,520 ‫Itulah alasan mengapa kita perlu menempatkan rute ini di 120 00:07:02,520 --> 00:07:04,557 ‫sini sebelum kita memanggil body-parser. 121 00:07:05,580 --> 00:07:08,260 ‫Sekarang kita masih perlu untuk benar-benar mengurai tubuh tetapi 122 00:07:08,260 --> 00:07:10,120 ‫dalam format yang disebut mentah. 123 00:07:10,120 --> 00:07:13,690 ‫Pada saat saya merekam video ini, kami tidak 124 00:07:13,690 --> 00:07:17,220 ‫dapat melakukannya dengan Express di luar kotak. 125 00:07:17,220 --> 00:07:21,500 ‫Jadi, dalam video ini, kami mengunduh body-parser dari npm dan menggunakannya 126 00:07:21,500 --> 00:07:24,220 ‫seperti yang saya tunjukkan di video. 127 00:07:24,220 --> 00:07:28,340 ‫Namun, seperti lima hari setelah saya merekam 128 00:07:28,340 --> 00:07:32,770 ‫video ini, Express juga menambahkan parser mentah ke Express. 129 00:07:32,770 --> 00:07:37,000 ‫Sekarang kita bisa menggunakan express. raw daripada harus menginstal 130 00:07:37,000 --> 00:07:39,523 ‫body-parser atau middleware dari npm. 131 00:07:40,530 --> 00:07:44,610 ‫Sekali lagi, dalam video ini, saya sekarang akan menginstal body-parser, tetapi Anda 132 00:07:44,610 --> 00:07:46,440 ‫tidak benar-benar perlu melakukannya. 133 00:07:46,440 --> 00:07:49,293 ‫Anda hanya dapat menggunakan ekspres. mentah sebagai gantinya. 134 00:07:51,590 --> 00:07:52,700 ‫Npm menginstal 135 00:07:54,480 --> 00:07:55,403 ‫body-parser. 136 00:07:58,950 --> 00:08:02,120 ‫Ini mungkin terdengar sedikit fokus, dan 137 00:08:02,120 --> 00:08:04,350 ‫saya benar-benar mengerti itu, tapi 138 00:08:04,350 --> 00:08:08,050 ‫begitulah cara kerja dokumentasi Stripe dan memaksa kita 139 00:08:08,890 --> 00:08:10,893 ‫untuk melakukannya, sungguh. 140 00:08:15,210 --> 00:08:17,100 ‫Mari kita kembali ke sini ke rute kita. 141 00:08:17,100 --> 00:08:20,453 ‫Dalam rute ini, kita membutuhkan tubuh dalam format mentah. 142 00:08:21,460 --> 00:08:25,330 ‫Kita dapat menambahkannya sebagai middleware di sini antara route 143 00:08:25,330 --> 00:08:26,673 ‫dan final handler. 144 00:08:28,654 --> 00:08:31,013 ‫Di sini kita katakan bodyParser. mentah, dan 145 00:08:34,830 --> 00:08:37,490 ‫kami juga perlu spesifik di 146 00:08:39,450 --> 00:08:43,127 ‫sini jenisnya dengan sangat cepat seperti application/json. 147 00:08:48,130 --> 00:08:52,660 ‫Kami sekarang menambahkan penguraian badan ini sebagai badan mentah di sini di 148 00:08:52,660 --> 00:08:54,183 ‫tumpukan middleware ini. 149 00:08:55,964 --> 00:08:58,150 ‫Semua ini akan benar-benar mulai 150 00:08:58,150 --> 00:09:00,970 ‫menyatu begitu kita mulai mengimplementasikan fungsi ini. 151 00:09:00,970 --> 00:09:02,543 ‫Sebenarnya mari kita lakukan itu 152 00:09:03,820 --> 00:09:05,210 ‫sekarang, jadi di sini. 153 00:09:05,210 --> 00:09:07,100 ‫Tapi sebelum kita benar-benar 154 00:09:07,100 --> 00:09:09,780 ‫melakukannya, mari singkirkan semua kode yang kita 155 00:09:09,780 --> 00:09:11,680 ‫tulis untuk membuatnya berfungsi sekarang. 156 00:09:11,680 --> 00:09:14,420 ‫Jadi, pada dasarnya fungsi middleware ini sudah 157 00:09:14,420 --> 00:09:16,350 ‫tidak kita butuhkan lagi. 158 00:09:16,350 --> 00:09:18,480 ‫Juga di sini, di 159 00:09:18,480 --> 00:09:21,980 ‫viewRoutes, kami juga tidak membutuhkannya di sini lagi. 160 00:09:21,980 --> 00:09:24,770 ‫Dan terakhir di bookingController, mari 161 00:09:24,770 --> 00:09:28,153 ‫kita juga mengatur kembali URL kita menjadi normal. 162 00:09:31,080 --> 00:09:33,180 ‫Semua ini akan saya tinggalkan di sini 163 00:09:33,180 --> 00:09:35,233 ‫agar Anda dapat menyimpannya sebagai referensi. 164 00:09:37,390 --> 00:09:40,863 ‫Tapi sekarang URL sukses seharusnya hanya ini. 165 00:09:43,090 --> 00:09:45,400 ‫Pada dasarnya setelah pemesanan berhasil, 166 00:09:45,400 --> 00:09:48,090 ‫kami masih ingin kembali ke tur 167 00:09:48,090 --> 00:09:50,350 ‫saya tetapi tanpa semua 168 00:09:51,350 --> 00:09:54,580 ‫parameter kueri ini karena sekarang bukan lagi fungsi 169 00:09:54,580 --> 00:09:57,430 ‫ini di sini, yang akan menangani 170 00:09:57,430 --> 00:09:59,770 ‫pembuatan pemesanan, melainkan fungsi ini 171 00:09:59,770 --> 00:10:02,060 ‫di sini, yang merupakan tentu 172 00:10:02,060 --> 00:10:05,633 ‫saja yang dipanggil setelah Stripe memanggil webhook kami. 173 00:10:07,140 --> 00:10:08,470 ‫Sekarang mari kita terapkan ini. 174 00:10:08,470 --> 00:10:10,140 ‫Hal pertama yang perlu 175 00:10:10,140 --> 00:10:13,763 ‫kita lakukan adalah menghilangkan tanda tangan Stripe ini dari header kita, 176 00:10:15,780 --> 00:10:19,840 ‫jadi tanda tangan dan kemudian minta. header 177 00:10:21,500 --> 00:10:26,373 ‫dan kemudian dari sana stripe-signature. 178 00:10:28,220 --> 00:10:30,710 ‫Pada dasarnya ketika Stripe memanggil webhook kami, 179 00:10:30,710 --> 00:10:32,830 ‫itu akan menambahkan header ke 180 00:10:32,830 --> 00:10:36,280 ‫permintaan itu yang berisi tanda tangan khusus untuk webhook kami. 181 00:10:38,480 --> 00:10:40,700 ‫Jika Anda berpikir bahwa Anda hanya mengikuti 182 00:10:40,700 --> 00:10:42,590 ‫secara membabi buta apa yang 183 00:10:42,590 --> 00:10:45,070 ‫saya lakukan di sini, yah, (tertawa) sebenarnya itulah 184 00:10:45,070 --> 00:10:47,050 ‫yang saya lakukan juga dari dokumentasi Stripe. 185 00:10:47,050 --> 00:10:50,320 ‫Sekali lagi, ini benar-benar cara kerja Stripe, dan tidak 186 00:10:50,320 --> 00:10:52,973 ‫ada yang bisa kita lakukan untuk melawannya. 187 00:10:54,350 --> 00:10:57,453 ‫Bagaimanapun, selanjutnya, mari kita buat 188 00:10:59,310 --> 00:11:03,690 ‫event Stripe, jadi event const sama dengan stripe. 189 00:11:03,690 --> 00:11:07,410 ‫Untuk itu tentu saja, kita perlu menginstal perpustakaan Stripe, 190 00:11:07,410 --> 00:11:09,573 ‫yang kita miliki di sini. 191 00:11:12,650 --> 00:11:14,350 ‫Jadi, garis. webhook. konstrukAcara. 192 00:11:20,378 --> 00:11:23,210 ‫Sekarang di sinilah akhirnya tubuh itu 193 00:11:23,210 --> 00:11:26,520 ‫berperan, jadi mintalah. tubuh. 194 00:11:26,520 --> 00:11:28,370 ‫Dan ingat bahwa tubuh ini di 195 00:11:28,370 --> 00:11:30,220 ‫sini harus dalam bentuk mentah, 196 00:11:30,220 --> 00:11:32,083 ‫jadi pada dasarnya tersedia sebagai string. 197 00:11:33,130 --> 00:11:36,340 ‫Sekali lagi, itulah sebabnya kami menempatkan rute itu 198 00:11:36,340 --> 00:11:38,110 ‫sebelum semua rute 199 00:11:38,110 --> 00:11:41,580 ‫kami yang lain dan terutama sebelum body parser dapat 200 00:11:41,580 --> 00:11:44,863 ‫melakukan tugasnya mengubah tubuh kami menjadi objek JSON. 201 00:11:46,170 --> 00:11:51,050 ‫Kemudian selain badan itu, untuk acara itu, kita membutuhkan tanda tangan, jadi 202 00:11:51,050 --> 00:11:53,370 ‫pada dasarnya tanda tangan yang 203 00:11:53,370 --> 00:11:56,763 ‫dikirim bersama dengan header, dan akhirnya rahasia webhook kita. 204 00:11:57,710 --> 00:12:00,653 ‫Mari kita dapatkan itu dari sini, salin. 205 00:12:01,585 --> 00:12:05,610 ‫Karena ini rahasia, kita harus, seperti biasa, menambahkannya di 206 00:12:05,610 --> 00:12:07,143 ‫sini ke 207 00:12:10,460 --> 00:12:12,737 ‫file konfigurasi kita, jadi STRIPE_WEBHOOK_SECRET. 208 00:12:16,650 --> 00:12:19,380 ‫Dan kemudian tentu saja, jangan lupa juga menambahkan 209 00:12:19,380 --> 00:12:21,663 ‫ini ke konfigurasi Heroku kami. 210 00:12:26,100 --> 00:12:27,330 ‫Sekarang mari kita gunakan itu. 211 00:12:27,330 --> 00:12:28,767 ‫Tambahkan proses. lingkungan 212 00:12:30,330 --> 00:12:31,830 ‫Seharusnya aku menyalinnya di 213 00:12:35,690 --> 00:12:36,573 ‫sini. 214 00:12:37,752 --> 00:12:41,200 ‫Jadi, Anda tahu, semua ini benar-benar untuk membuat 215 00:12:41,200 --> 00:12:43,450 ‫prosesnya super, super aman. 216 00:12:43,450 --> 00:12:45,970 ‫Kami membutuhkan semua data ini seperti 217 00:12:45,970 --> 00:12:49,450 ‫tanda tangan dan juga rahasia untuk pada dasarnya memvalidasi 218 00:12:49,450 --> 00:12:51,640 ‫data yang masuk ke dalam 219 00:12:51,640 --> 00:12:54,433 ‫tubuh sehingga tidak ada yang benar-benar dapat memanipulasinya. 220 00:12:55,870 --> 00:12:58,050 ‫Nah selama pembuatan event ini, 221 00:12:58,050 --> 00:12:59,280 ‫mungkin ada 222 00:12:59,280 --> 00:13:01,420 ‫beberapa kesalahan, misalnya jika tanda 223 00:13:01,420 --> 00:13:03,900 ‫tangan salah atau jika rahasianya salah. 224 00:13:03,900 --> 00:13:07,813 ‫Jadi, mari kita bungkus ini menjadi blok try-catch. 225 00:13:16,290 --> 00:13:17,850 ‫Oke. 226 00:13:17,850 --> 00:13:19,500 ‫Tentu saja, kita sekarang membutuhkan tangkapan. 227 00:13:22,150 --> 00:13:23,410 ‫Jika ada 228 00:13:23,410 --> 00:13:26,053 ‫kesalahan, kami ingin mengirim kembali kesalahan 229 00:13:27,880 --> 00:13:32,450 ‫ke Stripe, jadi kembalikan res. status 400 dan kemudian gunakan saja 230 00:13:33,756 --> 00:13:35,657 ‫kesalahan kirim webhook 231 00:13:40,140 --> 00:13:44,023 ‫dan kemudian tambahkan saja kesalahannya. pesan. 232 00:13:45,714 --> 00:13:49,220 ‫Jadi, Stripe yang akan menerima tanggapan ini karena 233 00:13:49,220 --> 00:13:53,230 ‫sekali lagi Stripe yang akan memanggil URL, jadi webhook 234 00:13:53,230 --> 00:13:56,603 ‫kita, yang kemudian akan memanggil fungsi ini. 235 00:13:58,520 --> 00:14:02,420 ‫Sekarang tentu saja kita juga perlu mendeklarasikan event ini di sini 236 00:14:02,420 --> 00:14:04,610 ‫di luar blok try-catch karena 237 00:14:04,610 --> 00:14:07,623 ‫jika tidak, kita tidak akan dapat menggunakannya di sana. 238 00:14:08,660 --> 00:14:13,160 ‫Jadi, biarkan event dan kemudian tetapkan kembali di sini karena 239 00:14:13,160 --> 00:14:15,430 ‫ingat bahwa ES6 const dan 240 00:14:15,430 --> 00:14:17,450 ‫let adalah cakupan blok. 241 00:14:17,450 --> 00:14:20,480 ‫Jadi, variabel ini tidak akan tersedia di luar 242 00:14:20,480 --> 00:14:21,473 ‫blok ini. 243 00:14:23,180 --> 00:14:25,830 ‫Sekarang mari kita benar-benar menggunakan acara itu. 244 00:14:25,830 --> 00:14:29,090 ‫Pertama, kita perlu menguji apakah ini benar-benar acara yang 245 00:14:29,090 --> 00:14:29,923 ‫kita inginkan. 246 00:14:30,810 --> 00:14:34,240 ‫Jadi, kita bisa melakukan acara. jenis sama dengan 247 00:14:34,240 --> 00:14:38,973 ‫checkout. sidang. menyelesaikan. 248 00:14:42,080 --> 00:14:44,370 ‫Ingatlah bahwa di dasbor 249 00:14:44,370 --> 00:14:48,090 ‫Stripe kami, itulah jenis yang kami definisikan di sini. 250 00:14:48,090 --> 00:14:49,260 ‫Jadi, itulah jenis acaranya. 251 00:14:49,260 --> 00:14:52,183 ‫Sekarang kami sedang memeriksa apakah itu 252 00:14:52,183 --> 00:14:56,287 ‫benar-benar peristiwa yang kami terima di sini untuk memastikan 100%. 253 00:14:56,287 --> 00:14:59,780 ‫Jika ya, kami ingin benar-benar menggunakan acara tersebut untuk membuat 254 00:14:59,780 --> 00:15:02,053 ‫pemesanan kami di database kami. 255 00:15:03,860 --> 00:15:06,280 ‫Sebenarnya mari kita lakukan itu dalam fungsi yang 256 00:15:06,280 --> 00:15:08,983 ‫terpisah dan tidak di dalam sini dari semua kekacauan ini. 257 00:15:10,517 --> 00:15:12,590 ‫Untuk itu, saya akan membuat fungsi. 258 00:15:12,590 --> 00:15:13,640 ‫Sebenarnya izinkan saya 259 00:15:13,640 --> 00:15:15,990 ‫memberikan nama yang sama persis ini, jadi buatBookingCheckout. 260 00:15:17,487 --> 00:15:19,490 ‫Itu sebenarnya nama yang bagus, tapi 261 00:15:19,490 --> 00:15:21,450 ‫sekarang tidak bisa menjadi middleware 262 00:15:21,450 --> 00:15:23,250 ‫melainkan hanya fungsi biasa. 263 00:15:26,080 --> 00:15:28,823 ‫Fungsi ini akan menerima data sesi. 264 00:15:31,080 --> 00:15:35,310 ‫Dan ingat bahwa data sesi persis sesi ini yang kami 265 00:15:35,310 --> 00:15:37,513 ‫buat di sini sejak awal. 266 00:15:41,404 --> 00:15:43,730 ‫Jika ini adalah acara yang benar, 267 00:15:43,730 --> 00:15:45,743 ‫maka mari kita panggil fungsi 268 00:15:46,680 --> 00:15:49,500 ‫itu, jadi buatBookingCheckout dengan sesi, yang ada 269 00:15:49,500 --> 00:15:53,057 ‫di acara. data. obyek. 270 00:15:57,447 --> 00:15:58,320 ‫Dan akhirnya, 271 00:15:58,320 --> 00:16:01,333 ‫mari kita kirim kembali beberapa tanggapan ke Stripe. 272 00:16:02,450 --> 00:16:03,840 ‫Jadi, status 273 00:16:05,780 --> 00:16:07,480 ‫200 dan katakanlah beberapa json 274 00:16:10,300 --> 00:16:11,823 ‫menerima disetel ke true. 275 00:16:13,200 --> 00:16:14,033 ‫Masuk akal? 276 00:16:16,000 --> 00:16:18,490 ‫Sekali lagi, semua kode ini di 277 00:16:18,490 --> 00:16:21,390 ‫sini akan berjalan setiap kali pembayaran berhasil. 278 00:16:21,390 --> 00:16:25,380 ‫Stripe kemudian akan memanggil webhook kita, yang merupakan URL, yang 279 00:16:25,380 --> 00:16:27,420 ‫akan memanggil fungsi ini. 280 00:16:27,420 --> 00:16:30,600 ‫Jadi, fungsi ini menerima isi dari permintaan, 281 00:16:30,600 --> 00:16:34,330 ‫dan kemudian bersama dengan tanda tangan dan/atau rahasia webhook, 282 00:16:34,330 --> 00:16:37,110 ‫membuat acara, yang akan berisi sesi. 283 00:16:37,110 --> 00:16:39,190 ‫Dan kemudian menggunakan data sesi itu, 284 00:16:39,190 --> 00:16:41,963 ‫kita bisa membuat pemesanan baru kita di database. 285 00:16:43,987 --> 00:16:45,660 ‫Jadi, itu sebenarnya akan sangat mirip dengan apa 286 00:16:45,660 --> 00:16:47,143 ‫yang kita miliki di sini sebelumnya. 287 00:16:48,400 --> 00:16:51,790 ‫Jadi, kita akan membutuhkan baris kode ini di sini lagi. 288 00:16:51,790 --> 00:16:53,923 ‫Jadi, ini juga akan menjadi fungsi async. 289 00:16:58,497 --> 00:17:00,530 ‫Jadi, ini persis sama. 290 00:17:00,530 --> 00:17:02,260 ‫Sekarang yang kita butuhkan 291 00:17:02,260 --> 00:17:06,690 ‫di sini tentu saja adalah untuk mendapatkan akses ke tur, pengguna, dan harga. 292 00:17:06,690 --> 00:17:10,550 ‫Tapi data itu sekali lagi disimpan di sesi itu. 293 00:17:10,550 --> 00:17:12,400 ‫Jadi, mari kita mulai dengan tur. 294 00:17:12,400 --> 00:17:14,780 ‫Dan ingat bagaimana di sini ketika 295 00:17:14,780 --> 00:17:17,100 ‫kami pertama kali membuat 296 00:17:17,100 --> 00:17:20,040 ‫fungsi handler ini, saya menentukan bidang client_reference_id 297 00:17:20,040 --> 00:17:22,370 ‫ini dan menambahkan tourId ke dalamnya. 298 00:17:22,370 --> 00:17:23,840 ‫Ingat bahwa? 299 00:17:23,840 --> 00:17:25,700 ‫Saya melakukan itu karena, pada 300 00:17:25,700 --> 00:17:29,840 ‫saat itu, saya sudah tahu bahwa kami akan membutuhkan ID tur ini nanti. 301 00:17:29,840 --> 00:17:32,490 ‫Sekarang saatnya kita benar-benar membutuhkan ID 302 00:17:32,490 --> 00:17:35,333 ‫tur untuk dapat membuat pemesanan baru itu. 303 00:17:36,732 --> 00:17:38,490 ‫Jadi, sekarang tour ID 304 00:17:38,490 --> 00:17:41,670 ‫yang kita butuhkan ada di session dot client reference ID. 305 00:17:41,670 --> 00:17:44,770 ‫Jadi, mari kita salin ini dan katakan 306 00:17:47,870 --> 00:17:48,703 ‫session. 307 00:17:49,660 --> 00:17:53,823 ‫Dan tentu saja, di sini kita perlu mengatakan tur. 308 00:17:55,670 --> 00:17:57,040 ‫Jadi, itulah ID turnya. 309 00:17:57,040 --> 00:17:59,150 ‫Selanjutnya, kita membutuhkan ID pengguna. 310 00:17:59,150 --> 00:18:01,240 ‫Sekarang informasi yang kami miliki 311 00:18:01,240 --> 00:18:03,973 ‫di sesi kami tentang pengguna adalah email pengguna. 312 00:18:05,630 --> 00:18:07,170 ‫Jadi, sekarang yang 313 00:18:07,170 --> 00:18:10,500 ‫perlu kita lakukan pada dasarnya adalah mendapatkan ID pengguna. 314 00:18:10,500 --> 00:18:12,793 ‫Untuk itu, kami akan melakukan query melalui email. 315 00:18:13,720 --> 00:18:16,810 ‫Itu tidak masalah karena emailnya juga unik. 316 00:18:16,810 --> 00:18:19,353 ‫Berdasarkan itu, kami kemudian dapat menemukan ID unik. 317 00:18:20,370 --> 00:18:24,183 ‫Jadi, pengguna const sedang menunggu. 318 00:18:25,570 --> 00:18:27,660 ‫Dan saya pikir kita sudah memiliki pengguna di sini. 319 00:18:27,660 --> 00:18:28,493 ‫Tidak? 320 00:18:29,520 --> 00:18:30,570 ‫Tidak, sebenarnya tidak. 321 00:18:31,890 --> 00:18:33,290 ‫Jadi, mari kita lakukan itu di sini. 322 00:18:35,490 --> 00:18:37,973 ‫Dan pengguna di sini juga. 323 00:18:41,070 --> 00:18:41,903 ‫Oke. 324 00:18:41,903 --> 00:18:46,890 ‫Jadi, Pengguna. findOne dan kemudian kueri melalui email, 325 00:18:47,990 --> 00:18:51,330 ‫yang ada di titik sesi, dan saya yakin 326 00:18:51,330 --> 00:18:53,780 ‫itu email klien atau semacamnya. 327 00:18:55,200 --> 00:18:56,200 ‫Ini adalah email_pelanggan. 328 00:18:59,860 --> 00:19:00,693 ‫Oke. 329 00:19:02,070 --> 00:19:04,970 ‫Tapi itu kemudian akan mengembalikan seluruh dokumen, tetapi 330 00:19:04,970 --> 00:19:06,910 ‫kami sebenarnya menginginkan ID. 331 00:19:06,910 --> 00:19:09,780 ‫Jadi, mari kita bungkus semua ini di sini 332 00:19:10,730 --> 00:19:14,743 ‫dalam tanda kurung dan kemudian panggil ID di sana atau baca IDnya. 333 00:19:16,620 --> 00:19:17,960 ‫Jadi, itu saja. 334 00:19:17,960 --> 00:19:19,233 ‫Dan akhirnya, harga. 335 00:19:22,350 --> 00:19:24,023 ‫Di mana harga disimpan? 336 00:19:25,320 --> 00:19:26,833 ‫Nah, itu di sini di line_items. 337 00:19:27,880 --> 00:19:30,610 ‫Itu array, jadi pada elemen 338 00:19:30,610 --> 00:19:33,553 ‫nol, dan kemudian jumlahnya dibagi 100. 339 00:19:34,580 --> 00:19:38,210 ‫Jadi, kami mengalikannya di sini dengan 100 untuk mendapatkan sen, 340 00:19:38,210 --> 00:19:41,590 ‫tetapi sekarang tentu saja kami menginginkannya kembali dalam dolar. 341 00:19:41,590 --> 00:19:44,700 ‫Jadi, pada dasarnya kita perlu membaginya kembali. 342 00:19:44,700 --> 00:19:48,550 ‫Dan, sesi. line_items dan 343 00:19:49,460 --> 00:19:54,460 ‫kemudian elemen pertama titik jumlah jika saya benar. 344 00:19:55,950 --> 00:19:56,783 ‫Ya. 345 00:19:56,783 --> 00:20:01,710 ‫Jadi, jumlah dibagi 100. 346 00:20:01,710 --> 00:20:04,010 ‫Seharusnya itu saja. 347 00:20:04,010 --> 00:20:06,630 ‫Sekarang mari kita komit perubahan kita ke 348 00:20:06,630 --> 00:20:08,740 ‫repo dan dorong ke Stripe. 349 00:20:08,740 --> 00:20:12,840 ‫Jadi, git add all, tentu saja, 350 00:20:12,840 --> 00:20:16,600 ‫dan kemudian git commit pesan 351 00:20:18,090 --> 00:20:21,633 ‫Implementasi strip yang 352 00:20:24,960 --> 00:20:29,960 ‫ditingkatkan, dan kemudian git push heroku master. 353 00:20:31,190 --> 00:20:33,273 ‫Sekali lagi, ini akan memakan waktu. 354 00:20:33,273 --> 00:20:35,263 ‫Saya akan melihat Anda ketika itu selesai. 355 00:20:36,200 --> 00:20:37,033 ‫Baiklah. 356 00:20:37,033 --> 00:20:40,323 ‫Sekarang jangan lupa untuk mengatur variabel lingkungan baru itu. 357 00:20:41,610 --> 00:20:46,610 ‫Jadi, itulah kumpulan titik dua konfigurasi heroku, dan kemudian 358 00:20:46,750 --> 00:20:49,433 ‫cukup salin dari sini. 359 00:20:53,590 --> 00:20:54,720 ‫Oke. 360 00:20:54,720 --> 00:20:56,800 ‫Itu kemudian me-restart aplikasi. 361 00:20:56,800 --> 00:20:58,173 ‫Dan itu saja. 362 00:20:59,570 --> 00:21:02,723 ‫Jadi, sekarang mari kita benar-benar pergi ke depan dan mengujinya. 363 00:21:04,980 --> 00:21:05,813 ‫Baiklah. 364 00:21:07,050 --> 00:21:09,480 ‫Kami masih di sini dalam aplikasi kami. 365 00:21:09,480 --> 00:21:12,883 ‫Mari kita lihat tur mana yang sudah dipesan Laura. 366 00:21:14,100 --> 00:21:15,370 ‫Dia memiliki Pendaki Hutan. 367 00:21:15,370 --> 00:21:19,823 ‫Pemesanan tersebut masih dilakukan dengan cara lama. 368 00:21:21,050 --> 00:21:24,240 ‫Tetapi metode lama itu sekarang tidak lagi berfungsi. 369 00:21:24,240 --> 00:21:27,047 ‫Sekarang jika kita melakukan pemesanan lain 370 00:21:27,047 --> 00:21:29,490 ‫dan berhasil, maka itu 371 00:21:29,490 --> 00:21:32,773 ‫berarti tentu saja implementasi baru kita berhasil. 372 00:21:34,730 --> 00:21:35,780 ‫Mari kita uji di sini. 373 00:21:39,760 --> 00:21:41,493 ‫Seperti biasa, 4242. 374 00:21:50,420 --> 00:21:51,683 ‫Sekarang mari kita tunggu saja. 375 00:21:52,730 --> 00:21:55,740 ‫Yah, itu tampaknya tidak berjalan dengan baik karena jika 376 00:21:55,740 --> 00:21:58,520 ‫tidak, tur baru kedua kami seharusnya sudah ada 377 00:21:58,520 --> 00:22:00,743 ‫di sini dalam pemesanan kami. 378 00:22:02,230 --> 00:22:04,203 ‫Mari kita lihat di sini di dasbor kami. 379 00:22:05,860 --> 00:22:06,983 ‫Jika kita sekarang 380 00:22:12,150 --> 00:22:15,893 ‫memuat ulang ini, maka kita benar-benar melihat bahwa ada acara yang sukses. 381 00:22:17,407 --> 00:22:20,320 ‫Jadi, itulah acara yang baru saja kami buat 382 00:22:20,320 --> 00:22:23,170 ‫dan yang mengirim badan ini ke sini 383 00:22:23,170 --> 00:22:25,380 ‫dan kemudian menerima tanggapan ini. 384 00:22:25,380 --> 00:22:27,560 ‫Jadi, penerimaan yang disetel ke true ini 385 00:22:27,560 --> 00:22:30,663 ‫persis seperti yang kami lakukan di sini dalam kode kami, jadi 386 00:22:31,670 --> 00:22:32,633 ‫ini di sini. 387 00:22:34,060 --> 00:22:36,000 ‫Jadi, itulah respons yang kami 388 00:22:36,000 --> 00:22:39,770 ‫kirimkan dan tubuh yang kami dapatkan adalah semua data ini. 389 00:22:39,770 --> 00:22:42,810 ‫Jadi, kita bisa lihat di 390 00:22:42,810 --> 00:22:46,460 ‫sini sesi dengan harga, dengan email, dengan tur. 391 00:22:46,460 --> 00:22:49,483 ‫Jadi, saya tidak yakin mengapa itu tidak berhasil. 392 00:22:51,000 --> 00:22:53,163 ‫Jadi, mari kita cepat memuat ulang ini di sini. 393 00:22:55,780 --> 00:22:59,050 ‫Jadi, sebenarnya implementasi Stripe kami harus benar, tetapi, untuk 394 00:22:59,050 --> 00:23:02,013 ‫beberapa alasan, pemesanan baru kami tidak dibuat. 395 00:23:03,120 --> 00:23:05,020 ‫Mari kita periksa juga di sini di Kompas. 396 00:23:07,460 --> 00:23:09,970 ‫Dan memang, itu tidak ada. 397 00:23:09,970 --> 00:23:12,123 ‫Jadi, mari kembali ke kode kita di sini. 398 00:23:13,410 --> 00:23:17,360 ‫Oh dan satu kesalahan yang langsung saya lihat ada di sini. 399 00:23:17,360 --> 00:23:20,393 ‫Jadi, harus diselesaikan seperti ini. 400 00:23:22,090 --> 00:23:24,480 ‫Jadi, itu kesalahan bodoh. 401 00:23:24,480 --> 00:23:26,950 ‫Mari kita lihat apakah mungkin 402 00:23:26,950 --> 00:23:30,050 ‫ada kesalahan lain di sini di createBookingCheckout. 403 00:23:30,050 --> 00:23:30,883 ‫Di sini kita 404 00:23:32,750 --> 00:23:33,583 ‫memiliki line_items. 405 00:23:33,583 --> 00:23:35,093 ‫Mari kita lihat apakah itu benar. 406 00:23:36,110 --> 00:23:38,170 ‫Dan ya, sepertinya begitu. 407 00:23:38,170 --> 00:23:41,123 ‫Kami juga dapat mengonfirmasinya di sini lagi di Stripe kami. 408 00:23:43,110 --> 00:23:45,290 ‫Sebenarnya ini namanya display_items. 409 00:23:46,590 --> 00:23:47,423 ‫Itu aneh. 410 00:23:48,367 --> 00:23:52,140 ‫Hanya untuk memastikan, sebut saja display_items di sini dalam 411 00:23:52,140 --> 00:23:54,363 ‫kode kita di sini. 412 00:23:55,980 --> 00:23:57,580 ‫Sekarang hal lain yang saya perhatikan 413 00:23:58,750 --> 00:24:00,350 ‫sekarang ketika saya melihat lagi 414 00:24:00,350 --> 00:24:03,510 ‫di sini adalah bahwa kita masih memiliki gambar ini dikodekan ke 415 00:24:03,510 --> 00:24:05,763 ‫alam lain ini. pengembang 416 00:24:07,587 --> 00:24:11,380 ‫Sekarang mari kita perbaiki itu karena pada titik ini tentu 417 00:24:11,380 --> 00:24:14,580 ‫saja, situs web kita sudah aktif dan disebarkan. 418 00:24:14,580 --> 00:24:16,600 ‫Jadi, pada dasarnya kita dapat menggantinya dengan yang sama 419 00:24:16,600 --> 00:24:18,100 ‫seperti yang kita miliki di sini. 420 00:24:20,900 --> 00:24:23,430 ‫Jadi, kami menggunakan bagian ini di sini berkali-kali. 421 00:24:23,430 --> 00:24:25,480 ‫Jadi, inilah saatnya untuk menggunakannya lagi di sini. 422 00:24:32,672 --> 00:24:33,505 ‫Ya. 423 00:24:33,505 --> 00:24:35,353 ‫Mari kita coba untuk menerapkan ulang ini. 424 00:24:36,380 --> 00:24:38,113 ‫Jadi, git tambahkan semua lagi. 425 00:24:40,420 --> 00:24:42,070 ‫Dan sebut saja ini 426 00:24:42,070 --> 00:24:44,430 ‫di sini Implementasi strip yang ditingkatkan dua. 427 00:24:44,430 --> 00:24:47,693 ‫Dan kemudian dorong lagi ke Heroku. 428 00:24:51,580 --> 00:24:52,560 ‫Oke. 429 00:24:52,560 --> 00:24:54,253 ‫Mari kita coba itu sekali lagi. 430 00:24:55,830 --> 00:24:57,023 ‫Mari kita kembali ke sini. 431 00:25:00,630 --> 00:25:04,063 ‫Sekarang ayo coba booking lagi ke Park Camper. 432 00:25:15,760 --> 00:25:16,683 ‫Baiklah. 433 00:25:17,920 --> 00:25:21,530 ‫Anda harus melihat gambar muncul di sini di sisi kiri. 434 00:25:21,530 --> 00:25:24,200 ‫Itu berarti integrasi gambar baru kami juga 435 00:25:24,200 --> 00:25:25,753 ‫bekerja dengan baik. 436 00:25:27,220 --> 00:25:28,283 ‫Sekarang sedang diproses. 437 00:25:29,382 --> 00:25:31,380 ‫Ah sekarang ada di sini. 438 00:25:31,380 --> 00:25:32,320 ‫Besar. 439 00:25:32,320 --> 00:25:33,533 ‫Itu indah. 440 00:25:34,420 --> 00:25:36,850 ‫Sekarang kami benar-benar memiliki implementasi Stripe 441 00:25:36,850 --> 00:25:39,940 ‫yang aman dan jauh lebih profesional dalam 442 00:25:39,940 --> 00:25:41,173 ‫aplikasi kami. 443 00:25:42,070 --> 00:25:43,520 ‫Itu hebat. 444 00:25:43,520 --> 00:25:45,570 ‫Tentu saja, jika Anda 445 00:25:45,570 --> 00:25:49,500 ‫memuat ulang di sini, maka Anda akan melihat acara baru ini 446 00:25:49,500 --> 00:25:52,050 ‫di sini, jadi panggilan baru ini ke 447 00:25:52,050 --> 00:25:54,593 ‫webhook kami, yang tentu saja berhasil lagi. 448 00:25:55,840 --> 00:25:57,690 ‫Itu bagus. 449 00:25:57,690 --> 00:26:00,740 ‫Sekarang hanya ada satu hal terakhir yang ingin saya 450 00:26:00,740 --> 00:26:04,420 ‫lakukan, yang pada dasarnya adalah memberikan umpan balik kepada pengguna dalam 451 00:26:04,420 --> 00:26:06,980 ‫bentuk salah satu pesan hijau yang kami 452 00:26:06,980 --> 00:26:09,123 ‫gunakan juga misalnya dalam login. 453 00:26:10,650 --> 00:26:12,930 ‫Saat ini aplikasi kami tidak 454 00:26:12,930 --> 00:26:16,476 ‫benar-benar memberikan umpan balik apa pun ketika tur baru dipesan. 455 00:26:16,476 --> 00:26:18,650 ‫Sekarang saya ingin mengubah itu. 456 00:26:18,650 --> 00:26:21,900 ‫Namun, melakukan ini tidak terlalu mudah karena 457 00:26:21,900 --> 00:26:23,990 ‫ingat bahwa pesan-pesan 458 00:26:23,990 --> 00:26:26,750 ‫ini sebenarnya ditampilkan oleh JavaScript. 459 00:26:26,750 --> 00:26:30,280 ‫Jadi, dalam kasus lain, kami melakukan panggilan HTTP ke API kami. 460 00:26:30,280 --> 00:26:33,070 ‫Dan ketika itu selesai, kami menggunakan JavaScript 461 00:26:33,070 --> 00:26:34,840 ‫untuk menampilkan semacam pesan. 462 00:26:34,840 --> 00:26:36,970 ‫Tapi sekarang kita tidak melakukannya dengan cara ini. 463 00:26:36,970 --> 00:26:40,710 ‫Jadi, pesan tersebut seharusnya sudah berada di suatu tempat di 464 00:26:40,710 --> 00:26:42,380 ‫HTML segera setelah halaman 465 00:26:42,380 --> 00:26:45,400 ‫dimuat sehingga JavaScript kami dapat mengambil pesan 466 00:26:45,400 --> 00:26:49,070 ‫itu dari HTML dan menampilkannya dengan baik di salah 467 00:26:49,070 --> 00:26:50,463 ‫satu spanduk ini. 468 00:26:51,610 --> 00:26:54,510 ‫Jadi, cara saya menempatkan peringatan ini 469 00:26:54,510 --> 00:26:58,223 ‫di HTML sekali lagi dengan menggunakan properti data. 470 00:26:59,450 --> 00:27:03,000 ‫Mari kita mulai dengan menerapkan fitur ini di 471 00:27:03,000 --> 00:27:04,363 ‫template utama kita. 472 00:27:06,610 --> 00:27:09,273 ‫Itu di sini dalam pandangan, base. 473 00:27:11,160 --> 00:27:13,630 ‫Saya benar-benar akan menambahkan pesan peringatan itu 474 00:27:13,630 --> 00:27:15,663 ‫langsung ke elemen tubuh. 475 00:27:17,110 --> 00:27:19,963 ‫Di sini kita akan memiliki properti peringatan 476 00:27:21,860 --> 00:27:24,000 ‫data, yang seharusnya hanya disetel 477 00:27:24,000 --> 00:27:26,563 ‫jika variabel peringatan tersedia di sini. 478 00:27:27,480 --> 00:27:31,460 ‫Jadi, mari kita gunakan ES6, jadi string templat, 479 00:27:31,460 --> 00:27:35,060 ‫dan katakan jika ada peringatan, 480 00:27:35,060 --> 00:27:38,713 ‫gunakan peringatan di sini, dan string kosong. 481 00:27:39,980 --> 00:27:43,370 ‫Jadi, peringatan ini di sini akan menjadi pesan 482 00:27:43,370 --> 00:27:47,230 ‫peringatan yang kemudian akan diambil oleh JavaScript dan ditampilkan di halaman. 483 00:27:47,230 --> 00:27:50,230 ‫Sekarang bagaimana pesan peringatan ini benar-benar berakhir sebagai variabel 484 00:27:50,230 --> 00:27:52,513 ‫peringatan di sini di template kita? 485 00:27:53,360 --> 00:27:56,448 ‫Nah, saya datang dengan solusi yang dapat digunakan kembali 486 00:27:56,448 --> 00:27:59,250 ‫sehingga kita dapat menggunakan seluruh aplikasi kita. 487 00:27:59,250 --> 00:28:01,840 ‫Yaitu bahwa pada string kueri, kami akan menambahkan beberapa 488 00:28:01,840 --> 00:28:03,890 ‫kata kunci peringatan dan kemudian kami 489 00:28:03,890 --> 00:28:05,820 ‫akan memiliki middleware, yang akan 490 00:28:05,820 --> 00:28:08,560 ‫mengambil kata kunci itu dari URL dan, menurut kata 491 00:28:08,560 --> 00:28:10,910 ‫kunci yang kami masukkan di sana, kemudian akan 492 00:28:10,910 --> 00:28:15,050 ‫menempatkan seluruh pesan peringatan pada respons . penduduk setempat. 493 00:28:15,050 --> 00:28:19,000 ‫Jadi, ingatlah bahwa segala sesuatu yang ada di respon. locals kemudian tersedia 494 00:28:19,000 --> 00:28:22,483 ‫sebagai variabel di semua template kami. 495 00:28:23,450 --> 00:28:25,630 ‫Jadi, kami benar-benar menggunakannya sebelumnya di 496 00:28:25,630 --> 00:28:27,563 ‫authController kami, saya percaya. 497 00:28:29,480 --> 00:28:32,567 ‫Sangat cepat, izinkan saya menunjukkannya kepada Anda. 498 00:28:33,530 --> 00:28:37,060 ‫Di sini, kami mengatakan tanggapan. lokal. pengguna dan 499 00:28:37,060 --> 00:28:39,074 ‫menempatkan pengguna saat ini di sana. 500 00:28:39,074 --> 00:28:41,720 ‫Kemudian secara otomatis di semua template, kami 501 00:28:41,720 --> 00:28:44,283 ‫memiliki akses ke variabel pengguna itu. 502 00:28:47,430 --> 00:28:50,070 ‫Jadi, sekarang mari kita terapkan apa yang baru 503 00:28:50,070 --> 00:28:52,597 ‫saja saya katakan dan mulai dengan URL. 504 00:28:54,330 --> 00:28:57,540 ‫Apa yang akan saya lakukan di sini adalah untuk benar-benar menambahkan string kueri 505 00:28:57,540 --> 00:28:59,097 ‫di sini ke URL yang berhasil. 506 00:28:59,970 --> 00:29:04,573 ‫Di sini, saya akan mengatakan peringatan pemesanan yang sama. 507 00:29:05,970 --> 00:29:10,310 ‫Sekarang saya bisa, di semua URL lainnya, juga menambahkan beberapa peringatan dan kemudian dengan 508 00:29:10,310 --> 00:29:12,863 ‫kata kunci yang berbeda di sini, tentu saja. 509 00:29:14,350 --> 00:29:18,100 ‫Dan kami hanya akan melakukannya di sini untuk pemesanan ini. 510 00:29:18,100 --> 00:29:21,793 ‫Tetapi sekali lagi saya membuat semacam solusi yang dapat digunakan kembali di sini. 511 00:29:23,340 --> 00:29:27,470 ‫Bagaimanapun, sekarang di rute kami, pada dasarnya kami membutuhkan middleware, yang 512 00:29:27,470 --> 00:29:29,920 ‫akan berjalan untuk semua permintaan. 513 00:29:29,920 --> 00:29:32,270 ‫Dan middleware itu, yang akan mengambil peringatan 514 00:29:32,270 --> 00:29:35,240 ‫dari string kueri dan memasukkan pesan peringatan ke 515 00:29:35,240 --> 00:29:37,453 ‫respons kami. penduduk setempat. 516 00:29:41,457 --> 00:29:42,624 ‫Jadi, router. 517 00:29:45,040 --> 00:29:48,233 ‫gunakan viewController. peringatan. 518 00:29:50,290 --> 00:29:52,320 ‫Jadi, ini adalah fungsi middleware, 519 00:29:52,320 --> 00:29:56,200 ‫yang pada dasarnya akan berjalan untuk setiap permintaan yang masuk ke 520 00:29:56,200 --> 00:29:58,130 ‫router ini, jadi pada 521 00:29:58,130 --> 00:30:01,063 ‫dasarnya untuk semua permintaan ke situs web kami. 522 00:30:02,370 --> 00:30:04,870 ‫Sekarang mari kita buat middleware itu di 523 00:30:04,870 --> 00:30:06,020 ‫viewsController kita. 524 00:30:10,460 --> 00:30:12,380 ‫Jadi, ekspor. permintaan 525 00:30:14,480 --> 00:30:17,283 ‫peringatan, tanggapan, dan berikutnya. 526 00:30:19,650 --> 00:30:20,730 ‫Jadi, peringatan 527 00:30:22,760 --> 00:30:26,300 ‫itu adalah permintaan. pertanyaan. peringatan. 528 00:30:26,300 --> 00:30:29,873 ‫Jadi, mari kita gunakan struktur ini sekali lagi. 529 00:30:32,020 --> 00:30:36,553 ‫Dan katakanlah jika peringatan sama dengan pemesanan, jadi peringatan yang 530 00:30:39,030 --> 00:30:42,653 ‫kita tempatkan di sini di string kueri, nah, 531 00:30:44,670 --> 00:30:46,070 ‫dalam kasus 532 00:30:46,070 --> 00:30:50,970 ‫itu, katakanlah respons. penduduk setempat. peringatan 533 00:30:52,830 --> 00:30:57,970 ‫akan pemesanan Anda berhasil, 534 00:30:59,850 --> 00:31:06,883 ‫silakan periksa email Anda untuk konfirmasi. 535 00:31:10,330 --> 00:31:13,090 ‫Dan kami juga harus menambahkan 536 00:31:13,090 --> 00:31:17,960 ‫beberapa frasa lain, yaitu yang ini, jika pemesanan Anda tidak, pilih 537 00:31:24,070 --> 00:31:27,743 ‫ini, jangan langsung muncul di sini, silakan kembali 538 00:31:33,270 --> 00:31:34,523 ‫lagi nanti. 539 00:31:36,140 --> 00:31:37,230 ‫Dan 540 00:31:37,230 --> 00:31:39,920 ‫bagian terakhir ini karena Stripe 541 00:31:39,920 --> 00:31:43,620 ‫secara spesifik mengatakan dalam dokumentasi mereka bahwa terkadang 542 00:31:43,620 --> 00:31:46,880 ‫webhook dipanggil sedikit setelah URL sukses dipanggil. 543 00:31:46,880 --> 00:31:49,810 ‫Dalam hal ini, URL sukses itu kemudian akan 544 00:31:49,810 --> 00:31:52,677 ‫menampilkan semua tur saat ini, tetapi hanya setelah 545 00:31:52,677 --> 00:31:54,300 ‫itu, webhook akan 546 00:31:54,300 --> 00:31:57,270 ‫dipanggil dan tur akan dibuat di database kami. 547 00:31:57,270 --> 00:32:00,040 ‫Oleh karena itu, pemesanan baru tidak akan langsung 548 00:32:00,040 --> 00:32:01,953 ‫muncul di halaman Pemesanan Saya. 549 00:32:02,850 --> 00:32:06,220 ‫Tapi tentu saja, semuanya masih bekerja dengan baik dalam kasus itu. 550 00:32:06,220 --> 00:32:09,583 ‫Jadi, saya cukup memuat ulang, tetapi nanti kami akan memperbaiki masalah itu. 551 00:32:12,340 --> 00:32:15,080 ‫Sekarang kita hanya perlu memanggil middleware berikutnya. 552 00:32:15,080 --> 00:32:17,160 ‫Dan itu sebenarnya. 553 00:32:17,160 --> 00:32:21,390 ‫Sekali lagi, kami hanya melakukan ini di sini untuk peringatan yang sama dengan pemesanan, 554 00:32:21,390 --> 00:32:24,090 ‫tetapi sekarang kami dapat menggunakan ini di semua 555 00:32:24,090 --> 00:32:27,070 ‫tempat di situs web kami dengan menyetel kata kunci peringatan 556 00:32:27,070 --> 00:32:28,982 ‫dan string kueri yang berbeda. 557 00:32:28,982 --> 00:32:33,982 ‫Dengan ini, kami menempatkan pesan ini di sini ke res. penduduk setempat. peringatan. 558 00:32:35,600 --> 00:32:38,940 ‫Sekali lagi, template dasar kami kemudian akan mengambilnya 559 00:32:38,940 --> 00:32:42,320 ‫dan menampilkannya di sini ke dalam properti peringatan data ini. 560 00:32:42,320 --> 00:32:46,440 ‫Jadi, yang tersisa untuk dilakukan sekarang adalah pergi ke index. js dan 561 00:32:46,440 --> 00:32:49,890 ‫baca lansiran dari sini lalu tampilkan. 562 00:32:49,890 --> 00:32:52,100 ‫Jadi, itu seharusnya cukup mudah. 563 00:32:52,100 --> 00:32:56,230 ‫Di sini, di depan umum, mari kita lakukan dengan benar di index. 564 00:32:56,230 --> 00:33:00,260 ‫Dan hal pertama adalah kita benar-benar perlu mengimpor 565 00:33:00,260 --> 00:33:01,343 ‫fungsi alerts. 566 00:33:06,480 --> 00:33:08,160 ‫Itu bukan aplikasi. 567 00:33:08,160 --> 00:33:09,343 ‫Ada di sini di index. 568 00:33:10,920 --> 00:33:12,090 ‫Oke. 569 00:33:12,090 --> 00:33:15,883 ‫Dan kemudian di sini, pada dasarnya mari kita membaca peringatan itu. 570 00:33:17,290 --> 00:33:22,133 ‫Jadi, const alertMessage, katakanlah, adalah 571 00:33:23,250 --> 00:33:25,320 ‫dokumen. querySelector, lalu 572 00:33:28,742 --> 00:33:31,327 ‫elemen body, titik dataset. peringatan. 573 00:33:35,350 --> 00:33:37,673 ‫Jadi, hanya jika ada peringatan, 574 00:33:39,760 --> 00:33:42,020 ‫tentu saja, maka tunjukkan peringatan 575 00:33:43,160 --> 00:33:44,250 ‫dengan 576 00:33:45,840 --> 00:33:48,000 ‫sukses dan pesan peringatan. 577 00:33:48,000 --> 00:33:50,640 ‫Dan sekarang satu hal kecil yang ingin 578 00:33:50,640 --> 00:33:54,630 ‫saya lakukan adalah mengubah sedikit fungsi showAlert di sini karena 579 00:33:54,630 --> 00:33:57,210 ‫kita sebenarnya memiliki banyak teks sekarang. 580 00:33:57,210 --> 00:33:59,780 ‫Dan waktu standar lansiran ditampilkan 581 00:33:59,780 --> 00:34:03,163 ‫tidak akan cukup untuk benar-benar membaca semua teks. 582 00:34:04,210 --> 00:34:06,880 ‫Jadi, Anda lihat di sini bahwa setelah lima 583 00:34:06,880 --> 00:34:08,373 ‫detik, peringatan itu disembunyikan. 584 00:34:10,126 --> 00:34:11,760 ‫Mari kita benar-benar mengizinkan 585 00:34:11,760 --> 00:34:14,253 ‫pengguna untuk menentukan jumlah detik peringatan itu ditampilkan. 586 00:34:16,810 --> 00:34:20,320 ‫Kami akan melakukannya sebagai default lima detik. 587 00:34:20,320 --> 00:34:24,810 ‫Di sini, kita cukup menghitung waktu dikalikan 1.000 untuk 588 00:34:24,810 --> 00:34:26,483 ‫mengubahnya menjadi milidetik. 589 00:34:27,976 --> 00:34:30,690 ‫Seperti ini, semua fungsi akan bekerja di 590 00:34:30,690 --> 00:34:32,270 ‫mana-mana dengan lima detik. 591 00:34:32,270 --> 00:34:34,790 ‫Mari kita membuatnya menjadi tujuh detik jika 592 00:34:34,790 --> 00:34:36,600 ‫kita tidak menentukan apa pun. 593 00:34:36,600 --> 00:34:39,980 ‫Tapi jika kita mau, kita bisa mengganti tujuh ini. 594 00:34:39,980 --> 00:34:42,040 ‫Jadi, saya akan melakukannya sekarang 595 00:34:42,040 --> 00:34:45,370 ‫di sini dan benar-benar meletakkannya di layar selama 20 detik. 596 00:34:45,370 --> 00:34:46,203 ‫Baiklah. 597 00:34:47,360 --> 00:34:49,240 ‫Saya pikir itu seharusnya. 598 00:34:49,240 --> 00:34:51,060 ‫Saya harap itu masuk akal. 599 00:34:51,060 --> 00:34:53,993 ‫Sekarang mari kita dengan cepat mengkompilasi bundel kita. 600 00:34:55,360 --> 00:35:00,343 ‫Itu npm run build, lalu ketuk pelengkapan otomatis. 601 00:35:03,480 --> 00:35:05,990 ‫Itu juga membutuhkan sedikit waktu. 602 00:35:05,990 --> 00:35:07,373 ‫Tapi sekarang sudah selesai. 603 00:35:12,030 --> 00:35:14,340 ‫Sekarang mari kita terapkan untuk terakhir kalinya dengan 604 00:35:15,580 --> 00:35:17,083 ‫harapan itu benar-benar berfungsi. 605 00:35:18,250 --> 00:35:19,083 ‫Jadi, git komit. 606 00:35:25,840 --> 00:35:27,513 ‫Jadi, pesan Stripe. 607 00:35:29,670 --> 00:35:34,670 ‫Dan untuk terakhir kalinya, git push heroku master. 608 00:35:37,451 --> 00:35:41,403 ‫Sekarang mari kita uji dengan membeli tur lagi di sini. 609 00:35:42,830 --> 00:35:44,963 ‫Mari kita dapatkan City Wanderer kali ini. 610 00:35:46,490 --> 00:35:49,683 ‫Oh, saya baru tahu ada pesan di sini. 611 00:35:50,810 --> 00:35:51,783 ‫Itu tidak baik. 612 00:35:54,530 --> 00:35:58,500 ‫Dan Anda melihat bahwa itu menghilang setelah 20 detik. 613 00:35:58,500 --> 00:36:00,240 ‫Jadi, sepertinya sekarang, secara default, 614 00:36:00,240 --> 00:36:02,993 ‫kelas peringatan ini akan selalu ditempatkan di sini. 615 00:36:06,028 --> 00:36:06,861 ‫(tertawa) 616 00:36:06,861 --> 00:36:07,694 ‫Ya. 617 00:36:07,694 --> 00:36:09,990 ‫Itu karena di sini seharusnya alertMessage dan 618 00:36:09,990 --> 00:36:11,063 ‫bukan hanya alert. 619 00:36:12,810 --> 00:36:16,800 ‫Tapi bagaimanapun, sekarang mari kita uji apakah pesan 620 00:36:16,800 --> 00:36:20,433 ‫itu benar ketika kita memesan tur. 621 00:36:24,410 --> 00:36:25,243 ‫Oke. 622 00:36:32,470 --> 00:36:34,880 ‫Sekarang mari kita tunggu saja. 623 00:36:34,880 --> 00:36:36,330 ‫Ini dia. 624 00:36:36,330 --> 00:36:39,163 ‫Memang, ada pesan kami. 625 00:36:40,130 --> 00:36:41,460 ‫Sangat cantik. 626 00:36:41,460 --> 00:36:44,420 ‫Juga, tur kami muncul di sini. 627 00:36:44,420 --> 00:36:48,510 ‫Dan Anda melihat bahwa itu benar-benar tinggal di sini untuk waktu yang lama. 628 00:36:48,510 --> 00:36:49,853 ‫Jadi, itu juga berhasil. 629 00:36:51,532 --> 00:36:52,832 ‫Ayo cepat... 630 00:36:55,840 --> 00:36:59,383 ‫Dan pertama, kita benar-benar perlu membangun kembali bundel di sini. 631 00:37:03,877 --> 00:37:07,170 ‫Kemudian kami dapat menambahkan semuanya 632 00:37:13,580 --> 00:37:18,490 ‫ke area pementasan kami, Perbaikan bug peringatan pesan. 633 00:37:18,490 --> 00:37:19,670 ‫Jadi, ini 634 00:37:19,670 --> 00:37:23,500 ‫adalah beberapa (tertawa) pesan yang terdengar sangat profesional di sini. 635 00:37:23,500 --> 00:37:26,313 ‫Sekarang satu dorongan terakhir untuk Heroku. 636 00:37:29,670 --> 00:37:32,580 ‫Sekarang ketika kita memuat halaman kita, kita 637 00:37:32,580 --> 00:37:34,740 ‫seharusnya tidak melihat pesan peringatan. 638 00:37:34,740 --> 00:37:37,250 ‫Dan memang, sekarang semuanya bersih. 639 00:37:37,250 --> 00:37:40,470 ‫Jadi, sekarang saya dapat mengatakan bahwa setidaknya untuk 640 00:37:40,470 --> 00:37:42,977 ‫saat ini, proyek ini benar-benar selesai. 641 00:37:42,977 --> 00:37:46,490 ‫Sekali lagi, kerja bagus, selamat, dan selamat karena 642 00:37:46,490 --> 00:37:51,100 ‫mungkin menjadi salah satu dari sedikit orang yang benar-benar berhasil sampai 643 00:37:51,100 --> 00:37:54,350 ‫akhir proyek dan benar-benar membangun situs web 644 00:37:54,350 --> 00:37:58,370 ‫yang indah ini dan juga API yang sekarang dapat 645 00:37:58,370 --> 00:38:01,780 ‫Anda masukkan ke dalam portofolio Anda dan tunjukkan 646 00:38:01,780 --> 00:38:02,923 ‫pada dunia.