‫Dosen: Halo.
‫Sekarang mari kita membuat beberapa halaman kesalahan yang bagus untuk pengguna kita.
‫Dan untuk memulai, mari kita membuat kesalahan terlebih dahulu.
‫Jadi mari kita buka tur ini di sini.
‫Tidak, saya tidak ingin menerjemahkan.
‫Dan sekarang mari kita tambahkan sesuatu ke log ini di sini,
‫dan kemudian, tentu saja, tidak akan ditemukan.
‫Benar, dan inilah yang terlihat seperti kesalahan pada
‫saat ini.
‫Jadi sederhananya, semua JSON
‫ini di sini, sama seperti di Postman.
‫Jadi kita pernah melihat kesalahan seperti ini di sini sebelumnya.
‫Jadi, sekarang mari kita perbaiki itu.
‫Tapi pertama-tama kita benar-benar perlu memperbaiki kesalahan khusus ini.
‫Jadi sekarang kita
‫mendapatkan, tidak dapat membaca nama properti null di getTour.
‫Oke.
‫Dan itu di sini di pengontrol tampilan kami, getTour.
‫Jadi di sini, kami tidak
‫memiliki penanganan kesalahan jika tidak ada tur, kan?
‫Jadi kami memilikinya di semua penangan rute kami yang lain,
‫tetapi dalam hal ini, kami belum memilikinya.
‫Jadi mari kita tambahkan itu.
‫Jadi jika tidak ada tur, maka kembali dan
‫pergi ke middleware berikutnya dengan kesalahan aplikasi baru.
‫Dan mungkin itu belum ada di sini.
‫Dan tidak, memang tidak.
‫Jadi konst.
‫AppError sama.
‫Baiklah.
‫Kesalahan di sini tentu saja.
‫Dan kemudian katakanlah
‫tidak ada tur dengan nama itu.
‫Dan kemudian 404 untuk tidak ditemukan.
‫Oke?
‫Jadi mari kita coba lagi.
‫Dan sekarang kita harus mendapatkan kesalahan yang jauh lebih baik.
‫Dan memang, kita mendapatkan satu.
‫Jadi 404.
‫Dan perlu diingat bahwa yang ini sekarang adalah kesalahan operasional.
‫Jadi kesalahan yang kita tahu bahwa kita pada dasarnya menciptakan diri kita sendiri.
‫Dan seperti sebelumnya, itu akan menjadi penting untuk
‫strategi penanganan kesalahan kami.
‫Jadi, mari kita bicara tentang itu.
‫Dan jadi di sini kita sudah selesai.
‫Dan sekarang di pengontrol kesalahan
‫kami, kami memiliki, ingat, dua fungsi yang mengirim
‫kesalahan kembali ke klien.
‫Jadi kami memiliki yang ini di sini untuk
‫pengembangan dan yang ini untuk produksi.
‫Kemudian dalam produksi, kami membedakan
‫antara kesalahan operasional dan kesalahan lain yang tidak diketahui.
‫Benar?
‫Dan itulah sebenarnya yang baru saja kita bicarakan sebelumnya.
‫Jadi untuk kesalahan yang kami
‫ketahui, kami mengirim kembali pesan kesalahan yang sebenarnya karena kami
‫dapat yakin bahwa itu tidak akan menjadi kesalahan
‫yang tampak aneh
‫yang datang dari suatu tempat dari ekspres atau
‫catatan atau sesuatu seperti itu.
‫Sementara, di satu sisi, ketika itu adalah kesalahan yang tidak
‫diketahui, ya, kami tidak ingin membocorkan detail kesalahan.
‫Jadi sekarang dalam kasus ini, dengan situs web
‫yang dirender, kami sebenarnya akan menggunakan strategi yang sama.
‫Sekarang, yang akan
‫saya lakukan hanyalah menambahkan rendering halaman kesalahan
‫ke masing-masing fungsi ini.
‫Dan pada dasarnya, yang akan saya
‫lakukan adalah menguji apakah URL dimulai dengan slash API.
‫Jadi dalam hal ini, kami mengirimkan kesalahan semacam ini, kan.
‫Tetapi jika URL tidak dimulai dengan API, baik dalam hal ini,
‫itu berarti kita ingin membuat halaman kesalahan
‫sebagai situs web yang dirender, oke?
‫Jadi seperti yang telah kita lakukan di bagian ini.
‫Bagaimanapun, sekarang mari kita terapkan itu.
‫Jadi, kita dapat menggunakan URL asli titik permintaan.
‫Dan mungkin kita pernah menggunakan itu sebelumnya.
‫Baiklah?
‫Jadi URL asli pada dasarnya adalah seluruh URL tetapi
‫tidak dengan host.
‫Jadi kelihatannya, persis seperti rutenya.
‫Dan sekali lagi, ketika kita menekan
‫URL kita, maka rute itu dimulai dengan slash API.
‫Dan sekarang kita bisa mengujinya.
‫Jadi kita bisa menggunakan fungsi JavaScript yang disebut startWith.
‫Jadi fungsi yang tersedia untuk string.
‫Dan kemudian uji apakah itu dimulai dengan slash API.
‫Benar?
‫Dan jika ya, maka inilah yang ingin kami lakukan.
‫Jadi cukup kirimkan kesalahan sebagai JSON.
‫Tetapi jika tidak, ya, maka kami sebenarnya ingin membuat kesalahan.
‫Jadi masih res. status.
‫Dan untuk statusCode juga.
‫Tapi di sini sebenarnya di-render.
‫Kemudian kita mendapatkan nama template, dan
‫kita akan membuat template ini dalam sedetik, tapi
‫itu akan disebut error.
‫Dan kemudian data yang ingin kami kirimkan ke
‫sana untuk saat ini hanyalah judulnya.
‫Dan saya akan menambahkan
‫beberapa hal lagi setelah template benar-benar selesai.
‫Jadi ada yang tidak beres akan menjadi judul
‫halaman kesalahan ini.
‫Baiklah?
‫Oh, sebenarnya kami tidak memiliki
‫akses ke variabel permintaan di sini.
‫Dan fungsinya.
‫Jadi mari kita tambahkan itu.
‫Permintaan di sini.
‫Dan kita juga akan membutuhkannya di sini.
‫Yang ini.
‫Jadi mari kita tambahkan itu di sini juga.
‫Jadi di sini.
‫Oke.
‫Jadi, sekarang kita sebenarnya perlu membuat halaman ini, atau
‫template ini, yang disebut error.
‫Dan sekali lagi, saya sudah memiliki template sederhana untuk itu.
‫Jadi ada di dev-data, templates, dan errorTemplate.
‫Oke?
‫Jadi mari kita salin ini.
‫Dan kemudian buat tampilan untuk itu.
‫kesalahan. pesek
‫Oke.
‫Jadi di sini kita memiliki h2 sederhana yang mengatakan, uh
‫oh, ada yang tidak beres.
‫Kemudian (tertawa) beberapa emoji lucu di sana.
‫Mereka tidak benar-benar menyenangkan.
‫Dan kemudian di sini kami ingin juga dapat menyampaikan pesan.
‫Baiklah?
‫Jadi mari kita tambahkan ini sama dengan msg, hanya singkatan untuk pesan.
‫Baiklah?
‫Dan itu sebenarnya.
‫Jadi mari kita tutup itu dan mari kita sampaikan pesan itu.
‫Jadi msg kemudian diatur.
‫Dan mari kita benar-benar mengaturnya ke pesan titik kesalahan.
‫Oke?
‫Dan kami melakukannya di sini karena kami sedang dalam pengembangan.
‫Jadi ingatlah itu.
‫Mari kita juga menambahkan beberapa komentar di sini.
‫API.
‫Mari kita taruh di sini.
‫Situs web yang dirender.
‫Jadi kami melakukannya seperti ini, dengan pesan kesalahan,
‫sekali lagi karena
‫dalam pengembangan, tidak masalah jika kami membocorkan semua detail
‫kesalahan ke halaman kami, bukan?
‫Karena tidak ada yang benar-benar akan melihatnya karena, ya, kami
‫sedang dalam pengembangan.
‫Jadi itu harus bekerja sekarang.
‫Jadi yang perlu kita lakukan sekarang adalah memuat ulang halaman ini.
‫Tapi sekarang ada yang salah di sini.
‫Jadi dikatakan tidak mengirim data apa pun.
‫Jadi mari kita kembali ke sini.
‫Nah sebagai masalah pertama yang saya
‫lihat di sini, bahwa saya harus memiliki kode status dan bukan hanya status.
‫Itu saja untuk memeriksa apakah ada kesalahan di sini.
‫Oh ya.
‫Sebenarnya ada kesalahan.
‫Jadi, itu sebenarnya adalah kode status yang tidak valid.
‫Jadi di sini harus kode.
‫Mari kita simpan lagi.
‫Muat ulang.
‫Dan sekarang kita mendapatkan beberapa halaman kesalahan di sini.
‫Yah, itu tidak benar-benar diformat.
‫Tapi tetap saja, ia memiliki judul dan yang
‫lebih penting, ia memiliki pesan yang baru saja kita sampaikan.
‫Jadi tidak ada tur dengan nama itu.
‫Dan itu datang persis dari pengontrol tampilan kami.
‫Jadi langsung dari sini.
‫Jadi ingat logika di mana kita membuat kesalahan di sini
‫yang kemudian diturunkan ke kesalahan global
‫dan middleware Lint kita.
‫Benar?
‫Dan itulah yang akan mengambil
‫kesalahan ini dan mengirimkannya ke klien.
‫Sekarang dalam kasus kami, kami mendapatkan
‫kesalahan ini karena di sini di template kami, kami
‫masih lupa melakukan sesuatu.
‫Yang hanya untuk memperluas, tentu saja, template utama kami.
‫Benar?
‫Jadi kita perlu mengatakan memperluas ke template dasar.
‫Dan seperti biasa, buat blok itu di sini.
‫Jadi blokir konten.
‫Dan kemudian semua ini harus ada di sana.
‫Jadi pada dasarnya di sini kita
‫melakukan hal yang sama persis seperti yang kita lakukan di semua template lainnya.
‫Jadi pada dasarnya menyuntikkan konten ini
‫di sini ke dalam konten blog di template dasar.
‫Jadi jika kita memuat ulang sekarang, maka akhirnya terlihat seperti yang dimaksudkan.
‫Baiklah?
‫Dan sekarang, jika kita benar-benar memiliki beberapa kesalahan dalam kode kita,
‫dan sekali lagi mari kita katakan
‫bahwa kita tidak memiliki penanganan kesalahan ini di
‫sini, maka tentu saja seluruh kesalahan bocor ke klien.
‫Jadi tidak bisa membaca nama properti null.
‫Dan tentunya kita tidak ingin pengunjung website
‫kita mengalami error seperti ini bukan?
‫Tidak ada yang akan benar-benar mengerti apa artinya itu.
‫Dan dalam penangan kesalahan produksi kita, sekarang
‫mari kita selesaikan itu.
‫Jadi di sini di pengontrol kesalahan kita, sekarang
‫mari kita terapkan logika yang sama yang kita miliki di sini.
‫Jadi pengujian apakah kita sedang menangani API atau tidak.
‫Dan tentu saja ada cara yang lebih elegan
‫untuk melakukan ini.
‫Misalnya, Anda dapat memiliki satu middleware
‫penanganan kesalahan yang sepenuhnya terpisah hanya untuk API,
‫dan satu untuk situs web yang dirender, bukan?
‫Tapi sekali lagi, saya hanya ingin membuatnya tetap sederhana di sini.
‫Oke?
‫Jadi dalam hal ini, itulah tujuan utama saya.
‫Baiklah.
‫Mari kita pilih semua ini.
‫Oh, apa yang terjadi di sana?
‫Ah, ini dia.
‫Oke.
‫Jadi itu untuk API.
‫Dan sekarang kita benar-benar akan memiliki sesuatu yang sangat mirip.
‫Jadi yang ini, sekali lagi, untuk situs web yang dirender.
‫Sebut saja B di sini dan A untuk yang ini.
‫Jadi hanya untuk memisahkannya sedikit lebih baik.
‫Jadi kita punya dan kemudian B di sini.
‫Bagaimanapun, ini akan terlihat sedikit mirip dengan yang ini.
‫Jadi jika kita memiliki kesalahan operasional, maka pada dasarnya halaman kesalahan
‫akan terlihat seperti
‫yang kita miliki di sini sebelumnya.
‫Tetapi jika itu adalah kesalahan pemrograman atau tidak
‫diketahui, maka kami tidak menginginkan pesan yang lengkap, tetapi
‫hanya pesan yang sangat umum.
‫Jadi sesuatu seperti silakan coba lagi nanti.
‫Baiklah?
‫Sekarang mari kita lihat kesalahan seperti apa yang kita dapatkan di sini.
‫Dan ternyata, kita mendapatkan sesuatu yang disebut
‫pernyataan jika kesepian di sini.
‫Benar.
‫Jadi ya, Lint tidak
‫benar-benar ingin kita hanya memiliki if di dalam blok else.
‫Dan saya setuju bahwa
‫ini bukan praktik pengkodean yang bagus.
‫Dan sebenarnya, mari kita perbaiki itu dengan
‫menyingkirkan hal lain ini di sini.
‫Berikan simpanan.
‫Dan kemudian kesalahan itu hilang.
‫Tetapi sekarang kita perlu memastikan bahwa ini
‫benar-benar mengakhiri siklus respons permintaan.
‫Jadi kita harus kembali ke sini dan ke sini juga.
‫Baiklah.
‫Sekarang, kesalahan ESLint lain, tidak perlu lagi setelah pengembalian.
‫Dan memang, itu benar juga.
‫Dan saya sebenarnya telah mengikuti
‫aturan ini selama kursus karena saya sendiri menyukainya
‫sebagai praktik pengkodean.
‫Jadi, ya, mari kita singkirkan hal lain di sini.
‫Saya benar-benar percaya, dan saya sudah lama mempercayainya,
‫bahwa itu terlihat jauh lebih bagus tanpa pernyataan if else ini,
‫tetapi hanya dengan if, seperti ini di sini, dan
‫kemudian sertakan else di luar itu.
‫Oke, itulah yang kita miliki di sini sekarang.
‫Mari kita juga menempatkan A dan B di sini.
‫B.
‫Dan sebenarnya, mari kita lakukan hal yang sama persis di sini.
‫Jadi kembali.
‫Kembalikan yang ini juga.
‫Lalu di sini, A dan B juga.
‫Jadi, itu sebenarnya terlihat lebih bersih bagi saya.
‫Sekarang kita memiliki A di sini dan A
‫di sini lagi, tetapi, yah, tidak apa-apa untuk saat ini.
‫Baiklah.
‫Jadi kembali ke sini.
‫Kembali ke sini.
‫Dan sebelum ia berteriak padaku, ayo singkirkan ini.
‫Dan itu lebih baik lagi.
‫Jadi taruh ini di sini.
‫Dan memang seharusnya begitu.
‫Baiklah?
‫Mari kita demi
‫kelengkapan menyalin komentar ini di sini juga.
‫Dan kemudian panggil yang ini B lagi.
‫Baiklah.
‫Sempurna.
‫Mari kita salin yang ini di sini
‫juga ke fungsi pengembangan.
‫Karena saat ini, setelah kami mengirim kembali kesalahan
‫itu, kami benar-benar tidak memiliki cara untuk melihat kesalahan yang lengkap.
‫Baiklah, jadi, singkirkan ini agar lebih terlihat.
‫Dan sekarang itu indah.
‫Oke.
‫Jadi mari kita keluar
‫dari sini sekarang sehingga kita dapat memulai aplikasi produksi kita.
‫Jadi pada dasarnya menjalankannya sekarang dalam produksi.
‫Dan kami memiliki skrip
‫untuk itu yang disebut npm run start production.
‫Oke?
‫Jadi jika kita mengujinya sekarang maka
‫kita seharusnya tidak lagi melihat string ini di sini, ingat?
‫Karena pada titik ini, kami tidak memiliki penanganan kesalahan
‫untuk nama tur yang tidak valid seperti ini.
‫Oke?
‫Benar?
‫Karena kita
‫dalam produksi, dan itu bukan kesalahan operasional,
‫ya, kami tidak ingin melihat ini.
‫Dan itulah yang baru saja kami kodekan sebelumnya.
‫Dan memang, ini adalah pesan kesalahan yang lebih umum.
‫Benar?
‫Tetapi jika kita meletakkannya kembali di sini di pengontrol tampilan, jadi jika
‫kita mengembalikan penanganan kesalahan ini, tentu
‫saja, karena ini di sini sekarang akan
‫menjadi kesalahan operasional, maka tentu saja kita akan mendapatkan
‫string kesalahan itu.
‫Karena itu selalu menyenangkan
‫untuk menunjukkan pesan yang ramah kepada pengguna.
‫Tapi seperti yang Anda lihat, itu sebenarnya tidak terjadi.
‫Jadi mengapa begitu?
‫Nah, kita berada dalam kesalahan produksi.
‫Kami berada di situs web yang dirender.
‫Dan memang, kami memiliki kesalahan operasional.
‫Sehingga ...
‫Kami memiliki ini di tempat.
‫Dan memang, itu harus bekerja seperti yang kita harapkan.
‫Baiklah, mari kita coba masuk ke konsol
‫pesan titik kesalahan hanya
‫untuk melihat apakah kita benar-benar mendapatkannya pada saat ini.
‫Baiklah.
‫Muat ulang orang ini.
‫Dan begitulah kesalahannya.
‫Tapi tetap saja, itu sangat aneh.
‫Jadi itu memang mencatat seluruh kesalahan.
‫Sangat aneh.
‫Karena entah kenapa, pesannya juga tidak ada.
‫Jadi mari kita jalankan lagi dalam pengembangan.
‫Jadi npm mulai.
‫Baiklah.
‫Dan di sini untuk beberapa alasan, ia mendapat akses ke pesan ini.
‫Jadi itu berarti bahwa di pengontrol tampilan kami,
‫kami benar-benar mengatur pesan itu dengan benar.
‫Jalankan dalam produksi lagi.
‫Jadi ini adalah hal-hal yang tidak kita sukai, kan?
‫Jadi mari kita lihat di mana kesalahan kita
‫dalam produksi sebenarnya dibuat.
‫Dan itu di sini.
‫Jadi objek kesalahan yang kita gunakan di sini dalam
‫produksi adalah salinan dari kesalahan ini, bukan?
‫Jadi salah satu yang masuk ke middleware ini.
‫Jadi mari kita lihat keduanya di
‫konsol.
‫Jadi pesan titik kesalahan.
‫Dan kemudian juga pesan titik kesalahan.
‫Jadi lakukan itu lagi.
‫Oke.
‫Jadi kami melihat kesalahan
‫itu, jadi kesalahan yang langsung masuk ke fungsi middleware
‫kami, memang memiliki pesan tersebut.
‫Tapi kemudian yang kita copy, jadi error,
‫entah kenapa tidak.
‫Jadi trik yang kita lakukan di
‫sini, untuk beberapa alasan tidak menyalin pesan dengan
‫itu, oke?
‫Jadi mari kita lakukan perbaikan cepat untuk itu.
‫Dan katakanlah pesan titik kesalahan sama dengan pesan titik kesalahan.
‫Baiklah?
‫Dan itu harus diperbaiki, semoga.
‫Ah, baiklah.
‫Ini dia.
‫Benar.
‫Jadi sekarang Anda melihat bahwa mereka memang sama.
‫Dan itulah masalahnya.
‫Baiklah?
‫Jadi tanpa ini, sebenarnya
‫semua kesalahan tidak akan berfungsi dengan benar.
‫Jadi jika kita meletakkan ini di
‫sini dan mencoba masuk misalnya, jadi admin@natours. saya
‫Jadi Anda lihat, kami juga mendapatkan kesalahan yang tidak ditentukan di sini.
‫Baiklah.
‫Dan itu sekali lagi karena kita sedang
‫dalam produksi dan objek kesalahan kita tidak menyalin pesan dengan benar.
‫Saya tidak yakin mengapa saya tidak menangkap yang
‫ini ketika kami benar-benar menerapkan ini.
‫Tapi mungkin saya tidak mengujinya dengan cara yang cukup menyeluruh.
‫Oke?
‫Lagi pula, jika kita mencoba ini
‫sekarang, sekarang kita mendapatkan pesan kesalahan yang benar yang
‫kita harapkan.
‫Baiklah.
‫Besar.
‫Jadi itu terpecahkan.
‫Dan itu benar-benar mengakhiri video ini.
‫Jadi
‫kesimpulannya, kami sekarang memiliki strategi
‫penanganan kesalahan yang berfungsi untuk pengembangan, seperti sebelumnya, dan
‫juga untuk produksi.
‫Dan kemudian di masing-masing dari mereka, pada dasarnya kami memiliki dua cabang.
‫Seseorang mengirimkan pesan kesalahan untuk API, yang
‫persis seperti yang kita miliki
‫sebelumnya, dan sekarang kita juga memiliki semacam penangan untuk
‫situs web yang dirender.
‫Jadi dalam hal ini, kami merender template kesalahan kami.
‫Kemudian dalam produksi, kami juga membedakan
‫antara situs web yang dirender dan API.
‫Dan seperti sebelumnya,
‫di dalam masing-masing cabang ini, kami
‫juga membedakan antara kesalahan
‫operasi dan kesalahan yang tidak diketahui.
‫Jadi operasional dan tidak diketahui.
‫Dan kemudian di dalam dirender, juga operasional dan tidak diketahui.
‫Demikian pula untuk situs web
‫yang dirender, jika kami memiliki kesalahan operasional, jadi yang
‫tepercaya, maka kami mengirim pesan kesalahan tepercaya kami.
‫Tetapi jika kita tidak mempercayai kesalahannya,
‫jadi ketika kita
‫tidak mengetahuinya, maka kita cukup mengirim pesan umum ini kembali ke pengguna.
‫Sangat bagus.
‫Mari kita berhenti di sini dan kembali ke
‫pengembangan dan menyelesaikan kuliah ini.
‫Jadi sampai jumpa di yang berikutnya.