1 00:00:01,220 --> 00:00:03,730 ‫-: In diesem Video erstellen wir 2 00:00:03,730 --> 00:00:06,333 ‫eine spezielle Art von Middleware namens Param-Middleware. 3 00:00:07,920 --> 00:00:11,460 ‫Param-Middleware ist also Middleware, die nur für bestimmte Parameter 4 00:00:11,460 --> 00:00:13,940 ‫ausgeführt wird, also im Grunde, 5 00:00:13,940 --> 00:00:17,450 ‫wenn wir einen bestimmten Parameter in unserer URL haben. 6 00:00:17,450 --> 00:00:20,000 ‫In unserem Beispiel hier ist der 7 00:00:20,000 --> 00:00:25,000 ‫einzige Parameter, den wir möglicherweise in unserer Routen-URL haben, die ID, oder? 8 00:00:25,320 --> 00:00:28,120 ‫Und so können wir Middleware schreiben, 9 00:00:28,120 --> 00:00:31,100 ‫die nur läuft, wenn diese ID in der 10 00:00:31,100 --> 00:00:34,570 ‫URL vorhanden ist. Okay, ich zeige Ihnen, wie es geht. 11 00:00:34,570 --> 00:00:38,000 ‫Es ist eigentlich ganz einfach, also auf 12 00:00:39,690 --> 00:00:43,260 ‫unserem Router und dann auf der param-Methode, okay. 13 00:00:43,260 --> 00:00:46,210 ‫Also geben wir hier zuerst den Parameter an, 14 00:00:46,210 --> 00:00:48,890 ‫nach dem wir eigentlich suchen wollen, also 15 00:00:48,890 --> 00:00:50,900 ‫im Grunde den Parameter, 16 00:00:50,900 --> 00:00:54,400 ‫für den diese Middleware laufen soll, und er heißt 17 00:00:54,400 --> 00:00:57,333 ‫id, und dann natürlich unsere eigentliche Middleware-Funktion. 18 00:00:59,060 --> 00:01:02,800 ‫Und wie üblich haben wir Zugriff auf das 19 00:01:02,800 --> 00:01:05,070 ‫Request- und das Response-Objekt, 20 00:01:05,070 --> 00:01:07,350 ‫und dann spürt eine Middleware-Funktion 21 00:01:07,350 --> 00:01:10,300 ‫auch die nächste Funktion auf, oder? 22 00:01:10,300 --> 00:01:12,090 ‫In einer Parameter-Middleware-Funktion 23 00:01:12,090 --> 00:01:15,370 ‫erhalten wir nun tatsächlich Zugriff auf ein viertes 24 00:01:15,370 --> 00:01:18,783 ‫Argument, und dieses ist der Wert des fraglichen Parameters. 25 00:01:20,280 --> 00:01:23,553 ‫Daher nennen wir das normalerweise val, was für Wert steht. 26 00:01:26,240 --> 00:01:28,720 ‫Und jetzt können wir es einfach 27 00:01:28,720 --> 00:01:30,650 ‫in die Konsole 28 00:01:30,650 --> 00:01:35,510 ‫einloggen, nur um zu sehen, ob das tatsächlich funktioniert. Sagen wir 29 00:01:37,700 --> 00:01:40,410 ‫also, Tour-ID ist und dann ID, richtig? 30 00:01:40,410 --> 00:01:43,840 ‫Als nächstes müssen wir auch als nächstes anrufen, oder? 31 00:01:43,840 --> 00:01:46,470 ‫Denn sonst bleibt der Request-Response-Zyklus 32 00:01:46,470 --> 00:01:48,970 ‫in dieser Middleware-Funktion 33 00:01:48,970 --> 00:01:51,630 ‫hängen und kann nicht zur 34 00:01:51,630 --> 00:01:54,570 ‫nächsten Middleware im Stack übergehen, oder? 35 00:01:54,570 --> 00:01:56,903 ‫Das werden diese Routen hier unten sein. 36 00:01:57,860 --> 00:02:01,563 ‫In Ordnung, also speichern wir es und sehen Sie es sich jetzt an. 37 00:02:03,000 --> 00:02:05,260 ‫Und wir möchten, dass es 38 00:02:06,370 --> 00:02:10,100 ‫nicht für alle Benutzer gilt, sondern für eine Tour, oder? 39 00:02:10,100 --> 00:02:11,940 ‫Lassen Sie mich 40 00:02:11,940 --> 00:02:16,940 ‫Ihnen zuerst zeigen, was passiert, wenn wir keine ID haben, okay, und 41 00:02:17,020 --> 00:02:20,310 ‫jetzt sehen wir in unserer Konsole kein Log-Down. 42 00:02:20,310 --> 00:02:22,870 ‫Aber wenn ich jetzt die gleiche Anfrage auf 43 00:02:22,870 --> 00:02:26,843 ‫dieser Route schicke, wo wir die ID haben, mal sehen, was dann passiert. 44 00:02:26,843 --> 00:02:29,610 ‫Oh, es sagt mir, dass id nicht definiert 45 00:02:29,610 --> 00:02:33,500 ‫ist, und tatsächlich ist es nicht id, also war das ein dummer Fehler. 46 00:02:33,500 --> 00:02:36,420 ‫Es ist also Wertsache, oder? 47 00:02:36,420 --> 00:02:39,710 ‫Denken Sie also daran, wie ich sagte, dass 48 00:02:39,710 --> 00:02:41,500 ‫dieser Wertparameter tatsächlich 49 00:02:41,500 --> 00:02:44,400 ‫den Wert des id-Parameters enthält, und den 50 00:02:44,400 --> 00:02:46,930 ‫müssen wir dann natürlich hier verwenden, 51 00:02:46,930 --> 00:02:49,303 ‫um auf diese ID zuzugreifen. 52 00:02:50,280 --> 00:02:53,580 ‫Versuchen wir es noch einmal, und jetzt 53 00:02:53,580 --> 00:02:56,990 ‫haben wir tatsächlich die Tour-ID ist zwei, oder? 54 00:02:56,990 --> 00:03:00,120 ‫Das Protokoll kam also direkt von dieser Funktion hier. 55 00:03:00,120 --> 00:03:01,893 ‫Was ich Ihnen 56 00:03:01,893 --> 00:03:04,160 ‫jetzt auch zeigen möchte, ist, dass 57 00:03:04,160 --> 00:03:07,003 ‫diese Middleware-Funktion für keine der Benutzerrouten ausgeführt wird. 58 00:03:08,963 --> 00:03:13,380 ‫Nehmen wir an, wir rufen einen Benutzer mit einer bestimmten ID 59 00:03:13,380 --> 00:03:15,593 ‫an, also kopieren wir diese 60 00:03:16,770 --> 00:03:20,680 ‫hierher, erstellen eine neue Anfrage mit einer ID und lassen 61 00:03:20,680 --> 00:03:22,493 ‫sie mich auch speichern. 62 00:03:25,250 --> 00:03:30,240 ‫Also Benutzer holen und an Benutzer speichern, und wenn ich es hier sende, erhalten 63 00:03:30,240 --> 00:03:32,340 ‫wir natürlich unsere Standardantwort, dass 64 00:03:32,340 --> 00:03:35,200 ‫diese Route nicht definiert ist, aber Sie sehen 65 00:03:35,200 --> 00:03:38,210 ‫auch, dass wir kein Protokoll wie zuvor hatten. 66 00:03:38,210 --> 00:03:41,800 ‫Und das liegt natürlich daran, dass diese Middleware-Funktion 67 00:03:41,800 --> 00:03:44,940 ‫nur in unserem Tourrouter spezifiziert ist. 68 00:03:44,940 --> 00:03:48,280 ‫Bei dieser Art von lokaler Minianwendung ist 69 00:03:48,280 --> 00:03:51,750 ‫das also wieder die Analogie, die ich gerne mache. 70 00:03:51,750 --> 00:03:53,960 ‫Im Grunde ist jeder 71 00:03:53,960 --> 00:03:58,040 ‫Router eine Art Mini-Unteranwendung, eine für jede Ressource. 72 00:03:58,040 --> 00:04:02,210 ‫Da diese Middleware nur auf diesem Router angegeben ist, 73 00:04:02,210 --> 00:04:04,300 ‫ist sie natürlich 74 00:04:04,300 --> 00:04:06,680 ‫nur ein Teil des Middleware-Stack, 75 00:04:06,680 --> 00:04:10,670 ‫wenn wir uns tatsächlich in dieser Unteranwendung befinden. 76 00:04:10,670 --> 00:04:11,780 ‫Macht Sinn? 77 00:04:11,780 --> 00:04:16,460 ‫Nehmen wir also an, wir haben eine eingehende Anfrage zu Touren/ID. 78 00:04:16,460 --> 00:04:20,110 ‫Also durchläuft diese Anfrage dann all diese Middleware, also 79 00:04:20,110 --> 00:04:22,900 ‫zuerst diese Middleware, dann diese, dann diese 80 00:04:22,900 --> 00:04:26,190 ‫Middleware, dann diese, also alle sind Teil des 81 00:04:26,190 --> 00:04:28,700 ‫Middleware-Stack und dann trifft sie schließlich 82 00:04:28,700 --> 00:04:31,360 ‫auf diese Middleware und da dies so 83 00:04:31,360 --> 00:04:33,660 ‫ist tatsächlich die Route, 84 00:04:33,660 --> 00:04:36,650 ‫wird es dann in die tourRouter-Middleware gelangen. 85 00:04:36,650 --> 00:04:40,830 ‫Okay, und von dort geht es dann direkt in diese 86 00:04:40,830 --> 00:04:43,823 ‫Middleware, und dann wird dieser Code ausgeführt. 87 00:04:45,650 --> 00:04:48,830 ‫Und das nur, weil es eine ID in der Route hat. 88 00:04:48,830 --> 00:04:51,970 ‫Wenn nicht, dann wird dies einfach ignoriert 89 00:04:51,970 --> 00:04:54,540 ‫und direkt zur nächsten 90 00:04:54,540 --> 00:04:58,097 ‫Middleware im Stack verschoben, also hier unten, oder? 91 00:04:58,097 --> 00:05:01,770 ‫Cool, so funktioniert die Param-Middleware; aber im Moment 92 00:05:01,770 --> 00:05:04,296 ‫ist es nicht wirklich nützlich. 93 00:05:04,296 --> 00:05:06,170 ‫Aber wir können es hier 94 00:05:06,170 --> 00:05:08,430 ‫tatsächlich für einen sehr praktischen Anwendungsfall verwenden. 95 00:05:08,430 --> 00:05:11,670 ‫Gehen wir also zu unseren Handlerfunktionen hier und 96 00:05:11,670 --> 00:05:14,800 ‫Sie sehen, dass wir in allen Handlerfunktionen, 97 00:05:14,800 --> 00:05:19,023 ‫die die ID tatsächlich verwenden, überprüfen, ob die ID gültig ist. 98 00:05:20,080 --> 00:05:24,560 ‫Also machen wir es hier in Get Tour, und wir 99 00:05:24,560 --> 00:05:29,470 ‫machen es auch in Update Tour, also hier und in Delete Tour. 100 00:05:29,470 --> 00:05:32,250 ‫Alle diese drei Funktionen haben also diesen sehr ähnlichen Code, 101 00:05:32,250 --> 00:05:34,370 ‫bei dem sie prüfen, ob die 102 00:05:34,370 --> 00:05:38,010 ‫ID gültig ist, und wenn nicht, senden sie diese ungültige ID-Antwort zurück. 103 00:05:38,010 --> 00:05:40,360 ‫Wir haben also all diesen Code 104 00:05:40,360 --> 00:05:43,100 ‫an derselben Stelle und wie Sie bereits wissen, 105 00:05:43,100 --> 00:05:46,020 ‫ist es keine gute Vorgehensweise, Code zu wiederholen. 106 00:05:46,020 --> 00:05:48,750 ‫Daher können wir hier das Konzept der 107 00:05:48,750 --> 00:05:51,680 ‫Param-Middleware verwenden; und führen Sie diese Prüfung hier in 108 00:05:51,680 --> 00:05:53,660 ‫einer externen Middleware durch, die 109 00:05:53,660 --> 00:05:56,483 ‫ausgeführt wird, bevor die Anforderung diese Handlerfunktionen erreicht. 110 00:05:57,690 --> 00:06:01,010 ‫Lassen Sie uns also den Code 111 00:06:01,010 --> 00:06:04,761 ‫von hier kopieren oder tatsächlich ausschneiden und eine 112 00:06:04,761 --> 00:06:09,761 ‫neue Middleware-Funktion namens checkID erstellen, die ich natürlich auch exportieren muss. 113 00:06:14,010 --> 00:06:18,344 ‫Also checkID und wir haben Zugriff, Anfrage, Antwort, Weiter und noch 114 00:06:18,344 --> 00:06:21,980 ‫einmal. Denken Sie daran, dass es sich um eine 115 00:06:21,980 --> 00:06:25,150 ‫Param-Middleware handelt und das vierte Argument der 116 00:06:25,150 --> 00:06:27,353 ‫Wert des Parameters ist. 117 00:06:29,040 --> 00:06:32,090 ‫Okay, fügen Sie es hier ein und vergessen 118 00:06:32,090 --> 00:06:36,570 ‫Sie dann nicht, am Ende der Middleware als nächstes anzurufen, in Ordnung? 119 00:06:36,570 --> 00:06:38,650 ‫Und was auch sehr wichtig 120 00:06:38,650 --> 00:06:41,402 ‫ist, ist, dass wir diese Rückgabeanweisung hier 121 00:06:41,402 --> 00:06:44,010 ‫haben, denn wenn wir diese Rückgabe hier 122 00:06:44,010 --> 00:06:47,360 ‫nicht hätten, dann würde Express diese Antwort zurücksenden, aber 123 00:06:47,360 --> 00:06:48,930 ‫den Code in 124 00:06:48,930 --> 00:06:50,550 ‫dieser Funktion weiterhin ausführen. 125 00:06:50,550 --> 00:06:52,510 ‫Und so wird es nach 126 00:06:52,510 --> 00:06:55,170 ‫dem Senden der Antwort immer noch diese nächste Funktion 127 00:06:55,170 --> 00:06:57,670 ‫treffen und es würde zur nächsten Middleware übergehen 128 00:06:57,670 --> 00:07:00,560 ‫und dann eine weitere Antwort an den Client senden. 129 00:07:00,560 --> 00:07:02,500 ‫Aber das ist wirklich nicht 130 00:07:02,500 --> 00:07:05,930 ‫erlaubt, also denken Sie daran, dass wir diesen Fehler tatsächlich schon 131 00:07:05,930 --> 00:07:08,150 ‫einmal hatten, als er uns sagte, dass 132 00:07:08,150 --> 00:07:11,520 ‫wir keine Header senden dürfen, nachdem die Antwort bereits gesendet wurde. 133 00:07:11,520 --> 00:07:13,030 ‫Und das ist die 134 00:07:13,030 --> 00:07:14,990 ‫Art von Fehler, auf die wir stoßen 135 00:07:14,990 --> 00:07:17,380 ‫würden, wenn wir diese return-Anweisung nicht hätten, okay. 136 00:07:17,380 --> 00:07:20,880 ‫Stellen Sie also noch einmal sicher, dass die Funktion nach dem 137 00:07:20,880 --> 00:07:23,460 ‫Senden dieser Antwort zurückkehrt, damit sie beendet 138 00:07:23,460 --> 00:07:26,350 ‫wird und diese nie als nächstes aufgerufen wird. 139 00:07:26,350 --> 00:07:28,350 ‫Vergiss das also nie, aber wir 140 00:07:28,350 --> 00:07:30,010 ‫werden das natürlich im 141 00:07:30,010 --> 00:07:31,720 ‫weiteren Verlauf des Kurses mehrmals machen 142 00:07:31,720 --> 00:07:34,823 ‫und du wirst dich an diese Art von Muster gewöhnen. 143 00:07:36,096 --> 00:07:39,570 ‫Lassen Sie uns also diesen wiederholten Code aus all diesen 144 00:07:39,570 --> 00:07:41,230 ‫anderen Funktionen entfernen, damit 145 00:07:44,756 --> 00:07:47,197 ‫wir ihn hier wieder haben, und ja. 146 00:07:49,740 --> 00:07:52,352 ‫Ich möchte diesen Code auch hier, 147 00:07:52,352 --> 00:07:54,903 ‫um sicherzustellen, dass die Funktion 148 00:07:57,910 --> 00:08:02,510 ‫tatsächlich ausgeführt wird, und in Ordnung, also können wir ihn jetzt 149 00:08:02,510 --> 00:08:06,640 ‫hier loswerden und durch unsere neu erstellte Controller-Funktion ersetzen. 150 00:08:06,640 --> 00:08:07,990 ‫Also tourController, 151 00:08:11,550 --> 00:08:13,143 ‫checkID, also lass uns 152 00:08:15,180 --> 00:08:18,370 ‫das jetzt und gut noch einmal überprüfen, nur 153 00:08:18,370 --> 00:08:19,860 ‫um sicherzustellen, dass es 154 00:08:19,860 --> 00:08:24,350 ‫nicht dort läuft, wo wir keine ID haben, also haben wir hier 155 00:08:24,350 --> 00:08:27,810 ‫kein Log, also funktioniert alles noch auf dieser Seite. 156 00:08:27,810 --> 00:08:30,670 ‫Und jetzt erhalten Sie eine Tour mit einer 157 00:08:30,670 --> 00:08:33,883 ‫regulären ID, also einer gültigen ID, und mal sehen. 158 00:08:34,750 --> 00:08:38,040 ‫Nun, wir erhalten die Tour-ID als log, 159 00:08:38,040 --> 00:08:40,346 ‫und das heißt, wenn 160 00:08:40,346 --> 00:08:43,563 ‫sie tatsächlich unsere checkID-Middleware ausgeführt hat, richtig? 161 00:08:44,560 --> 00:08:46,986 ‫Und wenn wir jetzt 162 00:08:46,986 --> 00:08:50,090 ‫eine ungültige ID versuchen, erhalten wir 163 00:08:50,090 --> 00:08:54,803 ‫unsere Meldung "Ungültige ID", den 404-Fehlercode und natürlich unsere Tour-ID. 164 00:08:56,200 --> 00:08:58,930 ‫Machen wir das gleiche mit dem Patch, 165 00:08:58,930 --> 00:09:01,240 ‫wir haben hier schon eine 166 00:09:01,240 --> 00:09:04,740 ‫ungültige ID und so läuft es auch auf diesem. 167 00:09:04,740 --> 00:09:08,420 ‫Also perfekt, oder? 168 00:09:08,420 --> 00:09:11,865 ‫Wir haben also nicht mehr den checkID-Code im 169 00:09:11,865 --> 00:09:15,910 ‫Update-Handler, den wir gerade aufgerufen haben, aber unsere ID 170 00:09:15,910 --> 00:09:18,240 ‫wird immer noch überprüft, 171 00:09:18,240 --> 00:09:21,470 ‫weil wir diese Middleware haben, also hier. 172 00:09:21,470 --> 00:09:23,630 ‫Wir haben diese Middleware im 173 00:09:23,630 --> 00:09:26,750 ‫Stack, bevor sie tatsächlich auf das Update tourController trifft. 174 00:09:26,750 --> 00:09:30,200 ‫Diese Middleware ist jetzt also Teil unserer Pipeline, wie 175 00:09:30,200 --> 00:09:32,770 ‫Sie sich das vorstellen können. Jetzt 176 00:09:32,770 --> 00:09:35,340 ‫könnten Sie argumentieren, dass wir einfach 177 00:09:35,340 --> 00:09:37,530 ‫eine einfache Funktion erstellen könnten, 178 00:09:37,530 --> 00:09:40,220 ‫die auch nach der ID suchen könnte, 179 00:09:40,220 --> 00:09:43,910 ‫und ich rufe diese Funktion in jeder dieser Tourfunktionen auf 180 00:09:43,910 --> 00:09:47,830 ‫und rufe dann auf es in jedem dieser relevanten Tour-Controller; 181 00:09:47,830 --> 00:09:49,410 ‫aber das würde 182 00:09:49,410 --> 00:09:52,860 ‫der Express-Philosophie wirklich widersprechen, wo wir immer mit dem 183 00:09:52,860 --> 00:09:55,730 ‫Middleware-Stack arbeiten sollten, also mit dieser Pipeline 184 00:09:55,730 --> 00:10:00,010 ‫so viel wie möglich, okay, und diese Funktionen hier müssen sich 185 00:10:00,010 --> 00:10:02,850 ‫also überhaupt nicht um die Validierung kümmern. 186 00:10:02,850 --> 00:10:05,580 ‫Jede dieser Funktionen hat nur einen Zweck, nämlich zu tun, 187 00:10:05,580 --> 00:10:07,540 ‫was sie sagen, also ruft diese 188 00:10:07,540 --> 00:10:09,200 ‫nur die Tour ab, diese 189 00:10:09,200 --> 00:10:12,170 ‫erstellt nur eine Tour, diese aktualisiert nur und diese löscht 190 00:10:12,170 --> 00:10:14,650 ‫nur, sie prüft nicht, sie tut es über 191 00:10:14,650 --> 00:10:17,003 ‫all das muss man sich keine Sorgen machen. 192 00:10:18,910 --> 00:10:21,060 ‫Und wenn wir hier nun 193 00:10:21,060 --> 00:10:24,630 ‫auch noch abhängig von der ID einen weiteren Controller hinzufügen 194 00:10:24,630 --> 00:10:27,380 ‫würden, dann würde das automatisch auch prüfen, ob 195 00:10:27,380 --> 00:10:30,960 ‫die ID ungültig ist, ohne dass wir weitere Schritte unternehmen müssen. 196 00:10:30,960 --> 00:10:34,620 ‫Dies wird also automatisch nach der ID 197 00:10:34,620 --> 00:10:38,670 ‫suchen und das ist wirklich praktisch und auch, 198 00:10:38,670 --> 00:10:41,450 ‫wie Express-Apps funktionieren sollten, großartig. 199 00:10:41,450 --> 00:10:45,810 ‫Wir haben also ein weiteres Tool in unserer Express-Toolbox, mit 200 00:10:45,810 --> 00:10:49,493 ‫dem wir jetzt unsere Express-Anwendungen schreiben können.