1 00:00:01,220 --> 00:00:03,730 ‫-: Dalam video ini, mari kita 2 00:00:03,730 --> 00:00:06,333 ‫buat jenis middleware khusus yang disebut param middleware. 3 00:00:07,920 --> 00:00:11,460 ‫Jadi param middleware adalah middleware yang hanya berjalan untuk 4 00:00:11,460 --> 00:00:13,940 ‫parameter tertentu, jadi pada dasarnya, 5 00:00:13,940 --> 00:00:17,450 ‫ketika kita memiliki parameter tertentu di URL kita. 6 00:00:17,450 --> 00:00:20,000 ‫Sekarang dalam contoh kita di sini, 7 00:00:20,000 --> 00:00:25,000 ‫satu-satunya parameter yang mungkin kita miliki di URL rute kita adalah id, bukan? 8 00:00:25,320 --> 00:00:28,120 ‫Jadi kita bisa menulis middleware yang 9 00:00:28,120 --> 00:00:31,100 ‫hanya berjalan ketika id ini ada di 10 00:00:31,100 --> 00:00:34,570 ‫URL, oke, jadi izinkan saya menunjukkan cara melakukannya. 11 00:00:34,570 --> 00:00:38,000 ‫Sebenarnya cukup sederhana, jadi ada di 12 00:00:39,690 --> 00:00:43,260 ‫router kami dan kemudian metode param, oke. 13 00:00:43,260 --> 00:00:46,210 ‫Jadi di sini kita tentukan terlebih dahulu 14 00:00:46,210 --> 00:00:48,890 ‫parameter yang sebenarnya ingin kita cari, jadi 15 00:00:48,890 --> 00:00:50,900 ‫pada dasarnya parameter yang 16 00:00:50,900 --> 00:00:54,400 ‫akan dijalankan middleware ini, dan itu disebut id, dan 17 00:00:54,400 --> 00:00:57,333 ‫tentu saja fungsi middleware kita yang sebenarnya. 18 00:00:59,060 --> 00:01:02,800 ‫Dan seperti biasa, kita memiliki akses ke permintaan 19 00:01:02,800 --> 00:01:05,070 ‫dan ke objek 20 00:01:05,070 --> 00:01:07,350 ‫respons, dan kemudian merasakan fungsi 21 00:01:07,350 --> 00:01:10,300 ‫middleware juga ke fungsi berikutnya, bukan? 22 00:01:10,300 --> 00:01:12,090 ‫Sekarang dalam fungsi 23 00:01:12,090 --> 00:01:15,370 ‫middleware param, kita sebenarnya mendapatkan akses ke argumen 24 00:01:15,370 --> 00:01:18,783 ‫keempat dan itu adalah nilai dari parameter yang dimaksud. 25 00:01:20,280 --> 00:01:23,553 ‫Jadi kami biasanya menyebutnya satu val, yang berarti nilai. 26 00:01:26,240 --> 00:01:28,720 ‫Jadi sekarang kita dapat melanjutkan dan 27 00:01:28,720 --> 00:01:30,650 ‫cukup login ke 28 00:01:30,650 --> 00:01:35,510 ‫konsol, hanya untuk melihat apakah ini benar-benar berfungsi, jadi katakanlah Tour 29 00:01:37,700 --> 00:01:40,410 ‫id adalah dan kemudian id, bukan? 30 00:01:40,410 --> 00:01:43,840 ‫Selanjutnya, kita juga harus menelepon berikutnya, kan? 31 00:01:43,840 --> 00:01:46,470 ‫Karena jika tidak, siklus respons permintaan 32 00:01:46,470 --> 00:01:48,970 ‫akan macet di fungsi 33 00:01:48,970 --> 00:01:51,630 ‫middleware ini dan tidak akan bisa 34 00:01:51,630 --> 00:01:54,570 ‫pindah ke middleware berikutnya di tumpukan, bukan? 35 00:01:54,570 --> 00:01:56,903 ‫Yang akan menjadi rute ini di sini. 36 00:01:57,860 --> 00:02:01,563 ‫Baiklah, jadi mari kita simpan dan periksa sekarang. 37 00:02:03,000 --> 00:02:05,260 ‫Dan kami menginginkannya bukan untuk 38 00:02:06,370 --> 00:02:10,100 ‫mendapatkan semua pengguna tetapi untuk mendapatkan satu Tur, bukan? 39 00:02:10,100 --> 00:02:11,940 ‫Baiklah saya tunjukkan 40 00:02:11,940 --> 00:02:16,940 ‫dulu apa yang terjadi jika kami tidak memiliki id, oke, dan sekarang, 41 00:02:17,020 --> 00:02:20,310 ‫kami tidak melihat log down di konsol kami. 42 00:02:20,310 --> 00:02:22,870 ‫Tetapi jika saya sekarang mengirim permintaan yang sama pada 43 00:02:22,870 --> 00:02:26,843 ‫rute ini di mana kami memiliki id, mari kita lihat apa yang terjadi kemudian. 44 00:02:26,843 --> 00:02:29,610 ‫Oh, itu memberitahu saya bahwa id tidak 45 00:02:29,610 --> 00:02:33,500 ‫didefinisikan, dan memang itu bukan id, jadi itu adalah kesalahan bodoh. 46 00:02:33,500 --> 00:02:36,420 ‫Jadi itu adalah val untuk nilai, kan? 47 00:02:36,420 --> 00:02:39,710 ‫Jadi ingat bagaimana saya mengatakan bahwa parameter nilai ini 48 00:02:39,710 --> 00:02:41,500 ‫adalah yang benar-benar 49 00:02:41,500 --> 00:02:44,400 ‫akan menyimpan nilai parameter id, dan tentu saja 50 00:02:44,400 --> 00:02:46,930 ‫itulah yang perlu kita gunakan di sini 51 00:02:46,930 --> 00:02:49,303 ‫untuk mendapatkan akses ke id itu. 52 00:02:50,280 --> 00:02:53,580 ‫Jadi mari kita coba lagi, dan 53 00:02:53,580 --> 00:02:56,990 ‫sekarang memang Tour id kita ada dua, kan? 54 00:02:56,990 --> 00:03:00,120 ‫Jadi log itu berasal langsung dari fungsi ini di sini. 55 00:03:00,120 --> 00:03:01,893 ‫Sekarang, yang juga ingin saya 56 00:03:01,893 --> 00:03:04,160 ‫tunjukkan kepada Anda adalah bahwa fungsi middleware 57 00:03:04,160 --> 00:03:07,003 ‫ini tidak akan berjalan untuk rute pengguna mana pun. 58 00:03:08,963 --> 00:03:13,380 ‫Jadi katakanlah kita memanggil pengguna dengan id tertentu, jadi mari 59 00:03:13,380 --> 00:03:15,593 ‫kita salin yang ini di 60 00:03:16,770 --> 00:03:20,680 ‫sini, buat permintaan baru dengan id, dan biarkan 61 00:03:20,680 --> 00:03:22,493 ‫saya menyimpannya juga. 62 00:03:25,250 --> 00:03:30,240 ‫Jadi dapatkan pengguna dan simpan ke pengguna, dan ketika saya mengirimnya ke sini, kami 63 00:03:30,240 --> 00:03:32,340 ‫tentu saja mendapatkan respons standar 64 00:03:32,340 --> 00:03:35,200 ‫kami tentang rute ini tidak ditentukan, tetapi Anda 65 00:03:35,200 --> 00:03:38,210 ‫juga melihat bahwa kami tidak memiliki log seperti sebelumnya. 66 00:03:38,210 --> 00:03:41,800 ‫Dan tentu saja karena fungsi middleware ini 67 00:03:41,800 --> 00:03:44,940 ‫hanya ditentukan di router tur kami. 68 00:03:44,940 --> 00:03:48,280 ‫Jadi dalam aplikasi mini lokal semacam ini, 69 00:03:48,280 --> 00:03:51,750 ‫sekali lagi, itulah analogi yang ingin saya buat. 70 00:03:51,750 --> 00:03:53,960 ‫Jadi pada dasarnya setiap 71 00:03:53,960 --> 00:03:58,040 ‫router adalah jenis sub-aplikasi mini, satu untuk setiap sumber daya. 72 00:03:58,040 --> 00:04:02,210 ‫Dan karena middleware ini hanya ditentukan pada router ini, 73 00:04:02,210 --> 00:04:04,300 ‫maka tentu saja, 74 00:04:04,300 --> 00:04:06,680 ‫itu hanya bagian dari tumpukan 75 00:04:06,680 --> 00:04:10,670 ‫middleware jika kita benar-benar berada di dalam sub-aplikasi ini. 76 00:04:10,670 --> 00:04:11,780 ‫Masuk akal? 77 00:04:11,780 --> 00:04:16,460 ‫Jadi misalkan kita memiliki permintaan masuk pada tur/id. 78 00:04:16,460 --> 00:04:20,110 ‫Jadi permintaan itu akan melalui semua middleware ini, jadi 79 00:04:20,110 --> 00:04:22,900 ‫pertama middleware ini, lalu yang ini, lalu 80 00:04:22,900 --> 00:04:26,190 ‫middleware ini, lalu yang ini, jadi semua ini 81 00:04:26,190 --> 00:04:28,700 ‫adalah bagian dari tumpukan middleware dan 82 00:04:28,700 --> 00:04:31,360 ‫akhirnya akan mengenai middleware ini dan karena 83 00:04:31,360 --> 00:04:33,660 ‫ini adalah sebenarnya rute 84 00:04:33,660 --> 00:04:36,650 ‫tersebut, kemudian akan masuk ke middleware tourRouter. 85 00:04:36,650 --> 00:04:40,830 ‫Oke, dan dari sana kemudian langsung masuk ke middleware ini, 86 00:04:40,830 --> 00:04:43,823 ‫dan kemudian kode ini akan dijalankan. 87 00:04:45,650 --> 00:04:48,830 ‫Dan sekali lagi, itu hanya karena ia memiliki id di rute. 88 00:04:48,830 --> 00:04:51,970 ‫Jika tidak, yah, maka ini akan diabaikan begitu 89 00:04:51,970 --> 00:04:54,540 ‫saja dan akan berpindah ke middleware 90 00:04:54,540 --> 00:04:58,097 ‫berikutnya di tumpukan, jadi ini di bawah sini, kan? 91 00:04:58,097 --> 00:05:01,770 ‫Keren, jadi begitulah cara kerja middleware param; tetapi untuk 92 00:05:01,770 --> 00:05:04,296 ‫saat ini itu tidak terlalu berguna. 93 00:05:04,296 --> 00:05:06,170 ‫Tapi kita sebenarnya bisa menggunakannya 94 00:05:06,170 --> 00:05:08,430 ‫untuk kasus penggunaan yang sangat praktis di sini. 95 00:05:08,430 --> 00:05:11,670 ‫Jadi mari kita pergi ke fungsi handler kami di 96 00:05:11,670 --> 00:05:14,800 ‫sini dan Anda melihat bahwa di semua 97 00:05:14,800 --> 00:05:19,023 ‫fungsi handler yang benar-benar menggunakan id, kami memeriksa apakah id tersebut valid. 98 00:05:20,080 --> 00:05:24,560 ‫Jadi kami melakukannya di sini dalam mendapatkan tur, dan kami 99 00:05:24,560 --> 00:05:29,470 ‫juga melakukannya di tur pembaruan, jadi di sini, dan di hapus tur. 100 00:05:29,470 --> 00:05:32,250 ‫Jadi ketiga fungsi ini memiliki kode yang sangat mirip 101 00:05:32,250 --> 00:05:34,370 ‫di mana mereka memeriksa apakah id 102 00:05:34,370 --> 00:05:38,010 ‫itu valid dan jika tidak, mereka mengirim kembali tanggapan Invalid ID ini. 103 00:05:38,010 --> 00:05:40,360 ‫Jadi kita memiliki semua kode ini 104 00:05:40,360 --> 00:05:43,100 ‫di tempat yang sama dan seperti yang sudah 105 00:05:43,100 --> 00:05:46,020 ‫Anda ketahui, bukanlah praktik yang baik untuk mengulang kode 106 00:05:46,020 --> 00:05:48,750 ‫dan jadi yang bisa kita lakukan di sini 107 00:05:48,750 --> 00:05:51,680 ‫adalah menggunakan konsep middleware param; dan lakukan pemeriksaan ini 108 00:05:51,680 --> 00:05:53,660 ‫di middleware luar yang akan 109 00:05:53,660 --> 00:05:56,483 ‫dijalankan bahkan sebelum permintaan mengenai fungsi handler ini. 110 00:05:57,690 --> 00:06:01,010 ‫Jadi mari kita salin atau potong 111 00:06:01,010 --> 00:06:04,761 ‫kode dari sini dan buat fungsi middleware 112 00:06:04,761 --> 00:06:09,761 ‫baru bernama checkID, dan tentu saja saya juga perlu mengekspornya. 113 00:06:14,010 --> 00:06:18,344 ‫Jadi checkID dan kami memiliki akses, permintaan, respons, berikutnya, 114 00:06:18,344 --> 00:06:21,980 ‫dan lagi, perlu diingat bahwa itu adalah 115 00:06:21,980 --> 00:06:25,150 ‫middleware param dan argumen keempat akan 116 00:06:25,150 --> 00:06:27,353 ‫menjadi nilai parameter. 117 00:06:29,040 --> 00:06:32,090 ‫Oke, tempel di sini, lalu 118 00:06:32,090 --> 00:06:36,570 ‫jangan lupa panggil next di akhir middleware, oke? 119 00:06:36,570 --> 00:06:38,650 ‫Dan yang juga sangat penting adalah 120 00:06:38,650 --> 00:06:41,402 ‫bahwa kami memiliki pernyataan pengembalian ini di sini, 121 00:06:41,402 --> 00:06:44,010 ‫karena jika kami tidak memiliki pengembalian ini 122 00:06:44,010 --> 00:06:47,360 ‫di sini, maka express akan mengirimkan respons ini kembali tetapi 123 00:06:47,360 --> 00:06:48,930 ‫masih akan terus 124 00:06:48,930 --> 00:06:50,550 ‫menjalankan kode dalam fungsi ini. 125 00:06:50,550 --> 00:06:52,510 ‫Jadi setelah mengirim respons, 126 00:06:52,510 --> 00:06:55,170 ‫itu akan tetap menekan fungsi berikutnya dan 127 00:06:55,170 --> 00:06:57,670 ‫akan pindah ke middleware berikutnya dan 128 00:06:57,670 --> 00:07:00,560 ‫kemudian akan mengirim respons lain ke klien. 129 00:07:00,560 --> 00:07:02,500 ‫Tapi itu benar-benar tidak diperbolehkan, 130 00:07:02,500 --> 00:07:05,930 ‫jadi ingatlah bahwa kami benar-benar mengalami kesalahan ini sebelumnya, di 131 00:07:05,930 --> 00:07:08,150 ‫mana ia memberi tahu kami bahwa 132 00:07:08,150 --> 00:07:11,520 ‫kami tidak diizinkan mengirim header setelah respons telah dikirim. 133 00:07:11,520 --> 00:07:13,030 ‫Dan itulah jenis 134 00:07:13,030 --> 00:07:14,990 ‫kesalahan yang akan kami alami jika 135 00:07:14,990 --> 00:07:17,380 ‫kami tidak memiliki pernyataan pengembalian ini, oke. 136 00:07:17,380 --> 00:07:20,880 ‫Jadi sekali lagi, pastikan bahwa setelah mengirim respons ini, 137 00:07:20,880 --> 00:07:23,460 ‫fungsinya akan kembali sehingga akan selesai 138 00:07:23,460 --> 00:07:26,350 ‫dan tidak akan pernah memanggil ini lagi. 139 00:07:26,350 --> 00:07:28,350 ‫Jadi jangan pernah lupakan itu, tapi 140 00:07:28,350 --> 00:07:30,010 ‫tentu saja kita akan 141 00:07:30,010 --> 00:07:31,720 ‫melakukan ini berkali-kali sepanjang sisa 142 00:07:31,720 --> 00:07:34,823 ‫kursus sehingga Anda akan terbiasa dengan pola seperti ini. 143 00:07:36,096 --> 00:07:39,570 ‫Jadi mari kita lanjutkan dan hapus kode berulang ini dari 144 00:07:39,570 --> 00:07:41,230 ‫semua fungsi lainnya jadi 145 00:07:44,756 --> 00:07:47,197 ‫di sini kita memilikinya lagi, dan ya. 146 00:07:49,740 --> 00:07:52,352 ‫Saya juga ingin kode ini di sini 147 00:07:52,352 --> 00:07:54,903 ‫hanya untuk memastikan bahwa fungsi 148 00:07:57,910 --> 00:08:02,510 ‫tersebut benar-benar berjalan, dan oke, jadi sekarang kita dapat menyingkirkan ini 149 00:08:02,510 --> 00:08:06,640 ‫di sini dan menggantinya dengan fungsi pengontrol yang baru dibuat. 150 00:08:06,640 --> 00:08:07,990 ‫Jadi tourController, 151 00:08:11,550 --> 00:08:13,143 ‫checkID, jadi mari kita 152 00:08:15,180 --> 00:08:18,370 ‫periksa sekarang, dan sekali lagi, hanya untuk memastikan 153 00:08:18,370 --> 00:08:19,860 ‫bahwa itu tidak berjalan 154 00:08:19,860 --> 00:08:24,350 ‫di mana kita tidak memiliki id, jadi kita tidak memiliki log 155 00:08:24,350 --> 00:08:27,810 ‫di sini, jadi semuanya masih bekerja di sisi itu. 156 00:08:27,810 --> 00:08:30,670 ‫Dan sekarang dapatkan tur dengan id biasa, 157 00:08:30,670 --> 00:08:33,883 ‫jadi id yang valid, dan mari kita lihat. 158 00:08:34,750 --> 00:08:38,040 ‫Nah, kami mendapatkan id Tour adalah log, 159 00:08:38,040 --> 00:08:40,346 ‫dan itu berarti jika 160 00:08:40,346 --> 00:08:43,563 ‫itu benar-benar menjalankan middleware checkID kami, bukan? 161 00:08:44,560 --> 00:08:46,986 ‫Dan jika sekarang kami mencoba id 162 00:08:46,986 --> 00:08:50,090 ‫yang tidak valid, maka kami mendapatkan pesan ID 163 00:08:50,090 --> 00:08:54,803 ‫Tidak Valid kami, kode kesalahan 404, dan tentu saja id tur kami. 164 00:08:56,200 --> 00:08:58,930 ‫Mari kita lakukan hal yang sama dengan tambalan, 165 00:08:58,930 --> 00:09:01,240 ‫kita sudah memiliki ID yang 166 00:09:01,240 --> 00:09:04,740 ‫tidak valid di sini dan begitu juga dengan yang ini. 167 00:09:04,740 --> 00:09:08,420 ‫Jadi, sempurna, kan? 168 00:09:08,420 --> 00:09:11,865 ‫Jadi kami tidak lagi memiliki kode checkID di penangan 169 00:09:11,865 --> 00:09:15,910 ‫pembaruan yang baru saja kami panggil pada dasarnya, tetapi ID 170 00:09:15,910 --> 00:09:18,240 ‫kami tetap diperiksa karena kami 171 00:09:18,240 --> 00:09:21,470 ‫memiliki middleware itu, jadi ini di sini. 172 00:09:21,470 --> 00:09:23,630 ‫Kami memiliki middleware itu 173 00:09:23,630 --> 00:09:26,750 ‫di tumpukan sebelum benar-benar menyentuh pembaruan tourController. 174 00:09:26,750 --> 00:09:30,200 ‫Jadi middleware ini sekarang menjadi bagian dari saluran kami 175 00:09:30,200 --> 00:09:32,770 ‫seperti yang dapat Anda bayangkan, sekarang Anda 176 00:09:32,770 --> 00:09:35,340 ‫mungkin berpendapat bahwa kami mungkin hanya 177 00:09:35,340 --> 00:09:37,530 ‫membuat fungsi sederhana yang juga 178 00:09:37,530 --> 00:09:40,220 ‫dapat memeriksa ID dan saya memanggil fungsi 179 00:09:40,220 --> 00:09:43,910 ‫itu di dalam masing-masing fungsi tur ini, dan kemudian memanggil 180 00:09:43,910 --> 00:09:47,830 ‫itu di dalam masing-masing pengontrol tur yang relevan ini; tapi 181 00:09:47,830 --> 00:09:49,410 ‫itu benar-benar bertentangan 182 00:09:49,410 --> 00:09:52,860 ‫dengan filosofi express, di mana kita harus selalu bekerja 183 00:09:52,860 --> 00:09:55,730 ‫dengan middleware stack, jadi dengan pipeline ini 184 00:09:55,730 --> 00:10:00,010 ‫sebanyak yang kita bisa, oke, dan fungsi-fungsi ini di sini, mereka 185 00:10:00,010 --> 00:10:02,850 ‫tidak perlu khawatir sama sekali tentang validasi. 186 00:10:02,850 --> 00:10:05,580 ‫Masing-masing fungsi ini hanya memiliki satu tujuan yaitu untuk 187 00:10:05,580 --> 00:10:07,540 ‫melakukan apa yang mereka katakan, 188 00:10:07,540 --> 00:10:09,200 ‫jadi yang ini hanya 189 00:10:09,200 --> 00:10:12,170 ‫mendapatkan tur, yang ini hanya membuat tur, yang ini hanya 190 00:10:12,170 --> 00:10:14,650 ‫memperbarui, dan yang ini hanya menghapus, tidak memeriksa, 191 00:10:14,650 --> 00:10:17,003 ‫tidak tidak perlu khawatir tentang semua itu. 192 00:10:18,910 --> 00:10:21,060 ‫Dan jika sekarang kita akan 193 00:10:21,060 --> 00:10:24,630 ‫menambahkan pengontrol lain di sini juga tergantung pada id, maka 194 00:10:24,630 --> 00:10:27,380 ‫itu akan secara otomatis juga memeriksa apakah id 195 00:10:27,380 --> 00:10:30,960 ‫tidak valid tanpa kita harus melakukan langkah tambahan apa pun. 196 00:10:30,960 --> 00:10:34,620 ‫Jadi ini secara otomatis akan memeriksa id 197 00:10:34,620 --> 00:10:38,670 ‫dan itu sangat berguna dan juga cara 198 00:10:38,670 --> 00:10:41,450 ‫kerja aplikasi ekspres, bagus. 199 00:10:41,450 --> 00:10:45,810 ‫Jadi kami memiliki alat lain di kotak alat ekspres kami yang 200 00:10:45,810 --> 00:10:49,493 ‫sekarang dapat kami gunakan untuk menulis aplikasi ekspres kami.