‫Dosen: Dan sekarang untuk menyelesaikan proyek
‫ini, mari selesaikan integrasi Stripe ini dengan webhook.
‫Mari kita mulai mengingat bagaimana integrasi Stripe
‫kita bekerja saat ini.
‫Kami memiliki titik akhir sesi
‫checkout ini, yang dipanggil dari front-end kami.
‫Ini kemudian akan memanggil fungsi getCheckoutSession, jadi pada
‫dasarnya yang ini
‫di sini, yang akan membuat sesi checkout di server
‫menggunakan semua informasi ini di sini,
‫dan kemudian mengirimkannya kembali ke klien.
‫Kemudian setelah proses pembayaran berhasil
‫dilakukan oleh Stripe, kemudian redirect
‫pengguna ke URL sukses ini, jadi ini yang
‫kami buat.
‫Ingat bahwa ke URL ini, kami menambahkan ID tur,
‫ID pengguna, dan juga harganya.
‫Kami melakukannya sehingga setelah URL ini dipanggil, aplikasi
‫kami akan membuat dokumen pemesanan baru
‫di database kami.
‫Bagaimana itu berhasil?
‫Di rute my-tours, kami memiliki middleware untuk itu.
‫Ingat, di sini, di viewRoutes, di tur saya,
‫kami memiliki createBookingCheckout ini.
‫Fungsi ini di sini, yang pada dasarnya dari kueri
‫mengambil tur, pengguna, dan harga,
‫dan membuat entri dalam database menggunakan data tersebut.
‫Pada dasarnya kami menempatkan data ini
‫di URL setiap kali Stripe berhasil memproses pembayaran.
‫Dan kemudian fungsi middleware yang kami miliki
‫di sini mengambil data dan membuat pemesanan baru di sistem kami
‫menggunakan data tersebut.
‫Dan kemudian setelah itu, pada dasarnya kami mengarahkan
‫ulang ke sini ke URL asli tanpa string kueri.
‫Sekarang masalah dengan ini adalah bahwa itu tidak benar-benar aman.
‫Jadi, semua orang yang mengetahui struktur URL
‫ini, jadi yang ini, tur, pengguna, dan harga mana dalam
‫string kueri, pada dasarnya dapat membuat pemesanan di
‫sistem kami tanpa benar-benar membayar.
‫Jadi, yang harus kita lakukan adalah membuka URL ini
‫dengan beberapa data
‫di sana dan kemudian dari sana secara otomatis
‫membuat pemesanan tanpa melalui proses Stripe.
‫Ingat bagaimana saat itu saya mengatakan bahwa kami akan
‫memperbaikinya menggunakan sesuatu yang disebut webhooks.
‫Jadi, kita lakukan itu sekarang.
‫Karena untuk
‫itu, sebenarnya kita membutuhkan website kita untuk di-deploy.
‫Sekarang pada titik ini, itulah yang sebenarnya terjadi.
‫Jadi, sekarang kita bisa mengimplementasikan webhook ini.
‫Untuk itu, mari buka dasbor Stripe kami.
‫Dan saya sebenarnya sudah membukanya di sini.
‫Dan kemudian pergi ke sini untuk pengembang, lalu pilih webhook, dan
‫di sini, tambahkan titik akhir baru.
‫Sekarang apa titik akhir ini di sini dan webhook ini?
‫Pada dasarnya kita akan menentukan URL di
‫sini yang Stripe akan secara otomatis mengirim permintaan POST
‫setiap kali sesi checkout berhasil diselesaikan, jadi
‫pada dasarnya setiap kali pembayaran berhasil.
‫Dengan permintaan POST itu, Stripe kemudian akan mengirim kembali data sesi
‫asli yang kita buat di langkah pertama saat
‫kita membuat sesi checkout itu.
‫Itulah alasan mengapa kami benar-benar membutuhkan situs web kami
‫untuk digunakan di sini karena sekarang kami perlu menentukan
‫URL kehidupan nyata di sini.
‫Mari ambil itu dari
‫sini, lalu tambahkan rute kita di sini pada dasarnya.
‫Saya akan menyebutnya webhook-checkout.
‫Itu tidak ada di API, dan tidak ada di dalam pemesanan.
‫Anda akan melihat sebentar lagi mengapa demikian.
‫Sekali lagi, ketika pembayaran berhasil, Stripe
‫kemudian akan secara otomatis memposting
‫data sesi asli ke URL ini.
‫Sekarang kita juga perlu memilih acara.
‫Dan Anda lihat ada banyak sekali acara yang bisa kita gunakan di sini.
‫Salah satu yang kami gunakan adalah checkout_session_completed.
‫Tambahkan itu.
‫Sekarang Anda perlu memasukkan kata sandi Anda di sini lagi.
‫Dan kemudian di sana kita pergi.
‫Webhook ini kemudian juga memiliki rahasia di sini.
‫Yang ini, kita juga akan membutuhkannya sebentar lagi ketika
‫kita benar-benar membuat rute kita untuk URL ini di sini.
‫Sebenarnya itulah yang akan kita lakukan selanjutnya.
‫Pada dasarnya di sistem
‫kami, tentu saja, kami sekarang membutuhkan rute untuk ini
‫di sini sehingga ketika Stripe kemudian memposting data ke aplikasi kami,
‫kami kemudian benar-benar dapat melakukan sesuatu dengannya.
‫Mari kita kembali ke sini dan membuka aplikasi kita.
‫Kami benar-benar akan menambahkan rute ini di sini.
‫Sekali lagi, saya akan menjelaskan mengapa dalam satu detik.
‫Jadi, aplikasi. post
‫dan rute standar dan tentu saja kita
‫membutuhkan fungsi handler untuk itu.
‫Mari kita buat dengan cepat di sini di BookingController kami.
‫Izinkan saya menyebut ekspor itu. webhookCheckout.
‫Sekarang saya harus mengimpor pengontrol ini ke dalam aplikasi. js.
‫Mari kita lakukan di sini setelah bookingRouter sebenarnya, jadi
‫yang ini dan yang ini, pengontrol
‫dan di sini juga pengontrol.
‫Baiklah.
‫Sekarang di sini, itu bookingController. webhookCheckout.
‫Sekarang mengapa kita benar-benar mendefinisikan webhook-checkout ini di
‫sini di app. js alih-alih
‫melakukannya misalnya di bookingRouter.
‫Alasannya adalah bahwa dalam fungsi handler ini, ketika kita
‫menerima body dari Stripe, fungsi Stripe yang
‫akan kita gunakan untuk benar-benar
‫membaca body membutuhkan body ini dalam bentuk mentah, jadi pada
‫dasarnya sebagai string dan bukan sebagai JSON.
‫Sekali lagi, dalam rute ini di sini, kita
‫membutuhkan badan yang datang dengan permintaan untuk tidak berada di
‫JSON, jika tidak, ini tidak akan berfungsi sama sekali.
‫Sekarang masalahnya, segera setelah permintaan mengenai middleware
‫ini di sini, body akan diurai dan
‫dikonversi ke JSON.
‫Kemudian akan diajukan berdasarkan permintaan. body sebagai objek JSON sederhana.
‫Sekali lagi dengan itu, penangan rute ini di
‫sini tidak akan berfungsi.
‫Itulah alasan mengapa kita perlu menempatkan rute ini di
‫sini sebelum kita memanggil body-parser.
‫Sekarang kita masih perlu untuk benar-benar mengurai tubuh tetapi
‫dalam format yang disebut mentah.
‫Pada saat saya merekam video ini, kami tidak
‫dapat melakukannya dengan Express di luar kotak.
‫Jadi, dalam video ini, kami mengunduh body-parser dari npm dan menggunakannya
‫seperti yang saya tunjukkan di video.
‫Namun, seperti lima hari setelah saya merekam
‫video ini, Express juga menambahkan parser mentah ke Express.
‫Sekarang kita bisa menggunakan express. raw daripada harus menginstal
‫body-parser atau middleware dari npm.
‫Sekali lagi, dalam video ini, saya sekarang akan menginstal body-parser, tetapi Anda
‫tidak benar-benar perlu melakukannya.
‫Anda hanya dapat menggunakan ekspres. mentah sebagai gantinya.
‫Npm menginstal
‫body-parser.
‫Ini mungkin terdengar sedikit fokus, dan
‫saya benar-benar mengerti itu, tapi
‫begitulah cara kerja dokumentasi Stripe dan memaksa kita
‫untuk melakukannya, sungguh.
‫Mari kita kembali ke sini ke rute kita.
‫Dalam rute ini, kita membutuhkan tubuh dalam format mentah.
‫Kita dapat menambahkannya sebagai middleware di sini antara route
‫dan final handler.
‫Di sini kita katakan bodyParser. mentah, dan
‫kami juga perlu spesifik di
‫sini jenisnya dengan sangat cepat seperti application/json.
‫Kami sekarang menambahkan penguraian badan ini sebagai badan mentah di sini di
‫tumpukan middleware ini.
‫Semua ini akan benar-benar mulai
‫menyatu begitu kita mulai mengimplementasikan fungsi ini.
‫Sebenarnya mari kita lakukan itu
‫sekarang, jadi di sini.
‫Tapi sebelum kita benar-benar
‫melakukannya, mari singkirkan semua kode yang kita
‫tulis untuk membuatnya berfungsi sekarang.
‫Jadi, pada dasarnya fungsi middleware ini sudah
‫tidak kita butuhkan lagi.
‫Juga di sini, di
‫viewRoutes, kami juga tidak membutuhkannya di sini lagi.
‫Dan terakhir di bookingController, mari
‫kita juga mengatur kembali URL kita menjadi normal.
‫Semua ini akan saya tinggalkan di sini
‫agar Anda dapat menyimpannya sebagai referensi.
‫Tapi sekarang URL sukses seharusnya hanya ini.
‫Pada dasarnya setelah pemesanan berhasil,
‫kami masih ingin kembali ke tur
‫saya tetapi tanpa semua
‫parameter kueri ini karena sekarang bukan lagi fungsi
‫ini di sini, yang akan menangani
‫pembuatan pemesanan, melainkan fungsi ini
‫di sini, yang merupakan tentu
‫saja yang dipanggil setelah Stripe memanggil webhook kami.
‫Sekarang mari kita terapkan ini.
‫Hal pertama yang perlu
‫kita lakukan adalah menghilangkan tanda tangan Stripe ini dari header kita,
‫jadi tanda tangan dan kemudian minta. header
‫dan kemudian dari sana stripe-signature.
‫Pada dasarnya ketika Stripe memanggil webhook kami,
‫itu akan menambahkan header ke
‫permintaan itu yang berisi tanda tangan khusus untuk webhook kami.
‫Jika Anda berpikir bahwa Anda hanya mengikuti
‫secara membabi buta apa yang
‫saya lakukan di sini, yah, (tertawa) sebenarnya itulah
‫yang saya lakukan juga dari dokumentasi Stripe.
‫Sekali lagi, ini benar-benar cara kerja Stripe, dan tidak
‫ada yang bisa kita lakukan untuk melawannya.
‫Bagaimanapun, selanjutnya, mari kita buat
‫event Stripe, jadi event const sama dengan stripe.
‫Untuk itu tentu saja, kita perlu menginstal perpustakaan Stripe,
‫yang kita miliki di sini.
‫Jadi, garis. webhook. konstrukAcara.
‫Sekarang di sinilah akhirnya tubuh itu
‫berperan, jadi mintalah. tubuh.
‫Dan ingat bahwa tubuh ini di
‫sini harus dalam bentuk mentah,
‫jadi pada dasarnya tersedia sebagai string.
‫Sekali lagi, itulah sebabnya kami menempatkan rute itu
‫sebelum semua rute
‫kami yang lain dan terutama sebelum body parser dapat
‫melakukan tugasnya mengubah tubuh kami menjadi objek JSON.
‫Kemudian selain badan itu, untuk acara itu, kita membutuhkan tanda tangan, jadi
‫pada dasarnya tanda tangan yang
‫dikirim bersama dengan header, dan akhirnya rahasia webhook kita.
‫Mari kita dapatkan itu dari sini, salin.
‫Karena ini rahasia, kita harus, seperti biasa, menambahkannya di
‫sini ke
‫file konfigurasi kita, jadi STRIPE_WEBHOOK_SECRET.
‫Dan kemudian tentu saja, jangan lupa juga menambahkan
‫ini ke konfigurasi Heroku kami.
‫Sekarang mari kita gunakan itu.
‫Tambahkan proses. lingkungan
‫Seharusnya aku menyalinnya di
‫sini.
‫Jadi, Anda tahu, semua ini benar-benar untuk membuat
‫prosesnya super, super aman.
‫Kami membutuhkan semua data ini seperti
‫tanda tangan dan juga rahasia untuk pada dasarnya memvalidasi
‫data yang masuk ke dalam
‫tubuh sehingga tidak ada yang benar-benar dapat memanipulasinya.
‫Nah selama pembuatan event ini,
‫mungkin ada
‫beberapa kesalahan, misalnya jika tanda
‫tangan salah atau jika rahasianya salah.
‫Jadi, mari kita bungkus ini menjadi blok try-catch.
‫Oke.
‫Tentu saja, kita sekarang membutuhkan tangkapan.
‫Jika ada
‫kesalahan, kami ingin mengirim kembali kesalahan
‫ke Stripe, jadi kembalikan res. status 400 dan kemudian gunakan saja
‫kesalahan kirim webhook
‫dan kemudian tambahkan saja kesalahannya. pesan.
‫Jadi, Stripe yang akan menerima tanggapan ini karena
‫sekali lagi Stripe yang akan memanggil URL, jadi webhook
‫kita, yang kemudian akan memanggil fungsi ini.
‫Sekarang tentu saja kita juga perlu mendeklarasikan event ini di sini
‫di luar blok try-catch karena
‫jika tidak, kita tidak akan dapat menggunakannya di sana.
‫Jadi, biarkan event dan kemudian tetapkan kembali di sini karena
‫ingat bahwa ES6 const dan
‫let adalah cakupan blok.
‫Jadi, variabel ini tidak akan tersedia di luar
‫blok ini.
‫Sekarang mari kita benar-benar menggunakan acara itu.
‫Pertama, kita perlu menguji apakah ini benar-benar acara yang
‫kita inginkan.
‫Jadi, kita bisa melakukan acara. jenis sama dengan
‫checkout. sidang. menyelesaikan.
‫Ingatlah bahwa di dasbor
‫Stripe kami, itulah jenis yang kami definisikan di sini.
‫Jadi, itulah jenis acaranya.
‫Sekarang kami sedang memeriksa apakah itu
‫benar-benar peristiwa yang kami terima di sini untuk memastikan 100%.
‫Jika ya, kami ingin benar-benar menggunakan acara tersebut untuk membuat
‫pemesanan kami di database kami.
‫Sebenarnya mari kita lakukan itu dalam fungsi yang
‫terpisah dan tidak di dalam sini dari semua kekacauan ini.
‫Untuk itu, saya akan membuat fungsi.
‫Sebenarnya izinkan saya
‫memberikan nama yang sama persis ini, jadi buatBookingCheckout.
‫Itu sebenarnya nama yang bagus, tapi
‫sekarang tidak bisa menjadi middleware
‫melainkan hanya fungsi biasa.
‫Fungsi ini akan menerima data sesi.
‫Dan ingat bahwa data sesi persis sesi ini yang kami
‫buat di sini sejak awal.
‫Jika ini adalah acara yang benar,
‫maka mari kita panggil fungsi
‫itu, jadi buatBookingCheckout dengan sesi, yang ada
‫di acara. data. obyek.
‫Dan akhirnya,
‫mari kita kirim kembali beberapa tanggapan ke Stripe.
‫Jadi, status
‫200 dan katakanlah beberapa json
‫menerima disetel ke true.
‫Masuk akal?
‫Sekali lagi, semua kode ini di
‫sini akan berjalan setiap kali pembayaran berhasil.
‫Stripe kemudian akan memanggil webhook kita, yang merupakan URL, yang
‫akan memanggil fungsi ini.
‫Jadi, fungsi ini menerima isi dari permintaan,
‫dan kemudian bersama dengan tanda tangan dan/atau rahasia webhook,
‫membuat acara, yang akan berisi sesi.
‫Dan kemudian menggunakan data sesi itu,
‫kita bisa membuat pemesanan baru kita di database.
‫Jadi, itu sebenarnya akan sangat mirip dengan apa
‫yang kita miliki di sini sebelumnya.
‫Jadi, kita akan membutuhkan baris kode ini di sini lagi.
‫Jadi, ini juga akan menjadi fungsi async.
‫Jadi, ini persis sama.
‫Sekarang yang kita butuhkan
‫di sini tentu saja adalah untuk mendapatkan akses ke tur, pengguna, dan harga.
‫Tapi data itu sekali lagi disimpan di sesi itu.
‫Jadi, mari kita mulai dengan tur.
‫Dan ingat bagaimana di sini ketika
‫kami pertama kali membuat
‫fungsi handler ini, saya menentukan bidang client_reference_id
‫ini dan menambahkan tourId ke dalamnya.
‫Ingat bahwa?
‫Saya melakukan itu karena, pada
‫saat itu, saya sudah tahu bahwa kami akan membutuhkan ID tur ini nanti.
‫Sekarang saatnya kita benar-benar membutuhkan ID
‫tur untuk dapat membuat pemesanan baru itu.
‫Jadi, sekarang tour ID
‫yang kita butuhkan ada di session dot client reference ID.
‫Jadi, mari kita salin ini dan katakan
‫session.
‫Dan tentu saja, di sini kita perlu mengatakan tur.
‫Jadi, itulah ID turnya.
‫Selanjutnya, kita membutuhkan ID pengguna.
‫Sekarang informasi yang kami miliki
‫di sesi kami tentang pengguna adalah email pengguna.
‫Jadi, sekarang yang
‫perlu kita lakukan pada dasarnya adalah mendapatkan ID pengguna.
‫Untuk itu, kami akan melakukan query melalui email.
‫Itu tidak masalah karena emailnya juga unik.
‫Berdasarkan itu, kami kemudian dapat menemukan ID unik.
‫Jadi, pengguna const sedang menunggu.
‫Dan saya pikir kita sudah memiliki pengguna di sini.
‫Tidak?
‫Tidak, sebenarnya tidak.
‫Jadi, mari kita lakukan itu di sini.
‫Dan pengguna di sini juga.
‫Oke.
‫Jadi, Pengguna. findOne dan kemudian kueri melalui email,
‫yang ada di titik sesi, dan saya yakin
‫itu email klien atau semacamnya.
‫Ini adalah email_pelanggan.
‫Oke.
‫Tapi itu kemudian akan mengembalikan seluruh dokumen, tetapi
‫kami sebenarnya menginginkan ID.
‫Jadi, mari kita bungkus semua ini di sini
‫dalam tanda kurung dan kemudian panggil ID di sana atau baca IDnya.
‫Jadi, itu saja.
‫Dan akhirnya, harga.
‫Di mana harga disimpan?
‫Nah, itu di sini di line_items.
‫Itu array, jadi pada elemen
‫nol, dan kemudian jumlahnya dibagi 100.
‫Jadi, kami mengalikannya di sini dengan 100 untuk mendapatkan sen,
‫tetapi sekarang tentu saja kami menginginkannya kembali dalam dolar.
‫Jadi, pada dasarnya kita perlu membaginya kembali.
‫Dan, sesi. line_items dan
‫kemudian elemen pertama titik jumlah jika saya benar.
‫Ya.
‫Jadi, jumlah dibagi 100.
‫Seharusnya itu saja.
‫Sekarang mari kita komit perubahan kita ke
‫repo dan dorong ke Stripe.
‫Jadi, git add all, tentu saja,
‫dan kemudian git commit pesan
‫Implementasi strip yang
‫ditingkatkan, dan kemudian git push heroku master.
‫Sekali lagi, ini akan memakan waktu.
‫Saya akan melihat Anda ketika itu selesai.
‫Baiklah.
‫Sekarang jangan lupa untuk mengatur variabel lingkungan baru itu.
‫Jadi, itulah kumpulan titik dua konfigurasi heroku, dan kemudian
‫cukup salin dari sini.
‫Oke.
‫Itu kemudian me-restart aplikasi.
‫Dan itu saja.
‫Jadi, sekarang mari kita benar-benar pergi ke depan dan mengujinya.
‫Baiklah.
‫Kami masih di sini dalam aplikasi kami.
‫Mari kita lihat tur mana yang sudah dipesan Laura.
‫Dia memiliki Pendaki Hutan.
‫Pemesanan tersebut masih dilakukan dengan cara lama.
‫Tetapi metode lama itu sekarang tidak lagi berfungsi.
‫Sekarang jika kita melakukan pemesanan lain
‫dan berhasil, maka itu
‫berarti tentu saja implementasi baru kita berhasil.
‫Mari kita uji di sini.
‫Seperti biasa, 4242.
‫Sekarang mari kita tunggu saja.
‫Yah, itu tampaknya tidak berjalan dengan baik karena jika
‫tidak, tur baru kedua kami seharusnya sudah ada
‫di sini dalam pemesanan kami.
‫Mari kita lihat di sini di dasbor kami.
‫Jika kita sekarang
‫memuat ulang ini, maka kita benar-benar melihat bahwa ada acara yang sukses.
‫Jadi, itulah acara yang baru saja kami buat
‫dan yang mengirim badan ini ke sini
‫dan kemudian menerima tanggapan ini.
‫Jadi, penerimaan yang disetel ke true ini
‫persis seperti yang kami lakukan di sini dalam kode kami, jadi
‫ini di sini.
‫Jadi, itulah respons yang kami
‫kirimkan dan tubuh yang kami dapatkan adalah semua data ini.
‫Jadi, kita bisa lihat di
‫sini sesi dengan harga, dengan email, dengan tur.
‫Jadi, saya tidak yakin mengapa itu tidak berhasil.
‫Jadi, mari kita cepat memuat ulang ini di sini.
‫Jadi, sebenarnya implementasi Stripe kami harus benar, tetapi, untuk
‫beberapa alasan, pemesanan baru kami tidak dibuat.
‫Mari kita periksa juga di sini di Kompas.
‫Dan memang, itu tidak ada.
‫Jadi, mari kembali ke kode kita di sini.
‫Oh dan satu kesalahan yang langsung saya lihat ada di sini.
‫Jadi, harus diselesaikan seperti ini.
‫Jadi, itu kesalahan bodoh.
‫Mari kita lihat apakah mungkin
‫ada kesalahan lain di sini di createBookingCheckout.
‫Di sini kita
‫memiliki line_items.
‫Mari kita lihat apakah itu benar.
‫Dan ya, sepertinya begitu.
‫Kami juga dapat mengonfirmasinya di sini lagi di Stripe kami.
‫Sebenarnya ini namanya display_items.
‫Itu aneh.
‫Hanya untuk memastikan, sebut saja display_items di sini dalam
‫kode kita di sini.
‫Sekarang hal lain yang saya perhatikan
‫sekarang ketika saya melihat lagi
‫di sini adalah bahwa kita masih memiliki gambar ini dikodekan ke
‫alam lain ini. pengembang
‫Sekarang mari kita perbaiki itu karena pada titik ini tentu
‫saja, situs web kita sudah aktif dan disebarkan.
‫Jadi, pada dasarnya kita dapat menggantinya dengan yang sama
‫seperti yang kita miliki di sini.
‫Jadi, kami menggunakan bagian ini di sini berkali-kali.
‫Jadi, inilah saatnya untuk menggunakannya lagi di sini.
‫Ya.
‫Mari kita coba untuk menerapkan ulang ini.
‫Jadi, git tambahkan semua lagi.
‫Dan sebut saja ini
‫di sini Implementasi strip yang ditingkatkan dua.
‫Dan kemudian dorong lagi ke Heroku.
‫Oke.
‫Mari kita coba itu sekali lagi.
‫Mari kita kembali ke sini.
‫Sekarang ayo coba booking lagi ke Park Camper.
‫Baiklah.
‫Anda harus melihat gambar muncul di sini di sisi kiri.
‫Itu berarti integrasi gambar baru kami juga
‫bekerja dengan baik.
‫Sekarang sedang diproses.
‫Ah sekarang ada di sini.
‫Besar.
‫Itu indah.
‫Sekarang kami benar-benar memiliki implementasi Stripe
‫yang aman dan jauh lebih profesional dalam
‫aplikasi kami.
‫Itu hebat.
‫Tentu saja, jika Anda
‫memuat ulang di sini, maka Anda akan melihat acara baru ini
‫di sini, jadi panggilan baru ini ke
‫webhook kami, yang tentu saja berhasil lagi.
‫Itu bagus.
‫Sekarang hanya ada satu hal terakhir yang ingin saya
‫lakukan, yang pada dasarnya adalah memberikan umpan balik kepada pengguna dalam
‫bentuk salah satu pesan hijau yang kami
‫gunakan juga misalnya dalam login.
‫Saat ini aplikasi kami tidak
‫benar-benar memberikan umpan balik apa pun ketika tur baru dipesan.
‫Sekarang saya ingin mengubah itu.
‫Namun, melakukan ini tidak terlalu mudah karena
‫ingat bahwa pesan-pesan
‫ini sebenarnya ditampilkan oleh JavaScript.
‫Jadi, dalam kasus lain, kami melakukan panggilan HTTP ke API kami.
‫Dan ketika itu selesai, kami menggunakan JavaScript
‫untuk menampilkan semacam pesan.
‫Tapi sekarang kita tidak melakukannya dengan cara ini.
‫Jadi, pesan tersebut seharusnya sudah berada di suatu tempat di
‫HTML segera setelah halaman
‫dimuat sehingga JavaScript kami dapat mengambil pesan
‫itu dari HTML dan menampilkannya dengan baik di salah
‫satu spanduk ini.
‫Jadi, cara saya menempatkan peringatan ini
‫di HTML sekali lagi dengan menggunakan properti data.
‫Mari kita mulai dengan menerapkan fitur ini di
‫template utama kita.
‫Itu di sini dalam pandangan, base.
‫Saya benar-benar akan menambahkan pesan peringatan itu
‫langsung ke elemen tubuh.
‫Di sini kita akan memiliki properti peringatan
‫data, yang seharusnya hanya disetel
‫jika variabel peringatan tersedia di sini.
‫Jadi, mari kita gunakan ES6, jadi string templat,
‫dan katakan jika ada peringatan,
‫gunakan peringatan di sini, dan string kosong.
‫Jadi, peringatan ini di sini akan menjadi pesan
‫peringatan yang kemudian akan diambil oleh JavaScript dan ditampilkan di halaman.
‫Sekarang bagaimana pesan peringatan ini benar-benar berakhir sebagai variabel
‫peringatan di sini di template kita?
‫Nah, saya datang dengan solusi yang dapat digunakan kembali
‫sehingga kita dapat menggunakan seluruh aplikasi kita.
‫Yaitu bahwa pada string kueri, kami akan menambahkan beberapa
‫kata kunci peringatan dan kemudian kami
‫akan memiliki middleware, yang akan
‫mengambil kata kunci itu dari URL dan, menurut kata
‫kunci yang kami masukkan di sana, kemudian akan
‫menempatkan seluruh pesan peringatan pada respons . penduduk setempat.
‫Jadi, ingatlah bahwa segala sesuatu yang ada di respon. locals kemudian tersedia
‫sebagai variabel di semua template kami.
‫Jadi, kami benar-benar menggunakannya sebelumnya di
‫authController kami, saya percaya.
‫Sangat cepat, izinkan saya menunjukkannya kepada Anda.
‫Di sini, kami mengatakan tanggapan. lokal. pengguna dan
‫menempatkan pengguna saat ini di sana.
‫Kemudian secara otomatis di semua template, kami
‫memiliki akses ke variabel pengguna itu.
‫Jadi, sekarang mari kita terapkan apa yang baru
‫saja saya katakan dan mulai dengan URL.
‫Apa yang akan saya lakukan di sini adalah untuk benar-benar menambahkan string kueri
‫di sini ke URL yang berhasil.
‫Di sini, saya akan mengatakan peringatan pemesanan yang sama.
‫Sekarang saya bisa, di semua URL lainnya, juga menambahkan beberapa peringatan dan kemudian dengan
‫kata kunci yang berbeda di sini, tentu saja.
‫Dan kami hanya akan melakukannya di sini untuk pemesanan ini.
‫Tetapi sekali lagi saya membuat semacam solusi yang dapat digunakan kembali di sini.
‫Bagaimanapun, sekarang di rute kami, pada dasarnya kami membutuhkan middleware, yang
‫akan berjalan untuk semua permintaan.
‫Dan middleware itu, yang akan mengambil peringatan
‫dari string kueri dan memasukkan pesan peringatan ke
‫respons kami. penduduk setempat.
‫Jadi, router.
‫gunakan viewController. peringatan.
‫Jadi, ini adalah fungsi middleware,
‫yang pada dasarnya akan berjalan untuk setiap permintaan yang masuk ke
‫router ini, jadi pada
‫dasarnya untuk semua permintaan ke situs web kami.
‫Sekarang mari kita buat middleware itu di
‫viewsController kita.
‫Jadi, ekspor. permintaan
‫peringatan, tanggapan, dan berikutnya.
‫Jadi, peringatan
‫itu adalah permintaan. pertanyaan. peringatan.
‫Jadi, mari kita gunakan struktur ini sekali lagi.
‫Dan katakanlah jika peringatan sama dengan pemesanan, jadi peringatan yang
‫kita tempatkan di sini di string kueri, nah,
‫dalam kasus
‫itu, katakanlah respons. penduduk setempat. peringatan
‫akan pemesanan Anda berhasil,
‫silakan periksa email Anda untuk konfirmasi.
‫Dan kami juga harus menambahkan
‫beberapa frasa lain, yaitu yang ini, jika pemesanan Anda tidak, pilih
‫ini, jangan langsung muncul di sini, silakan kembali
‫lagi nanti.
‫Dan
‫bagian terakhir ini karena Stripe
‫secara spesifik mengatakan dalam dokumentasi mereka bahwa terkadang
‫webhook dipanggil sedikit setelah URL sukses dipanggil.
‫Dalam hal ini, URL sukses itu kemudian akan
‫menampilkan semua tur saat ini, tetapi hanya setelah
‫itu, webhook akan
‫dipanggil dan tur akan dibuat di database kami.
‫Oleh karena itu, pemesanan baru tidak akan langsung
‫muncul di halaman Pemesanan Saya.
‫Tapi tentu saja, semuanya masih bekerja dengan baik dalam kasus itu.
‫Jadi, saya cukup memuat ulang, tetapi nanti kami akan memperbaiki masalah itu.
‫Sekarang kita hanya perlu memanggil middleware berikutnya.
‫Dan itu sebenarnya.
‫Sekali lagi, kami hanya melakukan ini di sini untuk peringatan yang sama dengan pemesanan,
‫tetapi sekarang kami dapat menggunakan ini di semua
‫tempat di situs web kami dengan menyetel kata kunci peringatan
‫dan string kueri yang berbeda.
‫Dengan ini, kami menempatkan pesan ini di sini ke res. penduduk setempat. peringatan.
‫Sekali lagi, template dasar kami kemudian akan mengambilnya
‫dan menampilkannya di sini ke dalam properti peringatan data ini.
‫Jadi, yang tersisa untuk dilakukan sekarang adalah pergi ke index. js dan
‫baca lansiran dari sini lalu tampilkan.
‫Jadi, itu seharusnya cukup mudah.
‫Di sini, di depan umum, mari kita lakukan dengan benar di index.
‫Dan hal pertama adalah kita benar-benar perlu mengimpor
‫fungsi alerts.
‫Itu bukan aplikasi.
‫Ada di sini di index.
‫Oke.
‫Dan kemudian di sini, pada dasarnya mari kita membaca peringatan itu.
‫Jadi, const alertMessage, katakanlah, adalah
‫dokumen. querySelector, lalu
‫elemen body, titik dataset. peringatan.
‫Jadi, hanya jika ada peringatan,
‫tentu saja, maka tunjukkan peringatan
‫dengan
‫sukses dan pesan peringatan.
‫Dan sekarang satu hal kecil yang ingin
‫saya lakukan adalah mengubah sedikit fungsi showAlert di sini karena
‫kita sebenarnya memiliki banyak teks sekarang.
‫Dan waktu standar lansiran ditampilkan
‫tidak akan cukup untuk benar-benar membaca semua teks.
‫Jadi, Anda lihat di sini bahwa setelah lima
‫detik, peringatan itu disembunyikan.
‫Mari kita benar-benar mengizinkan
‫pengguna untuk menentukan jumlah detik peringatan itu ditampilkan.
‫Kami akan melakukannya sebagai default lima detik.
‫Di sini, kita cukup menghitung waktu dikalikan 1.000 untuk
‫mengubahnya menjadi milidetik.
‫Seperti ini, semua fungsi akan bekerja di
‫mana-mana dengan lima detik.
‫Mari kita membuatnya menjadi tujuh detik jika
‫kita tidak menentukan apa pun.
‫Tapi jika kita mau, kita bisa mengganti tujuh ini.
‫Jadi, saya akan melakukannya sekarang
‫di sini dan benar-benar meletakkannya di layar selama 20 detik.
‫Baiklah.
‫Saya pikir itu seharusnya.
‫Saya harap itu masuk akal.
‫Sekarang mari kita dengan cepat mengkompilasi bundel kita.
‫Itu npm run build, lalu ketuk pelengkapan otomatis.
‫Itu juga membutuhkan sedikit waktu.
‫Tapi sekarang sudah selesai.
‫Sekarang mari kita terapkan untuk terakhir kalinya dengan
‫harapan itu benar-benar berfungsi.
‫Jadi, git komit.
‫Jadi, pesan Stripe.
‫Dan untuk terakhir kalinya, git push heroku master.
‫Sekarang mari kita uji dengan membeli tur lagi di sini.
‫Mari kita dapatkan City Wanderer kali ini.
‫Oh, saya baru tahu ada pesan di sini.
‫Itu tidak baik.
‫Dan Anda melihat bahwa itu menghilang setelah 20 detik.
‫Jadi, sepertinya sekarang, secara default,
‫kelas peringatan ini akan selalu ditempatkan di sini.
‫(tertawa)
‫Ya.
‫Itu karena di sini seharusnya alertMessage dan
‫bukan hanya alert.
‫Tapi bagaimanapun, sekarang mari kita uji apakah pesan
‫itu benar ketika kita memesan tur.
‫Oke.
‫Sekarang mari kita tunggu saja.
‫Ini dia.
‫Memang, ada pesan kami.
‫Sangat cantik.
‫Juga, tur kami muncul di sini.
‫Dan Anda melihat bahwa itu benar-benar tinggal di sini untuk waktu yang lama.
‫Jadi, itu juga berhasil.
‫Ayo cepat...
‫Dan pertama, kita benar-benar perlu membangun kembali bundel di sini.
‫Kemudian kami dapat menambahkan semuanya
‫ke area pementasan kami, Perbaikan bug peringatan pesan.
‫Jadi, ini
‫adalah beberapa (tertawa) pesan yang terdengar sangat profesional di sini.
‫Sekarang satu dorongan terakhir untuk Heroku.
‫Sekarang ketika kita memuat halaman kita, kita
‫seharusnya tidak melihat pesan peringatan.
‫Dan memang, sekarang semuanya bersih.
‫Jadi, sekarang saya dapat mengatakan bahwa setidaknya untuk
‫saat ini, proyek ini benar-benar selesai.
‫Sekali lagi, kerja bagus, selamat, dan selamat karena
‫mungkin menjadi salah satu dari sedikit orang yang benar-benar berhasil sampai
‫akhir proyek dan benar-benar membangun situs web
‫yang indah ini dan juga API yang sekarang dapat
‫Anda masukkan ke dalam portofolio Anda dan tunjukkan
‫pada dunia.