1 00:00:03,650 --> 00:00:08,385 Wir hatten bereits einen vollwertigen 2 00:00:08,385 --> 00:00:12,485 REST-API-Server entwickelt, der Express und MongoDB im Rahmen dieses Kurses verwendet. 3 00:00:12,485 --> 00:00:16,965 Damit dieser Server sinnvoll mit unserem Kunden kommunizieren kann, 4 00:00:16,965 --> 00:00:19,590 werden wir einige kleinere Anpassungen vornehmen, damit er die 5 00:00:19,590 --> 00:00:22,440 richtigen Daten zurückgibt, damit 6 00:00:22,440 --> 00:00:24,780 unsere Client-Implementierung 7 00:00:24,780 --> 00:00:28,935 effizienter mit den Daten arbeiten kann, die von unserer Server-Site zurückgegeben werden. 8 00:00:28,935 --> 00:00:30,410 Um dies zu tun, 9 00:00:30,410 --> 00:00:36,580 lassen Sie uns in dieser Übung an ein paar Anpassungen unserer Server-Site arbeiten. 10 00:00:36,580 --> 00:00:39,215 Bevor Sie mit dieser Übung beginnen, 11 00:00:39,215 --> 00:00:42,410 gehe ich davon aus, dass Sie 12 00:00:42,410 --> 00:00:46,430 die vorherige Lektion zur Integration des Winkelclients und 13 00:00:46,430 --> 00:00:55,395 des Servers nicht durchgeführt haben, da Sie diese Lektion durch die Spezialisierung React ausführen. 14 00:00:55,395 --> 00:01:01,190 Die Änderungen, die ich am Server vornehmen werde, gehen daher davon aus, dass 15 00:01:01,190 --> 00:01:07,430 die Version des Servers, den Sie ändern, vor der vorherigen Lektion liegt. 16 00:01:07,430 --> 00:01:11,540 Falls Sie diese Lektion auf dem Winkel-Client durchgeführt 17 00:01:11,540 --> 00:01:16,505 haben, werden einige der Änderungen, die Sie an Ihrem Server vorgenommen haben, 18 00:01:16,505 --> 00:01:22,495 in dieser Übung erneut wiederholt, sodass Sie diesen Teil der Änderungen überspringen können. 19 00:01:22,495 --> 00:01:26,055 Gehen Sie zu unserem Server im Editor. 20 00:01:26,055 --> 00:01:29,125 Bevor wir mit der Arbeit auf dem Server beginnen, 21 00:01:29,125 --> 00:01:33,530 würde ich vorschlagen, dass Sie alle Bilder herunterladen, die ich 22 00:01:33,530 --> 00:01:38,380 als ZIP-Datei in den Übungsressourcen namens images.zip bereitgestellt habe. 23 00:01:38,380 --> 00:01:43,160 Entpacken Sie die Datei und erhalten Sie dann alle Bilder von dort und kopieren Sie diese Bilder 24 00:01:43,160 --> 00:01:48,290 in den Ordner für öffentliche Bilder auf unserem Server. 25 00:01:48,290 --> 00:01:55,010 Sie sehen also, dass ich hier alle Bilder in meinen öffentlichen Image-Ordner kopiert habe, 26 00:01:55,010 --> 00:01:58,160 da unser Server derjenige ist, der 27 00:01:58,160 --> 00:02:02,275 all diese Bilder für unsere Client-Anwendung bereitstellen wird. 28 00:02:02,275 --> 00:02:07,835 Als nächstes gehen wir zum CORS und passen die Whitelist hier an. 29 00:02:07,835 --> 00:02:11,565 Also, für unsere React-Client-Anwendung, 30 00:02:11,565 --> 00:02:15,275 wenn wir mit dem garn-start-Befehl gestartet haben, 31 00:02:15,275 --> 00:02:18,470 läuft es unter Ihrem Computername:3001. 32 00:02:18,470 --> 00:02:22,040 Also, jede Anfrage, die von unserem Standort an 33 00:02:22,040 --> 00:02:25,760 den Server kommt, trägt dies als Ursprung dort. 34 00:02:25,760 --> 00:02:30,380 Deshalb werde ich das in meine Whitelist hinzufügen, damit 35 00:02:30,380 --> 00:02:35,390 alle CORS-Probleme automatisch behoben werden. 36 00:02:35,390 --> 00:02:40,985 Also, wenn ich hier in die Datei cors.js in meiner Whitelist gehe, 37 00:02:40,985 --> 00:02:49,460 lassen Sie mich den 38 00:02:49,460 --> 00:02:55,640 Namen des http://my Computers hinzufügen: 3001 und das ist 39 00:02:55,640 --> 00:02:58,610 der 40 00:02:58,610 --> 00:03:02,075 Ursprung, von dem mein Client die Anfragen, die an diesen Server kommen, stammt. 41 00:03:02,075 --> 00:03:07,075 Auf diese Weise würde mein CORS keine Probleme für meinen Kunden verursachen. 42 00:03:07,075 --> 00:03:11,690 Als nächstes müssen wir einige der Routen aktualisieren, um 43 00:03:11,690 --> 00:03:17,690 die Abfrageparameter und auch einige kleinere andere Anpassungen zu behandeln. 44 00:03:17,690 --> 00:03:21,280 Lassen Sie mich mit der Datei promoRouter.js beginnen. 45 00:03:21,280 --> 00:03:25,010 Das ist einfach, aktualisiert zu werden. 46 00:03:25,010 --> 00:03:27,570 Also, wenn wir in die Datei promoRouter.js gehen, 47 00:03:27,570 --> 00:03:32,360 in der promOuter Datei für die get-Anfrage, die wir 48 00:03:32,360 --> 00:03:37,610 hier bekommen, anstatt Promotions mit einem leeren JavaScript-Objekt 49 00:03:37,610 --> 00:03:47,320 zu finden, hier würde ich die req.query als Parameter für die Promotions hier liefern, 50 00:03:47,320 --> 00:03:49,680 dasselbe mit dem Leader Router auch. 51 00:03:49,680 --> 00:03:52,745 Also, lassen Sie mich zur Datei leaderRouter.js gehen. 52 00:03:52,745 --> 00:03:54,815 Im Leader Router auch 53 00:03:54,815 --> 00:04:00,545 hier, wo Sie Leaders.Find mit dem leeren JavaScript-Objekt finden 54 00:04:00,545 --> 00:04:06,685 , ersetzen Sie stattdessen das durch die req.query, so dass die Abfrageparameter übergeben werden. 55 00:04:06,685 --> 00:04:14,260 Also, hier werden wir in der featured:true als Abfrageparameter hier übergeben. 56 00:04:14,260 --> 00:04:16,945 Nun, nachdem wir diese beiden angepasst haben, 57 00:04:16,945 --> 00:04:19,340 lassen Sie uns jetzt am Geschirrrouter arbeiten. 58 00:04:19,340 --> 00:04:22,115 Also, gehen Sie in die Datei dishRouter.js, 59 00:04:22,115 --> 00:04:26,310 sogar im Dish Router auch das gleiche Update hier. 60 00:04:26,310 --> 00:04:31,200 Also, gehen Sie in dieses Gerichte.Finden Sie in der Get-Methode hier, 61 00:04:31,200 --> 00:04:33,945 ändern Sie das zu req.query. 62 00:04:33,945 --> 00:04:38,070 Damit wurde mein Dish Router-Update abgeschlossen. 63 00:04:38,070 --> 00:04:42,085 Also, wir haben jetzt den Promo-Router, den Führer 64 00:04:42,085 --> 00:04:43,850 und den Geschirrrouter aktualisiert, 65 00:04:43,850 --> 00:04:48,050 dann werden wir den Lieblings-Router aktualisieren. 66 00:04:48,050 --> 00:04:54,380 Nun hätten Sie den bevorzugten Router als Teil Ihrer vierten Aufgabe implementiert. 67 00:04:54,380 --> 00:04:56,530 Jetzt, im Lieblings-Router, 68 00:04:56,530 --> 00:04:58,910 werden Sie sehen, dass 69 00:04:58,910 --> 00:05:01,010 ich Ihnen für den Lieblings-Router nicht den verbleibenden Teil zeige, weil 70 00:05:01,010 --> 00:05:03,435 Sie das als Teil Ihrer Aufgabe hätten tun sollen. 71 00:05:03,435 --> 00:05:11,520 Lassen Sie mich zunächst Ihre Aufmerksamkeit auf die get-Methode für die Favoriterouter.route:dishid lenken. 72 00:05:11,520 --> 00:05:17,405 Jetzt werde ich diese Get-Methode verwenden, um sicherzustellen, dass 73 00:05:17,405 --> 00:05:25,460 das spezifische Gericht mit der Schale Id bereits ein Favorit für den Benutzer ist. 74 00:05:25,460 --> 00:05:29,130 Also, anstatt einfach getoperation.supported 75 00:05:29,130 --> 00:05:36,165 zu sagen, werde ich nur das Vorhandensein dieser Get-Operation nutzen und dann werden wir sagen, 76 00:05:36,165 --> 00:05:47,500 Favorites.Findone und wir sagen user: req.user. _id. 77 00:05:49,220 --> 00:05:59,340 Also, wir werden die Favoriten für diesen bestimmten Benutzer finden und dann sagen wir dann 78 00:06:03,070 --> 00:06:25,530 Favoriten und fangen Fehler als nächstes. 79 00:06:25,530 --> 00:06:35,265 Dann ähnlich hier, werden wir in den Fehler hier hinzufügen, nächste Fehler hier. 80 00:06:35,265 --> 00:06:37,380 Also, in diesem dann, 81 00:06:37,380 --> 00:06:39,495 wenn wir die Favoriten bekommen, 82 00:06:39,495 --> 00:06:45,360 dann werden wir überprüfen, ob nicht Favoriten. 83 00:06:45,360 --> 00:06:47,690 Also, wenn es keine Favoriten für 84 00:06:47,690 --> 00:06:53,900 diesen Benutzer gibt, dann existiert offensichtlich das Gericht, nach dem wir suchen, nicht, 85 00:06:53,900 --> 00:07:07,520 also werden wir res.StatusCode 200, 86 00:07:07,520 --> 00:07:14,370 setHeader, Content-Type, 87 00:07:17,230 --> 00:07:36,735 application/json zurückgeben und dann sagen wir, dass existiert falsch. 88 00:07:36,735 --> 00:07:44,215 Was wir hier angeben, ist, dass, wenn sie zu diesem Endpunkt mit einem Gericht Id gemacht wird, 89 00:07:44,215 --> 00:07:52,835 diese existiert Flagge hier wird auf true gesetzt, wenn dieses Gericht Teil meiner Favoriten ist. 90 00:07:52,835 --> 00:07:55,290 Wenn dieses Gericht nicht Teil meiner Favoriten ist, 91 00:07:55,290 --> 00:07:58,100 werde ich dort existiert Flagge auf false setzen. 92 00:07:58,100 --> 00:08:01,190 Also hier sehen Sie, dass da ich keine Favoriten habe, also 93 00:08:01,190 --> 00:08:04,770 existiert automatisch falsch an dieser Stelle sein sollte. 94 00:08:04,770 --> 00:08:13,020 Also, wir werden sagen existiert falsch und dann werden wir die Favoriten hier zurückgeben. 95 00:08:13,180 --> 00:08:19,090 Nun, offensichtlich, in diesem Fall wären die Favoriten an dieser Stelle null. 96 00:08:19,090 --> 00:08:26,440 Andernfalls, was bedeutet, dass Favoriten nicht null ist, 97 00:08:26,440 --> 00:08:32,750 so dass wir sagen, wenn favorites.Dishes.indexOf. 98 00:08:36,840 --> 00:08:45,995 Also, wir werden nach Req.params.dishid suchen. 99 00:08:45,995 --> 00:08:51,220 Also, wir werden diese Favoriten Gerichte Array suchen, um zu 100 00:08:51,220 --> 00:08:56,605 sehen, ob dieses Gericht dort existiert und wenn es nicht existiert, 101 00:08:56,605 --> 00:09:00,525 offensichtlich wird dies hier einen negativen Index zurückgeben. 102 00:09:00,525 --> 00:09:02,340 In diesem Fall 103 00:09:02,340 --> 00:09:05,440 werde ich auch genau das gleiche wie hier zurückgeben. 104 00:09:05,440 --> 00:09:08,630 Also, wenn es einen negativen Index zurückgibt, bedeutet das, dass, 105 00:09:08,630 --> 00:09:12,260 obwohl dieser bestimmte Benutzer eine Reihe von Favoriten hat, 106 00:09:12,260 --> 00:09:16,190 dieses spezifische Gericht nicht in 107 00:09:16,190 --> 00:09:22,340 der Liste seiner Favoriten existiert, also deshalb wird es hier falsch zurückgeben. 108 00:09:22,340 --> 00:09:30,255 Nun, sonst bedeutet das, dass das Gericht in der Liste der Favoriten existiert. 109 00:09:30,255 --> 00:09:31,859 Also, in diesem Fall 110 00:09:31,859 --> 00:09:36,670 werde ich Statuscode zurückgeben 200 existiert ist wahr. 111 00:09:36,670 --> 00:09:43,825 Auf diese Weise, wenn der Benutzer eine Get-Operation auf diesem Endpunkt mit 112 00:09:43,825 --> 00:09:52,015 der /Favorites/dishid ausführt, wo die Dish Id als Parameter hier angegeben wird, 113 00:09:52,015 --> 00:09:55,630 als Anforderungsparameter hier, 114 00:09:55,630 --> 00:10:00,650 dann werden wir prüfen, ob dieses Gericht in den Favoriten existiert. 115 00:10:00,650 --> 00:10:05,775 Wenn keiner der Favoriten für diesen Benutzer vorhanden ist, geben wir eine existiert false zurück. 116 00:10:05,775 --> 00:10:08,120 In ähnlicher Weise, wenn die Favoriten vorhanden sind 117 00:10:08,120 --> 00:10:12,320 , aber dieses bestimmte Gericht nicht in den Favoriten existiert, werden wir false zurückgeben, 118 00:10:12,320 --> 00:10:13,910 sonst werden wir true zurückgeben. 119 00:10:13,910 --> 00:10:20,260 Also diese existiert Flagge kann von meinem Client verwendet werden, um zu überprüfen, ob dieses Gericht 120 00:10:20,260 --> 00:10:27,755 Teil der Liste der Lieblingsgerichte für diesen Benutzer ist oder nicht. 121 00:10:27,755 --> 00:10:30,139 Auch während wir in Favoriten sind, 122 00:10:30,139 --> 00:10:33,410 wenn wir irgendwelche Änderungen an den Favoriten vornehmen, 123 00:10:33,410 --> 00:10:37,870 wollen wir in der Lage sein, den Benutzer und Gerichte Informationen, 124 00:10:37,870 --> 00:10:39,535 die Favoriten, zu füllen, bevor wir zurückkehren. 125 00:10:39,535 --> 00:10:43,240 Zum Beispiel, in dem Beitrag, den wir tun, 126 00:10:43,240 --> 00:10:48,470 wenn wir die Favoriten dann an dieser Stelle speichern, 127 00:10:48,470 --> 00:10:55,470 möchten wir zuerst Favoriten machen. 128 00:10:55,620 --> 00:11:06,380 FindById, also weil wir gerade die Änderungen vorgenommen haben, sagen 129 00:11:07,740 --> 00:11:15,325 wir favorite_id und wir werden sowohl den Benutzer als auch 130 00:11:15,325 --> 00:11:25,490 die Gerichte in den Favoriten füllen. 131 00:11:25,740 --> 00:11:32,420 Wenn die Favoriten zurückgegeben werden, 132 00:11:32,610 --> 00:11:36,940 werden wir stattdessen die Favoriten zurückgeben. 133 00:11:36,940 --> 00:11:40,440 Also, lassen Sie mich diese Änderung hier vornehmen. 134 00:11:40,440 --> 00:11:46,910 Also, wir werden das von hier ausschneiden und dann innerhalb der dann 135 00:11:46,910 --> 00:11:49,645 werden wir die Favoriten zurückgeben. 136 00:11:49,645 --> 00:11:53,510 Nachdem wir die Favoriten gespeichert haben, 137 00:11:53,510 --> 00:11:54,980 suchen wir danach, nach 138 00:11:54,980 --> 00:11:58,285 der FavoriteByID und geben dann diesen Favoriten 139 00:11:58,285 --> 00:12:03,940 hier zurück, so dass wir dann Lieblings Return und Statuscode sagen. 140 00:12:03,940 --> 00:12:05,355 Diese Änderung sollten wir vornehmen. 141 00:12:05,355 --> 00:12:08,180 Wenn Sie dies bereits in Ihren Favoriten implementiert 142 00:12:08,180 --> 00:12:09,760 haben, müssen Sie diese Änderung nicht vornehmen. 143 00:12:09,760 --> 00:12:13,310 Aber was wir tun, ist, wenn wir Änderungen an den Favoriten vornehmen, 144 00:12:13,310 --> 00:12:17,380 wir werden sowohl die Benutzer- als auch Gerichte Informationen füllen und dann diesen Wert zurückgeben, 145 00:12:17,380 --> 00:12:22,360 weil unser React-Client erwartet, dass dies da ist. 146 00:12:22,360 --> 00:12:24,685 Jetzt, die gleiche Art von Änderung, 147 00:12:24,685 --> 00:12:28,350 müssen wir Variable b machen, speichern Sie die Änderungen. 148 00:12:28,350 --> 00:12:33,125 Also in der Post hier, 149 00:12:33,125 --> 00:12:36,090 werden wir eine Änderung daran vornehmen, 150 00:12:36,090 --> 00:12:42,705 also sagen wir favorites.save und dann werden wir favorites.findById tun und diese Änderung vornehmen. 151 00:12:42,705 --> 00:12:45,210 In ähnlicher Weise unter der Schüssel ID, 152 00:12:45,210 --> 00:12:47,095 auch in der Post, 153 00:12:47,095 --> 00:12:51,070 werden Sie ähnlich sein, wenn Sie Änderungen an den Favoriten vornehmen, 154 00:12:51,070 --> 00:12:57,715 wird zuerst danach suchen und dann sowohl den Benutzer als auch die Gerichte füllen und dann zurückgeben, 155 00:12:57,715 --> 00:12:59,910 und dann in ähnlicher Weise im anderen Teil. 156 00:12:59,910 --> 00:13:06,290 Also, Sie müssen dies in Ihrem vierten Auftrag implementiert haben. 157 00:13:06,290 --> 00:13:09,010 Nehmen Sie also diese zusätzliche Änderung vor, wo Sie 158 00:13:09,010 --> 00:13:12,350 den Benutzer und Gerichte füllen, bevor Sie den Wert zurückgeben. 159 00:13:12,350 --> 00:13:14,685 Auch mit dem Löschen 160 00:13:14,685 --> 00:13:17,385 werden wir hier die gleichen Änderungen vornehmen. 161 00:13:17,385 --> 00:13:19,890 Sie bemerken also, dass 162 00:13:19,890 --> 00:13:21,830 ich im Löschen diese Änderung hier bereits vorgenommen habe. 163 00:13:21,830 --> 00:13:27,085 Nachdem wir die Änderungen an den Favoriten gespeichert 164 00:13:27,085 --> 00:13:29,480 haben, suchen wir dann nach den Favoriten und 165 00:13:29,480 --> 00:13:33,465 kehren dann zurück, nachdem Sie sowohl den Benutzer als auch die Gerichte und die Favoriten ausgefüllt haben. 166 00:13:33,465 --> 00:13:36,505 Das ist es, was unser React-Client von uns erwartet. 167 00:13:36,505 --> 00:13:38,145 Also, auch für das Löschen, 168 00:13:38,145 --> 00:13:39,995 werden wir die gleichen Änderungen vornehmen. 169 00:13:39,995 --> 00:13:44,115 Nun, damit wird mein Lieblings-Router aktualisiert, 170 00:13:44,115 --> 00:13:48,575 so dass wir fortfahren, users.js als nächstes zu aktualisieren. 171 00:13:48,575 --> 00:13:52,370 Schließlich werden wir die Datei users.js aktualisieren. 172 00:13:52,370 --> 00:13:57,060 Nun, in der Datei users.js müssen wir 173 00:13:57,060 --> 00:14:05,245 hier in einem anderen Feld router.options hinzufügen, 174 00:14:05,245 --> 00:14:10,610 weil manchmal eine Post-Anfrage, wie Sie 175 00:14:10,610 --> 00:14:16,315 mit dem Login gesehen haben, zuerst die Optionen senden, um zu überprüfen, 176 00:14:16,315 --> 00:14:21,610 insbesondere mit Autos, ob die Post-Anfrage erlaubt ist. 177 00:14:21,610 --> 00:14:30,080 Deshalb werden wir den Kurs mit Optionen hier überprüfen und dann 178 00:14:31,860 --> 00:14:35,450 werden wir einfach 179 00:14:39,960 --> 00:14:43,045 eine Statusmeldung 180 00:14:43,045 --> 00:14:46,180 von 200 als Antwort darauf zurückgeben. 181 00:14:46,180 --> 00:14:52,960 Für jeden Endpunkt unter Benutzern, wenn wir die Optionen erhalten, geben 182 00:14:52,960 --> 00:14:56,530 wir hier einfach den Status 200 zurück. 183 00:14:56,530 --> 00:15:03,580 Jetzt die Login-Funktion, die wir früher implementiert hatten, 184 00:15:03,580 --> 00:15:07,470 hatten wir einfach passport.authenticate 185 00:15:07,470 --> 00:15:12,930 local hier gemacht und die wir nach den verbleibenden Werten hier überprüft. 186 00:15:12,930 --> 00:15:15,215 Nun, diese passport.authenticate local, 187 00:15:15,215 --> 00:15:17,600 wenn der Benutzer nicht authentifiziert wird, 188 00:15:17,600 --> 00:15:21,800 gibt es einfach eine nicht autorisierte in der Antwortnachricht. 189 00:15:21,800 --> 00:15:28,380 Nun, das 190 00:15:28,380 --> 00:15:30,480 ist möglicherweise nicht sehr sinnvoll für die Client-Seite, um diese Informationen anzuzeigen, deshalb werden wir 191 00:15:30,480 --> 00:15:36,310 diese Router-Post-Login-Methode 192 00:15:36,310 --> 00:15:41,765 so verbessern, dass die Authentifizierung an dieser Stelle aussagekräftigere Informationen zurückgibt. 193 00:15:41,765 --> 00:15:43,210 Also, um das zu tun, 194 00:15:43,210 --> 00:15:49,395 werden wir nicht tun, den Pass.authenticate hier drin, 195 00:15:49,395 --> 00:15:51,955 sondern wir nehmen. 196 00:15:51,955 --> 00:15:55,140 Also, lassen Sie mich das von dort entfernen und dann werden Sie sehen, 197 00:15:55,140 --> 00:15:58,930 wie ich den Routerpost hier aktualisieren werde. 198 00:15:58,930 --> 00:16:08,620 Also, wir werden Kurs mit Optionen sehen und dann werden wir die req, 199 00:16:08,620 --> 00:16:12,160 res und nächste hier einschließen. 200 00:16:12,160 --> 00:16:16,885 In diesem req, res und weiter hier 201 00:16:16,885 --> 00:16:27,954 wird passport.authenticate dies mit local aufrufen. 202 00:16:27,954 --> 00:16:31,210 Nun, wenn wir dies mit lokalen aufrufen, 203 00:16:31,210 --> 00:16:34,970 wenn Authentifizierungsfehler auftritt, 204 00:16:34,970 --> 00:16:38,240 kann die passport.authenticate gemacht werden, um 205 00:16:38,240 --> 00:16:44,230 den Fehlerwert zurückzugeben, und es wird auch den Benutzer zurückgeben, wenn es 206 00:16:44,230 --> 00:16:48,960 keinen Fehler gibt und ein dritter Parameter namens 207 00:16:48,960 --> 00:16:54,000 info, der zusätzliche Informationen enthält, die möglicherweise zurück zu der Benutzer. 208 00:16:54,000 --> 00:16:56,580 Dieser Fehler wird zurückgegeben, wenn 209 00:16:56,580 --> 00:16:59,950 ein echter Fehler in der passport.authenticate auftritt. 210 00:16:59,950 --> 00:17:03,400 Aber wenn die Benutzerinformationen 211 00:17:03,400 --> 00:17:07,645 in passport.authenticate gesendet werden, der Benutzer aber nicht existiert, 212 00:17:07,645 --> 00:17:10,490 dann wird das nicht als Fehler gezählt. 213 00:17:10,490 --> 00:17:14,690 Stattdessen wird es gezählt, als der Benutzer nicht existiert und 214 00:17:14,690 --> 00:17:19,305 diese Informationen wieder im Info-Objekt analysiert werden, das eingeht. 215 00:17:19,305 --> 00:17:21,500 Daher wird der Fehler zurückgegeben, wenn 216 00:17:21,500 --> 00:17:24,925 ein echter Fehler auftritt, der während des Authentifizierungsprozesses auftritt, 217 00:17:24,925 --> 00:17:30,820 aber die Informationen enthalten Informationen, wenn der Benutzer nicht existiert. 218 00:17:30,820 --> 00:17:36,920 Also, passport.authenticate gibt eine Nachricht zurück, die besagt, dass 219 00:17:36,920 --> 00:17:39,575 der Benutzer nicht existiert oder entweder der Benutzername 220 00:17:39,575 --> 00:17:42,850 falsch ist oder das Passwort falsch ist und so weiter. 221 00:17:42,850 --> 00:17:46,870 Diese Informationen werden also in der Info-Nachricht weitergegeben. 222 00:17:46,870 --> 00:17:49,230 Jetzt werden wir sehen, wie das für 223 00:17:49,230 --> 00:17:52,060 uns nützlich ist, wenn wir uns ein wenig später auf die Kundenseite schauen. 224 00:17:52,060 --> 00:17:55,400 Also, in dieser Situation 225 00:17:55,400 --> 00:18:01,455 werden wir dies wie folgt behandeln, 226 00:18:01,455 --> 00:18:06,810 und nicht nur, dass, wenn wir diesen 227 00:18:06,810 --> 00:18:10,220 Pass aufrufen.authenticate, wir müssen auch eine req, 228 00:18:10,220 --> 00:18:15,080 res, als die drei Parameter zu ihm übergeben. 229 00:18:15,080 --> 00:18:20,130 Also, dies ist die Struktur, wenn Sie passport.authenticate aufrufen müssen und erwarten, dass es 230 00:18:20,130 --> 00:18:25,270 Ihnen Informationen wie diese als Callback-Methode hier zurückgibt, 231 00:18:25,270 --> 00:18:27,630 also müssen Sie auch diese req, res, als 232 00:18:27,630 --> 00:18:30,250 nächstes direkt dort angeben. 233 00:18:30,250 --> 00:18:32,270 Nun, wenn dies geschieht, 234 00:18:32,270 --> 00:18:36,780 so werden wir sagen, wenn irre, 235 00:18:36,780 --> 00:18:40,425 also wenn es einen Fehler gibt, der auftritt, 236 00:18:40,425 --> 00:18:45,395 sagen wir return next error und dann lassen Sie 237 00:18:45,395 --> 00:18:51,480 den Fehler-Handler unseres Express-Routers und kümmern sich darum. 238 00:18:51,480 --> 00:18:56,755 Jetzt werden wir andere Situationen betrachten, wenn nicht Benutzer. 239 00:18:56,755 --> 00:18:59,630 Also, wenn wir diesen Punkt erreicht haben, 240 00:18:59,630 --> 00:19:02,580 dann bedeutet das, dass es kein Fehler war, der aufgetreten ist, 241 00:19:02,580 --> 00:19:05,615 sondern vielleicht konnte der Benutzer nicht gefunden werden. 242 00:19:05,615 --> 00:19:07,100 Wenn der Benutzer nicht gefunden wird, 243 00:19:07,100 --> 00:19:11,190 wird der Benutzer hier in diesem Fall auf null gesetzt. 244 00:19:11,190 --> 00:19:14,634 In dieser Situation, 245 00:19:14,634 --> 00:19:17,375 wenn der Benutzer nicht existiert, 246 00:19:17,375 --> 00:19:23,680 müssen wir in der Lage sein, Informationen zurück an die Serverseite zu übergeben. 247 00:19:23,680 --> 00:19:28,435 Also, was wir tun werden, ist, dass wir diese Informationen in diesem Format übergeben werden. 248 00:19:28,435 --> 00:19:32,020 Also, ich werde das von hier aus ausschneiden und 249 00:19:32,020 --> 00:19:36,640 es dann hier einfügen und dann werden wir das bearbeiten. 250 00:19:36,640 --> 00:19:40,704 Also, wenn der Benutzer null ist, 251 00:19:40,704 --> 00:19:45,830 dann werden wir einen Statuscode als 401 zurücksenden, was 252 00:19:45,830 --> 00:19:53,975 nicht autorisiert bedeutet, und dann werden wir Informationen Erfolg falsch zurücksenden, 253 00:19:53,975 --> 00:19:57,405 und dann werden wir das Token nicht 254 00:19:57,405 --> 00:20:00,795 zurückgeben, wir werden die Statusmeldung zurückgeben. 255 00:20:00,795 --> 00:20:03,135 Also, hier werden wir sagen 256 00:20:03,135 --> 00:20:12,670 „Login nicht erfolgreich“ und dann die dritte Information, 257 00:20:12,670 --> 00:20:18,070 wir werden diese Informationen das Objekt übergeben, das wir hier als 258 00:20:18,070 --> 00:20:25,635 der dritte Teil in der Antwortnachricht erhalten haben, die wir von unserem Server hier zurücksenden. 259 00:20:25,635 --> 00:20:28,935 Das Erfolgsflag wird also auf false gesetzt, 260 00:20:28,935 --> 00:20:32,385 der Status wird Login fehlgeschlagen gesetzt und 261 00:20:32,385 --> 00:20:36,725 die Fehlerinformationen, die in der Info übergeben werden, werden zurückgegeben. 262 00:20:36,725 --> 00:20:39,855 Beachten Sie nun, dass diese Situation auftritt 263 00:20:39,855 --> 00:20:43,125 , wenn entweder der Benutzername und das Kennwort falsch sind. 264 00:20:43,125 --> 00:20:48,600 Dies ist also kein Fehler im Fehlersinn, aber die Tatsache, dass 265 00:20:48,600 --> 00:20:54,040 die Authentifizierung weder den Benutzer noch das Kennwort des Benutzers finden konnte, ist falsch. 266 00:20:54,040 --> 00:20:58,530 Also, diese Informationen werden in die Info codiert, die hereinkommt und so dass ich 267 00:20:58,530 --> 00:21:04,590 als Fehler an meine Client-Seite weitergebe. 268 00:21:04,590 --> 00:21:09,615 Der ansonsten Teil 269 00:21:09,615 --> 00:21:15,355 wird als Req.login behandelt. 270 00:21:15,355 --> 00:21:17,220 Also, wenn dies erfolgreich ist, 271 00:21:17,220 --> 00:21:22,710 die passport.authenticate werden wir diese Methode namens Req.login zum Benutzer hinzufügen. 272 00:21:22,710 --> 00:21:24,340 Also, an diesem Punkt 273 00:21:24,340 --> 00:21:27,950 werden wir einfach das Benutzerobjekt übergeben, das wir erhalten haben. 274 00:21:27,950 --> 00:21:31,055 Also hier, wenn wir diesen Punkt erreicht haben, 275 00:21:31,055 --> 00:21:36,195 dann bedeutet das, dass das Benutzerobjekt nicht null ist und auch kein Fehler aufgetreten ist, 276 00:21:36,195 --> 00:21:40,090 so dass der Benutzer angemeldet werden kann. 277 00:21:41,080 --> 00:21:44,550 Also, wir werden sagen, irren, 278 00:21:48,960 --> 00:21:51,460 wir werden versuchen, den Benutzer anzumelden. 279 00:21:51,460 --> 00:21:58,000 Also, wir werden sagen, wenn irre und 280 00:21:58,000 --> 00:22:05,345 dann werden wir die gleiche Art von Fehlerinformationen zurückgeben, die wir hier gemacht haben. 281 00:22:05,345 --> 00:22:09,840 Also in diesem Fall, wenn Fehler, 282 00:22:13,290 --> 00:22:19,430 dann werden wir einen Statuscode als 401 übergeben und wir werden sagen, Erfolg 283 00:22:19,430 --> 00:22:25,125 ist falsch und Status als Login nicht erfolgreich, 284 00:22:25,125 --> 00:22:28,340 und dann die Fehlerinformationen, 285 00:22:29,280 --> 00:22:31,840 statt der Info, 286 00:22:31,840 --> 00:22:42,380 werden wir in übergeben „Konnte nicht in Benutzer anmelden“. 287 00:22:42,380 --> 00:22:48,960 Also, das ist die Nachricht, die wir hier zurückgeben werden, wenn der Fehler auftritt. 288 00:22:48,960 --> 00:22:53,200 Sonst wären wir hier unten. 289 00:22:53,200 --> 00:22:55,960 Also, an diesem Punkt, 290 00:22:55,960 --> 00:22:59,440 würden wir in der Lage sein, das Token zu generieren. 291 00:22:59,440 --> 00:23:02,495 Also, wenn wir bis zu diesem Punkt erreicht haben, 292 00:23:02,495 --> 00:23:06,370 bedeutet das, dass der Benutzer sich erfolgreich angemeldet hat, 293 00:23:06,370 --> 00:23:08,430 und so können wir jetzt das Token generieren. 294 00:23:08,430 --> 00:23:12,705 Also werden wir das Token basierend auf der ID des Benutzers generieren, 295 00:23:12,705 --> 00:23:18,350 und dann übergeben wir das Token an den Benutzer zurück. 296 00:23:18,350 --> 00:23:21,635 Also, hier werden wir var Token sagen, 297 00:23:21,635 --> 00:23:30,730 und dann können wir sagen res.StatusCode ist 200 und dann res.json Erfolg wahr, 298 00:23:30,730 --> 00:23:33,600 also, was bedeutet, dass der Benutzer erfolgreich angemeldet ist. 299 00:23:33,600 --> 00:23:38,490 Also, der Status wäre Login erfolgreich. 300 00:23:38,490 --> 00:23:40,605 Dann, der dritte Teil, 301 00:23:40,605 --> 00:23:42,360 anstelle des Fehlers, 302 00:23:42,360 --> 00:23:46,200 werde ich das Token zurück an den Benutzer übergeben. 303 00:23:46,200 --> 00:23:48,760 Also, wir sagen Token, 304 00:23:51,100 --> 00:23:54,675 dieses Token, das wir gerade früher erhalten haben. Dieses 305 00:23:54,675 --> 00:24:01,030 Token wird also als Token-Eigenschaft der Antwortnachricht übergeben. 306 00:24:01,030 --> 00:24:04,560 Beachten Sie hier also, dass der Erfolg auf true gesetzt ist, 307 00:24:04,560 --> 00:24:08,340 was bedeutet, dass sich der Benutzer erfolgreich angemeldet hat, 308 00:24:08,340 --> 00:24:12,290 und so kann der Benutzer an dieser Stelle weiter fortfahren. 309 00:24:12,290 --> 00:24:19,050 Dies muss innerhalb der Req.login hier getan werden. 310 00:24:19,820 --> 00:24:22,970 Also, an dieser Stelle 311 00:24:22,970 --> 00:24:27,180 werden wir die Req.login schließen. 312 00:24:27,180 --> 00:24:33,735 Beachten Sie also, dass dies in diesem Req.login hier ist. 313 00:24:33,735 --> 00:24:37,320 Also, da drin, werden wir diese drei zurückgeben. 314 00:24:37,320 --> 00:24:41,370 Also, lassen Sie mich einfach diese drei Zeilen einrücken. 315 00:24:41,720 --> 00:24:48,850 So würden wir die Protokollierungsmethode des Benutzers behandeln. 316 00:24:48,850 --> 00:24:52,230 Also, wieder, überprüfen Sie diesen Code noch einmal. 317 00:24:52,230 --> 00:24:53,950 Also, wir werden Router-Post tun, 318 00:24:53,950 --> 00:24:56,815 aber anstatt Pass authentifizieren genau dort, 319 00:24:56,815 --> 00:24:58,960 wir werden sagen, req, res, 320 00:24:58,960 --> 00:25:01,240 nächste, und dann innen hier, 321 00:25:01,240 --> 00:25:04,285 werden wir einen Reisepass authentifizieren für die lokale, 322 00:25:04,285 --> 00:25:06,560 und diese Authentifizierung wird zurück übergeben. 323 00:25:06,560 --> 00:25:09,250 So können wir eine Callback-Funktion liefern, 324 00:25:09,250 --> 00:25:11,810 und diese Callback-Funktion gibt entweder den Fehler, 325 00:25:11,810 --> 00:25:14,730 den Benutzer oder die Info hier zurück. 326 00:25:14,730 --> 00:25:16,300 Also, wenn es ein Fehler ist, 327 00:25:16,300 --> 00:25:20,735 werden wir nur zulassen, dass der Express-Fehlerbehandler sich darum kümmert. 328 00:25:20,735 --> 00:25:22,730 Wenn der Benutzer null ist, 329 00:25:22,730 --> 00:25:26,940 bedeutet dies, dass die Benutzeranmeldung fehlgeschlagen war, 330 00:25:26,940 --> 00:25:29,730 und der Grund dafür wird in der Info sein. 331 00:25:29,730 --> 00:25:36,870 Also, das wird als Infofehler in der Antwortnachricht hier zurückgegeben. 332 00:25:36,870 --> 00:25:38,790 Wenn wir zu diesem Punkt kommen, 333 00:25:38,790 --> 00:25:43,555 wird der Benutzer erfolgreich verifiziert. 334 00:25:43,555 --> 00:25:45,400 Also, dann werden wir den Benutzer einloggen. 335 00:25:45,400 --> 00:25:47,630 Also, der Pass authentifizieren, 336 00:25:47,630 --> 00:25:53,385 werden wir in dieser Methode namens Login in der req, die Anfrage Nachricht hinzufügen. 337 00:25:53,385 --> 00:25:56,770 So können wir den Login mit dem Benutzer aufrufen. 338 00:25:56,770 --> 00:25:59,355 Wenn dies einen Fehler zurückgibt, 339 00:25:59,355 --> 00:26:03,105 dann werden wir den Fehler hier entsprechend zurückgeben. 340 00:26:03,105 --> 00:26:08,590 Wenn nicht, dann haben wir den Punkt erreicht, an dem der Benutzer erfolgreich authentifiziert wird. 341 00:26:08,590 --> 00:26:12,630 So können wir hier das JSON Web Token generieren und dann 342 00:26:12,630 --> 00:26:18,315 das JSON Web Token an den Benutzer zurückgeben, um zu bestätigen, dass der Benutzer erfolgreich angemeldet ist. 343 00:26:18,315 --> 00:26:21,545 Also, das ist die Reihe von Schritten, die wir hier verwenden werden. 344 00:26:21,545 --> 00:26:25,735 Nun, der Grund, warum ich eine aufwendigere Art und Weise tue, ist, dass 345 00:26:25,735 --> 00:26:30,035 ich zwischen der Situation unterscheiden möchte, in der ein echter Fehler 346 00:26:30,035 --> 00:26:34,170 während des Authentifizierungsprozesses auftritt, im Gegensatz zu der 347 00:26:34,170 --> 00:26:39,095 Situation, in der der Benutzername ungültig ist oder das Passwort ungültig ist. 348 00:26:39,095 --> 00:26:42,860 Diese beiden Fälle werden also durch diese Situation behandelt, 349 00:26:42,860 --> 00:26:46,550 wo die Informationen die Informationen zu uns zurückbringen werden. 350 00:26:46,550 --> 00:26:48,900 Das ist also kein Fehler per se, 351 00:26:48,900 --> 00:26:52,090 aber das ist eine Situation, in der der Benutzer 352 00:26:52,090 --> 00:26:55,710 kein gültiger Benutzer ist oder das Passwort des Benutzers ungültig ist. 353 00:26:55,710 --> 00:27:01,070 So werden wir den Anmeldeprozess des Benutzers behandeln. 354 00:27:01,070 --> 00:27:03,660 Darüber hinaus werde ich 355 00:27:03,660 --> 00:27:14,825 hier eine weitere Methode namens checkJWTToken hinzufügen. 356 00:27:14,825 --> 00:27:21,100 Es ist durchaus möglich, dass, während der Client sich angemeldet hat und das JSON Web Token 357 00:27:21,100 --> 00:27:24,855 abruft, irgendwann später das JSON Web Token abläuft. 358 00:27:24,855 --> 00:27:32,840 Wenn der Benutzer also versucht, von der Clientseite mit einem abgelaufenen Token auf den Server zuzugreifen, 359 00:27:32,840 --> 00:27:35,610 kann der Server den Benutzer nicht authentifizieren. 360 00:27:35,610 --> 00:27:37,780 Daher 361 00:27:37,780 --> 00:27:42,180 möchten wir in regelmäßigen Abständen eine Gegenprüfung durchführen, um sicherzustellen, dass das JSON-Web-Token weiterhin gültig ist. 362 00:27:42,180 --> 00:27:44,975 Also, das ist der Grund, warum ich dies einschließe, 363 00:27:44,975 --> 00:27:49,620 einen anderen Endpunkt namens checkJWTToken. 364 00:27:49,620 --> 00:27:53,155 Wenn Sie also ein get to checkJWTToken durchführen, indem Sie das 365 00:27:53,155 --> 00:27:58,700 Token in den Autorisierungsheader 366 00:27:58,700 --> 00:28:02,490 einschließen, gibt dieser Aufruf einen true oder false zurück, 367 00:28:02,490 --> 00:28:06,535 um Ihnen anzuzeigen, ob das JSON-Web-Token noch gültig ist oder nicht. 368 00:28:06,535 --> 00:28:10,930 Wenn es ungültig ist, kann die Client-Seite eine weitere Anmeldung für 369 00:28:10,930 --> 00:28:15,945 den Benutzer initiieren, um bei Bedarf ein neues JSON-Web-Token zu erhalten. 370 00:28:15,945 --> 00:28:17,285 Also, um dies zu tun, 371 00:28:17,285 --> 00:28:27,109 sagen wir cors.corsWithOptions und req, 372 00:28:27,109 --> 00:28:31,385 res hier wie erwartet. 373 00:28:31,385 --> 00:28:35,670 Hier werden wir sagen, 374 00:28:39,820 --> 00:28:49,360 Pass authentifizieren jwt 375 00:28:49,360 --> 00:28:57,150 und session: false, 376 00:29:00,020 --> 00:29:07,270 und dies würde err, user, info zurückgeben. 377 00:29:09,020 --> 00:29:13,770 Also, erinnern Sie sich, wie wir verwenden den Reisepass authentifizieren früher. 378 00:29:13,770 --> 00:29:17,195 Also, wir nennen die JWT mit Sitzung falsch hier. 379 00:29:17,195 --> 00:29:21,745 Also, früher hier, sagen wir Reisepass authentifizieren lokale. 380 00:29:21,745 --> 00:29:23,535 Dies ist also für die lokale Authentifizierung. 381 00:29:23,535 --> 00:29:27,330 Dies ist also für die JSON-Web-Token-Authentifizierung. 382 00:29:27,330 --> 00:29:29,430 Also, wenn wir das aufrufen, 383 00:29:29,430 --> 00:29:33,435 dann, da dies das JSON Web Token überprüfen wird, so werden wir sagen, 384 00:29:33,435 --> 00:29:40,335 wenn irr nächsten Fehler zurückgibt, 385 00:29:40,335 --> 00:29:44,895 und dann lassen Sie den Express Error Handler sich um diese Situation kümmern. 386 00:29:44,895 --> 00:29:50,469 Dann werden wir sagen, wenn nicht Benutzer, 387 00:29:53,330 --> 00:30:00,330 wenn der Benutzer nicht existiert, dann ähnlich. 388 00:30:00,330 --> 00:30:03,510 Also, was bedeutet, dass, wenn das Benutzerobjekt 389 00:30:03,510 --> 00:30:07,810 aus dem JSON-Web-Token gefunden und dann auf den req.user geladen wurde, 390 00:30:07,810 --> 00:30:11,400 das bedeutet, dass der Benutzer ein gültiger Benutzer ist 391 00:30:11,400 --> 00:30:13,485 und so weiter fortfahren kann. 392 00:30:13,485 --> 00:30:20,330 Andernfalls werden wir sagen, dass der Benutzer nicht existiert. 393 00:30:20,330 --> 00:30:24,995 Daher müssen wir informieren, dass das JSON Web Token abgelaufen ist. 394 00:30:24,995 --> 00:30:26,180 Also, an dieser Stelle 395 00:30:26,180 --> 00:30:29,090 senden wir ein res mit 396 00:30:29,090 --> 00:30:36,545 einem Statuscode von 401. 397 00:30:36,545 --> 00:30:47,130 Also, nicht autorisiert, setHeader, Content-Type, 398 00:30:49,900 --> 00:30:56,280 application/json, und dann werden wir res zurückgeben. 399 00:30:58,680 --> 00:31:13,750 Res.JSON wird sagen, Status JWT 400 00:31:13,750 --> 00:31:17,090 ungültig und dann, 401 00:31:17,730 --> 00:31:23,690 wir werden ein Flag namens Erfolg fällt 402 00:31:23,880 --> 00:31:29,080 zurückgeben und dann, wir werden die Informationen, die wir erhalten, wenn der Benutzer 403 00:31:29,080 --> 00:31:34,460 nicht als Fehler an diesem Punkt authentifiziert. 404 00:31:36,420 --> 00:31:40,480 Andernfalls bedeutet das, dass wir diesen Punkt erreicht haben, 405 00:31:40,480 --> 00:31:43,220 dann ist der Benutzer ein gültiger Benutzer. 406 00:31:43,220 --> 00:31:44,850 Also, in diesem Fall, 407 00:31:44,850 --> 00:31:47,230 lassen Sie mich einfach diesen Code hier kopieren, 408 00:31:47,230 --> 00:31:54,070 wir werden einen Statuscode von 200 senden und dann 409 00:31:54,070 --> 00:32:02,720 wird der res.json JWT gültig und erfolgreich als wahr senden. 410 00:32:02,940 --> 00:32:09,820 Im dritten Teil senden wir die Informationen des Benutzers. 411 00:32:09,820 --> 00:32:16,000 Wenn dieser Endpunkt mit der get-Methode aufgerufen 412 00:32:16,000 --> 00:32:19,170 wird, überprüft dies, ob das Token gültig ist oder nicht. 413 00:32:19,170 --> 00:32:20,220 Wenn das Token gültig ist, 414 00:32:20,220 --> 00:32:24,020 erhalten Sie diese Antwort und vom Erfolgsflag in der Antwort 415 00:32:24,020 --> 00:32:27,770 können Sie überprüfen, ob das jsonwebtoken gültig ist oder nicht. 416 00:32:27,770 --> 00:32:32,155 Dies ist auf der Client-Seite nützlich. 417 00:32:32,155 --> 00:32:37,825 Nun, dieser Pass authentifizieren hier muss 418 00:32:37,825 --> 00:32:43,790 mit req und res als die beiden Parameter hier geliefert werden. 419 00:32:43,790 --> 00:32:47,630 Also, so nennen wir den Reisepass authentifizieren. 420 00:32:47,630 --> 00:32:49,355 Also, beachten Sie, dass, wenn Sie 421 00:32:49,355 --> 00:32:52,840 Pass authentifizieren und erwarten, dass diese Callback-Funktion hier in, 422 00:32:52,840 --> 00:33:01,825 müssen Sie bis zu diesem Punkt req.res an den Pass anhängen authentifizieren hier hinten. 423 00:33:01,825 --> 00:33:03,890 In unserem restlichen API-Server 424 00:33:03,890 --> 00:33:07,490 hatten wir unsere Kommentare so implementiert, dass die Kommentare 425 00:33:07,490 --> 00:33:12,245 Unterdokumente innerhalb des Dokuments des Dishe bildeten, 426 00:33:12,245 --> 00:33:16,540 so dass sie jedes Gericht mit seinen eigenen Kommentaren kaufen. 427 00:33:16,540 --> 00:33:19,520 Aber die Art und Weise, 428 00:33:19,520 --> 00:33:22,965 wie wir unseren React-Client implementiert haben, ist so, dass die Kommentare unabhängig von den Gerichten gehalten werden, 429 00:33:22,965 --> 00:33:27,680 und die Kommentare selbst trugen die entsprechende ID des Gerichts. 430 00:33:27,680 --> 00:33:30,400 Nun, dies sind zwei verschiedene Möglichkeiten, sowohl 431 00:33:30,400 --> 00:33:34,445 die serverseitige als auch die Client-Seite zu implementieren. 432 00:33:34,445 --> 00:33:39,685 In der Angular-Anwendung, die wir in unserer Angular-Spezialisierung implementiert sind, 433 00:33:39,685 --> 00:33:43,470 hatten wir die Unterdokumentmethode für die 434 00:33:43,470 --> 00:33:47,560 Bearbeitung von Kommentaren in unserer Angular Client-Anwendung verwendet. 435 00:33:47,560 --> 00:33:50,050 So wurde der Rest API-Server 436 00:33:50,050 --> 00:33:54,090 so implementiert, dass er besser für den Angular-Client geeignet war. 437 00:33:54,090 --> 00:34:00,600 Aber für die React-Kunden, da wir die Kommentare unabhängig von den Gerichten gehalten haben, 438 00:34:00,600 --> 00:34:03,985 und dann die Dish-ID innerhalb des Kommentars verwenden, 439 00:34:03,985 --> 00:34:09,300 so dass wir unseren Rest API-Server neu strukturieren müssen, 440 00:34:09,300 --> 00:34:16,835 so ist es, dass wir einen separaten Kommentar Endpunkt unabhängig von den Gerichten Endpunkt. 441 00:34:16,835 --> 00:34:22,310 Daher müssen wir unseren Code im Server neu strukturieren, 442 00:34:22,310 --> 00:34:29,140 um den /comments REST-API-Endpunkt in diesem Stadium einzuführen. 443 00:34:29,140 --> 00:34:30,600 Um dies zu tun, 444 00:34:30,600 --> 00:34:37,540 lassen Sie uns ein neues Modell namens comment.js implementieren. 445 00:34:37,540 --> 00:34:39,260 Also, wenn ich in die Modelle gehe, 446 00:34:39,260 --> 00:34:45,790 lass mich eine neue Datei namens comments.js implementieren. 447 00:34:47,220 --> 00:34:50,015 In der Datei comments.js 448 00:34:50,015 --> 00:34:56,110 verschieben wir das CommentSchema aus der 449 00:34:56,110 --> 00:35:02,660 Datei dishes.js in die Datei comments.js und entfernen es dann vollständig aus der Datei dishes.js. 450 00:35:02,660 --> 00:35:03,900 Aber bevor wir das tun, 451 00:35:03,900 --> 00:35:08,770 müssen wir den Mungo und das Schema von hier kopieren, 452 00:35:08,770 --> 00:35:13,860 also lassen Sie mich das einfach von dishes.js in comment.js kopieren. 453 00:35:13,860 --> 00:35:16,590 Danach, wenn ich in dishes.js gehe, 454 00:35:16,590 --> 00:35:21,040 lass mich dieses CommentSchema vollständig von hier aus schneiden, 455 00:35:21,040 --> 00:35:28,300 weil wir dies separat im Kommentarmodell hier haben werden. 456 00:35:28,300 --> 00:35:33,070 Also, lassen Sie uns das in das Kommentarmodell verschieben und dann fügen Sie es hier ein. 457 00:35:33,070 --> 00:35:35,050 Aber natürlich ist dies nicht das komplette, 458 00:35:35,050 --> 00:35:37,870 wir werden das CommentSchema ein wenig aktualisieren. 459 00:35:37,870 --> 00:35:39,300 Aber bevor wir das tun, 460 00:35:39,300 --> 00:35:43,455 gehen Sie zurück zur Datei dishes.js und in der Datei Gerichte, 461 00:35:43,455 --> 00:35:47,925 werden wir die Kommentare aus dem DishesSchema entfernen, 462 00:35:47,925 --> 00:35:51,510 weil wir den Inhalt getrennt von 463 00:35:51,510 --> 00:35:55,550 den Gerichten in dieser Version unseres Servers speichern werden. 464 00:35:55,550 --> 00:36:00,450 So werden wir das Geschirr Modell hier aktualisieren. 465 00:36:00,450 --> 00:36:08,180 Also, wir haben die Kommentare vollständig aus dem Geschirr Modell hier entfernt. 466 00:36:08,180 --> 00:36:10,270 Gehen Sie in das Kommentarmodell, 467 00:36:10,270 --> 00:36:15,355 so dass wir jetzt sehen, dass wir das CommentSchema hier implementiert haben. 468 00:36:15,355 --> 00:36:19,525 Darüber hinaus 469 00:36:19,525 --> 00:36:23,330 müssen wir im CommentsSchema jetzt explizit auf 470 00:36:23,330 --> 00:36:28,885 das spezifische Gericht verweisen, für das dieser Kommentar der entsprechende Kommentar ist. 471 00:36:28,885 --> 00:36:37,435 Nun, hier 472 00:36:37,435 --> 00:36:41,580 kommt unsere Mungo Population und die Art, wie wir die Objekt-IDs lagern, zu unserer Rettung. 473 00:36:41,580 --> 00:36:45,860 Wir werden also das CommentSchema aktualisieren und sagen, dass wir 474 00:36:45,860 --> 00:36:47,800 hier die Bewertung, den Kommentar und den Autor haben werden. 475 00:36:47,800 --> 00:36:49,110 Zusätzlich zu dem Autor, 476 00:36:49,110 --> 00:36:56,080 werden wir ein weiteres Feld als das Gericht hier genannt, 477 00:36:56,080 --> 00:37:05,540 das vom Typ ist: Mongoose.Schema types.ObjectID, 478 00:37:06,390 --> 00:37:19,870 und so wird dies auf die Dish hier beziehen. 479 00:37:19,870 --> 00:37:29,060 Also, dies wäre ein Objekt-Verweis auf das Gericht Modell hier, 480 00:37:29,060 --> 00:37:32,255 und so mit dieser Änderung jetzt 481 00:37:32,255 --> 00:37:36,640 unsere Kommentare enthalten das Bewertungsfeld, das Kommentarfeld, 482 00:37:36,640 --> 00:37:42,355 den Autor, der wieder ein Verweis auf den entsprechenden Benutzer ist, 483 00:37:42,355 --> 00:37:47,660 und dann das Gericht Feld, das ein Verweis auf die entsprechenden Gericht hier. 484 00:37:47,660 --> 00:37:50,060 Also, was bedeutet, dass wir jetzt 485 00:37:50,060 --> 00:37:53,640 die Kommentare sowohl mit dem Autor als auch mit dem Gericht Feld füllen müssen. 486 00:37:53,640 --> 00:37:55,565 Sobald wir dies abgeschlossen haben, 487 00:37:55,565 --> 00:38:01,585 dann werden wir sagen var Kommentare 488 00:38:01,585 --> 00:38:09,910 mongoose.model und wir werden diesen 'Kommentar' nennen, 489 00:38:09,910 --> 00:38:16,765 und dann verwendet dies das CommentSchema, das wir gerade hier definiert haben, 490 00:38:16,765 --> 00:38:21,970 und dann müssen wir dies von hier aus exportieren, 491 00:38:21,970 --> 00:38:25,280 die comments.model von hier. 492 00:38:25,280 --> 00:38:28,395 Also, jetzt, da wir das comments.model eingeführt haben, 493 00:38:28,395 --> 00:38:35,045 werden wir voran gehen und dann einen neuen Router namens CommentRouter vorstellen. 494 00:38:35,045 --> 00:38:37,060 Also, um den Kommentarrouter einzuführen, 495 00:38:37,060 --> 00:38:39,630 gehen wir in die Routen hier, 496 00:38:39,630 --> 00:38:45,990 und erstellen Sie dann eine neue Datei namens commentRouter.js. 497 00:38:47,090 --> 00:38:52,415 Lassen Sie mich in der commentRouter.js ein paar Dinge 498 00:38:52,415 --> 00:38:59,890 vom DishRouter kopieren. 499 00:38:59,890 --> 00:39:07,720 Also, wir werden diese Kommentare hier haben, 500 00:39:07,720 --> 00:39:14,865 also lassen Sie mich diese Dinge von der und auch kopieren, 501 00:39:14,865 --> 00:39:21,070 während ich dabei bin, lassen Sie mich einfach diese auch bis zu diesem Punkt kopieren, 502 00:39:21,070 --> 00:39:24,625 und dann werde ich das ein wenig später aktualisieren. 503 00:39:24,625 --> 00:39:26,680 Also, wenn wir in den CommentRouter gehen, 504 00:39:26,680 --> 00:39:28,040 brauchen wir alle diese Teile, 505 00:39:28,040 --> 00:39:33,640 also sagen wir Com, Express, BodyParser, Mungo 506 00:39:33,640 --> 00:39:37,735 , authentifizieren, cors, und dann 507 00:39:37,735 --> 00:39:46,490 werden wir Kommentare aus Modellen/Kommentaren importieren. 508 00:39:49,950 --> 00:40:00,460 Dann nennen wir dies als CommentRouter, der hier ein Express.Router ist. 509 00:40:02,060 --> 00:40:11,950 Dann werden wir sagen, CommentRouter BodyParser verwenden, 510 00:40:11,950 --> 00:40:17,915 und dann würde dies jetzt CommentRouter Route werden. 511 00:40:17,915 --> 00:40:22,030 Jetzt müssen wir in den DishRouter gehen und dann 512 00:40:22,030 --> 00:40:27,200 alle Teile entfernen, die sich auf die Kommentare hier beziehen. 513 00:40:27,200 --> 00:40:34,330 Also, lassen Sie mich einfach diesen Teil ausschneiden und dann werden wir diese für unseren CommentRouter wiederverwenden. 514 00:40:34,330 --> 00:40:38,200 Also, all diese werden im DishRouter nicht mehr benötigt. 515 00:40:38,200 --> 00:40:42,080 Also, ich werde all dies aus dem DishRouter hier entfernen, 516 00:40:42,080 --> 00:40:43,770 also lassen Sie mich sie ausschneiden, 517 00:40:43,770 --> 00:40:48,715 alles, was mit der Kommentarroute vom DishRouter zusammenhängt, 518 00:40:48,715 --> 00:40:50,770 dann gehen wir in den CommentRouter 519 00:40:50,770 --> 00:40:54,405 und lassen Sie mich dann voran und fügen Sie das hier ein, 520 00:40:54,405 --> 00:40:57,100 dann werden wir das hier bearbeiten. 521 00:40:57,100 --> 00:41:02,660 Danach müssen wir den CommentRouter exportieren. 522 00:41:05,160 --> 00:41:08,205 Also, wird den CommentRouter für uns exportieren. 523 00:41:08,205 --> 00:41:12,060 Aber natürlich ist dieser Code nicht vollständig korrekt. 524 00:41:12,060 --> 00:41:14,995 Also müssen wir voran gehen und diesen Code hier reparieren. 525 00:41:14,995 --> 00:41:16,585 Für diesen Code 526 00:41:16,585 --> 00:41:20,180 erkennen wir nun, dass dies nicht die DishRouter-Route ist, 527 00:41:20,180 --> 00:41:21,785 sondern 528 00:41:21,785 --> 00:41:27,700 der /Endpunkt sein sollte, weil 529 00:41:27,700 --> 00:41:33,685 wir dies hier im Endpunkt /comments einhängen werden. 530 00:41:33,685 --> 00:41:35,685 Also, wir sagen CommentRouter, 531 00:41:35,685 --> 00:41:39,859 und dann die Optionen corsWithOptions (req, 532 00:41:39,859 --> 00:41:42,550 res), die als solche dort bleibt, 533 00:41:42,550 --> 00:41:48,429 und dann die get cors.cors und dann req.res, 534 00:41:48,429 --> 00:41:52,460 und dann wird dieser zu Kommentaren werden. 535 00:41:53,880 --> 00:41:58,430 FindById, req. 536 00:42:00,600 --> 00:42:05,330 Also, das wäre Kommentare.Find 537 00:42:07,050 --> 00:42:17,080 und req.query hier. 538 00:42:17,080 --> 00:42:20,920 Also, wenn die Kommentare gefunden werden 539 00:42:20,920 --> 00:42:22,974 , dann 540 00:42:22,974 --> 00:42:25,940 werden wir an dieser Stelle den Autor bevölkern, 541 00:42:26,880 --> 00:42:30,430 bereits dort haben, hier bevölkern. 542 00:42:30,430 --> 00:42:33,380 Also, ich werde nur diesen comments.author entfernen, und dann, 543 00:42:33,380 --> 00:42:37,410 wir werden einfach den Autor hier füllen. 544 00:42:37,410 --> 00:42:44,425 Dann würde dies uns hier Kommentare geben. 545 00:42:44,425 --> 00:42:49,310 Dann werden wir sagen, dass dies erheblich vereinfacht werden kann. 546 00:42:49,310 --> 00:42:53,835 Also, der Catch-Fehler ist sowieso da. 547 00:42:53,835 --> 00:43:00,805 Also, wenn der Kommentar kommt, wird er einfach zurückkehren. 548 00:43:00,805 --> 00:43:03,910 Tut mir leid, das sollte sein. 549 00:43:03,910 --> 00:43:06,525 Also, wenn für die get, 550 00:43:06,525 --> 00:43:09,305 wenn wir die Kommentare erhalten, 551 00:43:09,305 --> 00:43:13,760 comments.Find req.query, .populate Autor hier, 552 00:43:13,760 --> 00:43:18,010 und dann, wir sagen,, .then Kommentare, 553 00:43:18,010 --> 00:43:21,619 und dann, wir werden sagen, res.StatusCode 200, 554 00:43:21,619 --> 00:43:27,605 SetHeader, und dann, wir werden die Kommentare von hier zurückgeben, 555 00:43:27,605 --> 00:43:30,850 res.json Kommentare von hier. 556 00:43:30,850 --> 00:43:36,970 Nun bevölkere ich die Gerichte hier nicht, weil ich die Gerichte nicht explizit 557 00:43:36,970 --> 00:43:45,300 so brauche, wie ich diese Informationen in meinem Reakt-Client verwende. 558 00:43:45,300 --> 00:43:46,840 Ich brauche nur die Dish ID, 559 00:43:46,840 --> 00:43:49,085 und die Dish ID ist bereits dort vorhanden, 560 00:43:49,085 --> 00:43:55,310 und das ist gut genug für mich, diese Daten in meinem React Client zu verwenden. 561 00:43:55,310 --> 00:43:57,685 Also, ich werde es als solche dort lassen. 562 00:43:57,685 --> 00:43:59,530 Ich werde nur 563 00:43:59,530 --> 00:44:02,910 die Autoreninformationen dort auffüllen, weil wir die vollständigen Autoreninformationen benötigen, 564 00:44:02,910 --> 00:44:08,930 wenn wir ein Kommentarelement in unserem Reakt-Client rendern. 565 00:44:08,930 --> 00:44:12,655 Also, das get wird hier so aktualisiert. 566 00:44:12,655 --> 00:44:22,015 Für den Beitrag corsWithOptions, 567 00:44:22,015 --> 00:44:26,070 wir sagen, Authenticate.VerifyUser req, res, weiter. 568 00:44:26,070 --> 00:44:29,540 Damit ein Kommentar gepostet werden kann, 569 00:44:29,540 --> 00:44:38,315 muss der Autor offensichtlich ein gültiger angemeldeter Benutzer sein. 570 00:44:38,315 --> 00:44:42,910 Nur dann erlauben Sie dem Benutzer, einen Kommentar zu posten. 571 00:44:42,910 --> 00:44:49,020 Dann kommt der Kommentar selbst im Hauptteil der eingehenden Anforderungsnachricht. 572 00:44:49,020 --> 00:44:51,810 Also, zuerst überprüfen wir den Körper, 573 00:44:51,810 --> 00:44:58,865 um sicherzustellen, dass der Kommentar in den Körper hier enthalten ist. 574 00:44:58,865 --> 00:45:03,730 Also, hier werde ich alle diese Teile entfernen und 575 00:45:03,730 --> 00:45:06,100 es dann weiter vereinfachen, und dann 576 00:45:06,100 --> 00:45:09,430 werden wir das dort richtig implementieren. 577 00:45:09,430 --> 00:45:17,755 Also, genau an diesem Punkt, werden wir sagen, 578 00:45:17,755 --> 00:45:27,465 wenn req.body nicht gleich null ist, 579 00:45:27,465 --> 00:45:35,030 was bedeutet, dass es einen Kommentar gibt, der innerhalb des Körpers eingeschlossen ist. 580 00:45:37,380 --> 00:45:45,025 Also, lassen Sie mich das schneiden und das in den If-Teil hier verschieben 581 00:45:45,025 --> 00:45:47,155 , und dann werden wir das hier bearbeiten. 582 00:45:47,155 --> 00:45:52,245 Also, wenn der Körper nicht existiert, 583 00:45:52,245 --> 00:45:56,140 dann werden wir einen Fehler verursachen. 584 00:45:56,140 --> 00:46:01,220 Also, wir werden sagen, irr neuen Fehler, 585 00:46:01,500 --> 00:46:08,965 Kommentar nicht im Anforderungskörper gefunden. 586 00:46:08,965 --> 00:46:12,440 Also, wir werden diesen Fehler hier aufwerfen. 587 00:46:12,450 --> 00:46:16,425 Der Fehlerstatus ist 404. 588 00:46:16,425 --> 00:46:20,385 Dann werden wir sagen, nächsten Fehler zurückgeben. 589 00:46:20,385 --> 00:46:26,560 Also, lassen Sie uns den Fehlerteil hier behandeln, wenn der Körper 590 00:46:26,560 --> 00:46:33,280 nicht die entsprechenden Kommentarinformationen enthält. 591 00:46:33,280 --> 00:46:35,450 Wenn es enthält, dann, natürlich, 592 00:46:35,450 --> 00:46:38,170 was wir als nächstes tun werden, ist, 593 00:46:38,170 --> 00:46:48,310 sagen wir, req.body.author ist req.user. _id. 594 00:46:50,420 --> 00:46:55,610 Der Grund, warum wir dies tun, ist, dass wir uns daran erinnern, dass, wenn es 595 00:46:55,610 --> 00:46:59,950 sich um einen registrierten Benutzer handelt und der Benutzer 596 00:46:59,950 --> 00:47:03,050 sich angemeldet hat, der req.user die Benutzerinformationen enthält. 597 00:47:03,050 --> 00:47:07,260 Ich benötige also nur die ID des aktuell angemeldeten Benutzers. 598 00:47:07,260 --> 00:47:10,310 Also, wir werden sagen, req.user. _id, und dann 599 00:47:10,310 --> 00:47:14,645 setzen wir die req.body.author auf req.user. _id. 600 00:47:14,645 --> 00:47:20,070 Nun wird der Verifizierungsbenutzer automatisch sicherstellen, dass Sie, wenn Sie an diesem Punkt landen, 601 00:47:20,070 --> 00:47:25,710 offensichtlich einen Benutzer haben, der sich korrekt angemeldet hat. 602 00:47:25,710 --> 00:47:28,605 Andernfalls hätte das bereits das Problem dort verursacht. 603 00:47:28,605 --> 00:47:30,260 Also, wenn Sie an dieser Stelle erreichen, 604 00:47:30,260 --> 00:47:37,660 haben Sie einen gültigen Benutzer, der sich bereits beim System angemeldet hat. 605 00:47:37,660 --> 00:47:43,460 Also, das ist, wo Sie jetzt in der Lage sein würden. 606 00:47:43,460 --> 00:47:46,040 Also, was wir tun, ist, dass das Autorenfeld, 607 00:47:46,040 --> 00:47:50,625 wir setzen es explizit in die Benutzer-ID hier, so dass 608 00:47:50,625 --> 00:47:57,490 die req.body die verbleibenden Teile des Kommentars enthält. 609 00:47:57,490 --> 00:48:01,315 Wie Sie erkennen, enthält der Kommentar die Bewertung, 610 00:48:01,315 --> 00:48:04,540 den Kommentar selbst und den Autor und die Felder des Gerichts. 611 00:48:04,540 --> 00:48:11,510 Also, die restlichen Teile sollten vom Benutzer gefüllt worden sein. 612 00:48:11,510 --> 00:48:14,730 Die Bewertung, der Kommentar 613 00:48:14,730 --> 00:48:17,775 und die Dish-Informationen sollten bereits 614 00:48:17,775 --> 00:48:20,840 in den Text der eingehenden Anforderungsnachricht eingegeben werden. 615 00:48:20,840 --> 00:48:23,460 Der Autorenteil bleibt dort unausgefüllt 616 00:48:23,460 --> 00:48:28,380 , den wir an dieser Stelle explizit in den Body einfügen werden. 617 00:48:28,380 --> 00:48:32,515 Also, jetzt wird der req.body die gesamten Kommentarinformationen enthalten. 618 00:48:32,515 --> 00:48:34,440 Also, an dieser Stelle, 619 00:48:34,440 --> 00:48:43,400 anstatt dies zu tun, werden wir sagen, Kommentare.Erstellen. 620 00:48:44,550 --> 00:48:49,940 Mit dem req.body, werden wir die Kommentare hier erstellen. 621 00:48:50,010 --> 00:48:53,304 Dann gibt dies 622 00:48:53,304 --> 00:48:58,735 den Kommentar zurück, der dem Kommentar entspricht, den wir gerade hier eingefügt haben. 623 00:48:58,735 --> 00:49:00,755 Nun, sobald der Kommentar zurückgegeben wurde, 624 00:49:00,755 --> 00:49:07,050 dann sollten wir comments.findById tun. 625 00:49:07,050 --> 00:49:09,680 Nun, der Grund, warum wir dies tun müssen, ist, dass wir 626 00:49:09,680 --> 00:49:13,070 die Autoreninformationen hier füllen müssen. 627 00:49:13,780 --> 00:49:18,144 Also, wir werden sagen, FindById Kommentare. _id, 628 00:49:18,144 --> 00:49:26,155 und dann füllen wir die Autoreninformationen in den Kommentar selbst. 629 00:49:26,155 --> 00:49:34,610 Dann werden wir sagen, dann kommentieren. 630 00:49:36,570 --> 00:49:41,115 Nun, offensichtlich, hier, würden Sie feststellen, dass der Kommentar 631 00:49:41,115 --> 00:49:44,880 existieren wird, weil wir gerade diesen Kommentar eingefügt haben. 632 00:49:44,880 --> 00:49:54,470 Also, hier werden wir einfach zurückkehren, res.StatusCode ist 200, 633 00:49:54,900 --> 00:50:10,040 Res.setHeader ist Content-Type, application/json. 634 00:50:14,610 --> 00:50:18,430 Der Kommentar selbst wird sagen, res.json, und dann, 635 00:50:18,430 --> 00:50:21,745 den Kommentar an dieser Stelle zurück. 636 00:50:21,745 --> 00:50:26,255 So werden wir 637 00:50:26,255 --> 00:50:30,805 hier mit dem Einfügen eines neuen Kommentars in unsere Kundenseite umgehen. 638 00:50:30,805 --> 00:50:33,925 Für den Put, wie Sie erkennen, werden 639 00:50:33,925 --> 00:50:38,360 Sie nicht in der Lage sein, einen Put auf die /comments/Endpunkte zu tun. 640 00:50:38,360 --> 00:50:47,610 Also, wir werden sagen, PUT-Operation nicht unterstützt auf /comments/Endpunkt. 641 00:50:52,050 --> 00:50:56,180 Das ist der Punkt. Das ist die Nachricht, die du zurückkehrst. 642 00:50:56,180 --> 00:50:58,570 Also, StatusCode ist 403, 643 00:50:58,570 --> 00:51:02,610 und dann, PUT-Operation nicht unterstützt auf /comments/. 644 00:51:02,610 --> 00:51:05,260 Nun, wenn wir ein Löschen tun, 645 00:51:13,230 --> 00:51:22,840 lassen Sie mich einfach schneiden dies von hier, und dann, wir sagen, 646 00:51:30,440 --> 00:51:32,835 Kommentare.Entfernen. 647 00:51:32,835 --> 00:51:37,710 leer geschrieben. Wenn Sie also einen Löschvorgang auf dem Endpunkt von Schrägkommentaren 648 00:51:37,710 --> 00:51:40,990 vornehmen, werden Sie alle Kommentare aus Ihrem System entfernen. 649 00:51:40,990 --> 00:51:43,680 Also, das ist eine sehr gefährliche Operation, und so 650 00:51:43,680 --> 00:51:48,990 sollten Sie dies nicht normal tun. 651 00:51:48,990 --> 00:51:53,860 Daher erlauben wir dem Administrator nur, eine solche Operation durchzuführen. 652 00:51:53,860 --> 00:51:59,410 Also, wir werden alle Kommentare von dort entfernen. 653 00:51:59,410 --> 00:52:01,940 Also, wenn Sie die Antwort erhalten, 654 00:52:01,940 --> 00:52:07,700 dann sagen wir res.StatusCode 200. 655 00:52:07,700 --> 00:52:11,080 Also, lassen Sie mich diese Teile hier kopieren, 656 00:52:12,090 --> 00:52:18,130 und dann kommen Sie und fügen Sie sie hier ein. 657 00:52:18,130 --> 00:52:21,330 Also, wir werden sagen, Kommentare.entfernen. 658 00:52:21,330 --> 00:52:30,480 Dann antworten Sie res.StatusCode 200 Anwendung json und dann res.json (Antwort) hier. 659 00:52:30,480 --> 00:52:33,100 So gehen wir mit der Löschung um. 660 00:52:33,100 --> 00:52:37,280 Löschvorgang auf dem Endpunkt von Schrägstrichkommentaren. 661 00:52:37,280 --> 00:52:43,135 Nun, die nächste Route ist der Kommentarrouter. 662 00:52:43,135 --> 00:52:49,490 Also, hier sagen wir commentRouter.Route und 663 00:52:49,490 --> 00:52:56,820 der Endpunkt hier wäre der Schrägstrich commenttID. 664 00:53:01,190 --> 00:53:05,580 Also, hier werden die Optionen als solche bleiben. 665 00:53:05,580 --> 00:53:09,760 Dann für den get auf den aktuellen Router, 666 00:53:09,760 --> 00:53:20,455 für die get sagen wir, comments.findById (req.params. 667 00:53:20,455 --> 00:53:25,040 Dies wäre CommentID. 668 00:53:25,380 --> 00:53:31,029 Also, sobald wir den spezifischen Kommentar gefunden haben, 669 00:53:31,029 --> 00:53:37,525 dann werden wir nur den Autor von dort füllen. 670 00:53:37,525 --> 00:53:39,985 Dann, wenn Sie den Autor füllen, 671 00:53:39,985 --> 00:53:45,830 dann sagen wir, dann kommentieren. 672 00:53:47,880 --> 00:53:51,310 Nun, all dieser Teil ist hier unnötig, 673 00:53:51,310 --> 00:53:54,440 also werde ich nur den Teil löschen. 674 00:53:54,480 --> 00:54:00,985 Das ist auch hier nicht das Richtige. 675 00:54:00,985 --> 00:54:04,540 Also, lassen Sie mich Code umbenennen. 676 00:54:04,540 --> 00:54:08,990 Also, wir werden für die get comments.findById sagen, 677 00:54:11,550 --> 00:54:15,385 dann füllen Sie den Autor, 678 00:54:15,385 --> 00:54:20,365 dann kommentieren, res.StatusCode ist 200, setHeader. 679 00:54:20,365 --> 00:54:22,435 Dann sind der Rest JSON. 680 00:54:22,435 --> 00:54:29,960 Wir werden einfach die Kommentare hier zurückgeben. 681 00:54:39,240 --> 00:54:46,750 Also, wir werden den Kommentar an dieser Stelle zurückgeben, res.json (Kommentar). 682 00:54:46,750 --> 00:54:49,340 Sie finden den spezifischen Kommentar 683 00:54:49,340 --> 00:54:52,415 und geben dann diesen Kommentar für den Beitrag zurück. 684 00:54:52,415 --> 00:54:55,185 Für die Post-Operation, wie Sie erkennen, 685 00:54:55,185 --> 00:54:56,900 ist die Post-Operation nicht 686 00:54:56,900 --> 00:55:06,740 auf Kommentare CommentID erlaubt. 687 00:55:10,080 --> 00:55:13,805 Also, das ist die Nachricht, die wir senden, 688 00:55:13,805 --> 00:55:19,110 POST-Operation nicht auf Kommentare Slash CommentID unterstützt. 689 00:55:19,110 --> 00:55:23,640 Also, das ist die Botschaft, die wir für den Einsatz sagen werden. 690 00:55:23,640 --> 00:55:33,730 Nun, für den Put, sagen wir Kommentare.Finden Sie wo Id (req.params.CommentID). 691 00:55:34,890 --> 00:55:39,230 Also, wir werden den Kommentar dort finden, 692 00:55:40,890 --> 00:55:48,070 und dort Kommentar, also für den Putt. 693 00:55:48,070 --> 00:55:50,805 Also, wir werden den Kommentar dort finden, 694 00:55:50,805 --> 00:55:53,400 und dann sagen wir für die Kommentare. 695 00:55:53,400 --> 00:55:55,305 Also, wenn wir den Kommentar finden, 696 00:55:55,305 --> 00:56:07,080 wenn der Kommentar nicht null ist, 697 00:56:07,080 --> 00:56:19,455 dann werden wir auch überprüfen, ob comment.author. 698 00:56:19,455 --> 00:56:32,625 Wenn nicht, ist comment.arthur gleich (req.user. _id). 699 00:56:32,625 --> 00:56:38,095 Wir überprüfen also, um sicherzustellen, dass 700 00:56:38,095 --> 00:56:43,755 der comments.author mit dem aktuellen Benutzer identisch ist. 701 00:56:43,755 --> 00:56:50,950 Nur der aktuelle Benutzer, der angemeldet ist - wenn der Benutzer mit dem Autor des Kommentars 702 00:56:50,950 --> 00:56:53,760 übereinstimmt, kann der Benutzer aktualisieren. 703 00:56:53,760 --> 00:56:57,190 Also, das ist das erste, was wir überprüfen werden. 704 00:56:57,190 --> 00:57:01,900 Also, Kommentare, dann kommentiert.author.equal rec.user. _id. 705 00:57:01,900 --> 00:57:07,860 Wenn nicht, dann werden Sie sagen, dass Sie nicht berechtigt sind, diesen Kommentar zu aktualisieren. 706 00:57:07,860 --> 00:57:10,859 Wie Sie die.403 sehen, 707 00:57:10,859 --> 00:57:13,090 und geben Sie dann den nächsten Fehler hier zurück. 708 00:57:13,090 --> 00:57:16,705 Also, wir werden den Fehler dort erstellen. 709 00:57:16,705 --> 00:57:21,800 Danach sagen wir 710 00:57:29,910 --> 00:57:36,860 req.body.author, req.user. _id. 711 00:57:40,010 --> 00:57:42,215 Das ist wichtig. 712 00:57:42,215 --> 00:57:45,580 Nun, diese beiden sind hier nicht notwendig, 713 00:57:45,580 --> 00:57:51,385 weil wir den Kommentar direkt speichern. 714 00:57:51,385 --> 00:58:05,980 Dann Pillen, sagen wir comments.findByidAndUpdate, 715 00:58:05,980 --> 00:58:14,965 und req.params.CommentID. 716 00:58:14,965 --> 00:58:18,395 Also, wir werden diesen spezifischen Kommentar finden, 717 00:58:18,395 --> 00:58:21,925 weil wir bereits die Kommentar-ID angegeben haben. 718 00:58:21,925 --> 00:58:27,205 Also, wir werden Kommentare FindById Req.params.CommentID tun. 719 00:58:27,205 --> 00:58:30,260 Dann sagen wir dann (Kommentar). 720 00:58:32,730 --> 00:58:38,705 Wenn Sie die Req.params.CommentID angeben, 721 00:58:38,705 --> 00:58:42,275 müssen wir explizit den zweiten Parameter angeben, 722 00:58:42,275 --> 00:58:45,825 was wir ändern möchten. 723 00:58:45,825 --> 00:58:52,285 Also, wir sagen $set: req.body. 724 00:58:52,285 --> 00:58:54,970 Der zweite Parameter 725 00:58:54,970 --> 00:58:58,740 sagt Ihnen also im Wesentlichen, welchen Teil Sie ändern. 726 00:58:58,740 --> 00:59:03,710 Jetzt, da wir den Körper geliefert haben, der den aktualisierten Kommentar enthält, 727 00:59:03,710 --> 00:59:09,140 werden wir nur den gesamten Kommentar selbst aktualisieren. 728 00:59:09,510 --> 00:59:18,205 Dann ist der andere Teil, nach dem wir fragen werden, neu: wahr. 729 00:59:18,205 --> 00:59:23,240 Dadurch wird sichergestellt, dass der aktualisierte Kommentar in der 730 00:59:23,240 --> 00:59:29,815 Höhle dieses Aufrufs des Kommentars.findByIdandUpdate-Objekts zurückgegeben wird. 731 00:59:29,815 --> 00:59:32,565 Also, wir werden sagen, dann Kommentare. 732 00:59:32,565 --> 00:59:35,214 Wenn dieser Kommentar zurückgegeben wird, 733 00:59:35,214 --> 00:59:38,440 dann sagen wir comments.findById (Kommentar. _id). 734 00:59:46,200 --> 00:59:51,460 Dann füllen Sie den Autor dort. 735 00:59:51,460 --> 00:59:53,785 Wir werden den Autor dort füllen, 736 00:59:53,785 --> 00:59:58,490 und dann sagen wir, dann kommentieren. 737 00:59:58,700 --> 01:00:09,680 Sie sehen also, dass wir den Kommentar erhalten und dann den Kommentar an dieser Stelle zurückgeben werden. 738 01:00:09,680 --> 01:00:13,095 So werden wir den Kommentar aktualisieren. 739 01:00:13,095 --> 01:00:17,395 Dies ist also die Situation, in der der Kommentar nicht null ist. 740 01:00:17,395 --> 01:00:20,625 Also, diese if-Anweisung für den Kommentar ist nicht null. 741 01:00:20,625 --> 01:00:23,785 Also, das sonst wenn Teil, 742 01:00:23,785 --> 01:00:29,020 jetzt ist dies nicht anwendbar, 743 01:00:29,020 --> 01:00:33,325 also sagen wir sonst, Fehler. 744 01:00:33,325 --> 01:00:35,470 Der Fehler in diesem Fall. 745 01:00:35,470 --> 01:00:37,825 Also, wenn der Kommentar null ist, 746 01:00:37,825 --> 01:00:40,850 bedeutet das, dass wir den Kommentar dort nicht gefunden haben, 747 01:00:40,850 --> 01:00:43,650 so dass Sie keinen nicht vorhandenen Kommentar ändern können. 748 01:00:43,650 --> 01:00:44,805 Also sagen wir, Fehler, 749 01:00:44,805 --> 01:00:54,700 neue Fehler Kommentar req.params.CommentID nicht gefunden und dann werden wir den Fehler zurückgeben. 750 01:00:54,700 --> 01:01:01,255 Also, so werden wir den Put-Teil unseres Kommentars hier behandeln, 751 01:01:01,255 --> 01:01:04,099 und dann endlich das Löschen. 752 01:01:06,120 --> 01:01:11,130 Für das Löschen, wieder müssen wir zuerst 753 01:01:11,130 --> 01:01:12,900 comments.findById (Req.params.CommentID) finden 754 01:01:12,900 --> 01:01:25,720 und dann kommentieren. 755 01:01:25,720 --> 01:01:28,150 Also, wir werden nach dem Kommentar suchen. 756 01:01:28,150 --> 01:01:34,160 Also, wir werden zuerst überprüfen, ob Kommentar nicht gleich null ist. 757 01:01:36,180 --> 01:01:39,955 Das ist wichtig, hier zu überprüfen. 758 01:01:39,955 --> 01:01:50,990 Dann wird der nächste Teil, auf den wir prüfen werden, ist, ob der comment.author gleich req.user ist. _id. 759 01:01:58,830 --> 01:02:03,400 Wir stellen sicher, dass dieser Benutzer, der versucht, 760 01:02:03,400 --> 01:02:08,060 diesen Kommentar zu löschen, genau derselbe Benutzer ist, der den Kommentar an erster Stelle eingefügt hat. 761 01:02:08,060 --> 01:02:10,750 Wenn nicht, so, wenn dies der Fall ist, 762 01:02:10,750 --> 01:02:13,920 dann sehen Sie „Sie sind nicht berechtigt, diesen Kommentar zu löschen!“ 763 01:02:13,920 --> 01:02:16,365 Und dann den Status dorthin zurückgeben. 764 01:02:16,365 --> 01:02:20,920 Dann unten hier unten, 765 01:02:20,920 --> 01:02:41,310 sagen wir comments.findByIdandRemove hier. 766 01:02:41,310 --> 01:02:48,750 Also, wir sagen comments.findByIdAndRemove (req.params.CommentID), 767 01:02:48,750 --> 01:02:54,035 dann erhalten wir eine Antwort aus dem Kommentar. 768 01:02:54,035 --> 01:02:55,630 Also, an dieser Stelle 769 01:02:55,630 --> 01:02:59,830 werden wir einfach sagen, res.StatusCode. 770 01:02:59,830 --> 01:03:05,365 Also sagen wir comments.findByIdAndRemove dann Antwort. 771 01:03:05,365 --> 01:03:07,210 Wenn es richtig entfernt wird, 772 01:03:07,210 --> 01:03:10,915 sagen wir 200 und dann res.json 773 01:03:10,915 --> 01:03:17,260 Antwort hier und wir werden auch den Fehler an dieser Stelle fangen. 774 01:03:17,260 --> 01:03:25,195 Also, lassen Sie mich das hier kopieren und dann werden wir den Fang des Fehlers an dieser Stelle einschließen. 775 01:03:25,195 --> 01:03:28,895 Also, das ist das erste, was wir überprüfen werden. 776 01:03:28,895 --> 01:03:33,500 Wir stellen sicher, dass der Kommentar nicht gleich null ist. 777 01:03:33,630 --> 01:03:38,360 Andernfalls ist dies also der andere Teil. 778 01:03:39,810 --> 01:03:44,170 Also, dies ist der andere Teil des wenn else Fehler 779 01:03:44,170 --> 01:03:48,040 neuen Kommentar req.params.CommentID nicht gefunden und dann 780 01:03:48,040 --> 01:03:56,220 404 und senden Sie den sonst Teil für uns und dann wird der dann Teil angemessen behandeln. 781 01:03:56,220 --> 01:04:01,460 Also, das sind die Änderungen, die wir hier für den Kommentarrouter vornehmen. 782 01:04:01,460 --> 01:04:05,025 Also, wir behandeln den get put post und löschen für 783 01:04:05,025 --> 01:04:10,330 die Schrägstrich Kommentare und Punkt Schrägstrich Kommentare Schrägstrich CommentID Auswirkungen. 784 01:04:10,330 --> 01:04:12,495 Sobald wir dies abgeschlossen haben, 785 01:04:12,495 --> 01:04:17,500 müssen wir dies in die Datei app.js aufnehmen. 786 01:04:17,500 --> 01:04:27,345 Also, wir werden in die app.js Datei gehen und dann sagen wir 787 01:04:27,345 --> 01:04:30,070 var CommentRouter 788 01:04:31,130 --> 01:04:42,280 benötigen Routes/CommentRouter. 789 01:04:42,280 --> 01:04:45,960 Also, wir haben den Kommentar Router hier und dann werden wir 790 01:04:45,960 --> 01:04:49,390 unten in die app.js Datei unten gehen und 791 01:04:49,390 --> 01:04:54,610 dann sagen wir app.use 792 01:04:55,040 --> 01:05:04,695 Schrägstrich Kommentare, CommentRouter hier. 793 01:05:04,695 --> 01:05:07,365 Das war's. Also, jetzt 794 01:05:07,365 --> 01:05:09,390 ist mein Kommentarrouter bereit. 795 01:05:09,390 --> 01:05:12,935 Also, lassen Sie uns fortfahren und alle Änderungen speichern. 796 01:05:12,935 --> 01:05:19,020 Dann wird unser Server jetzt aktualisiert, 797 01:05:19,020 --> 01:05:24,420 um alle Anfragen unserer React-Clients hier zu bearbeiten. 798 01:05:24,420 --> 01:05:27,800 Nun, wenn Sie den alternativen Weg machen möchten, das heißt, 799 01:05:27,800 --> 01:05:34,120 Sie haben Ihre Kommentare als Unterdokumente Ihres Gerichts und dann möchten Sie damit umgehen, 800 01:05:34,120 --> 01:05:37,680 dann müssen Sie den React-Client aktualisieren, 801 01:05:37,680 --> 01:05:42,185 um die Kommentare aus jedem Gericht entsprechend verwenden zu können. 802 01:05:42,185 --> 01:05:44,830 Das wird als Übung für Sie übrig bleiben. 803 01:05:44,830 --> 01:05:48,920 Denken Sie darüber nach, wie Sie Ihren React-Client so gestalten würden, dass er 804 01:05:48,920 --> 01:05:53,465 sehr gut mit der früheren Version 805 01:05:53,465 --> 01:06:03,735 des Servers funktioniert, der die Kommentare als Unterdokumente Ihrer Gerichte selbst hatte. 806 01:06:03,735 --> 01:06:07,065 Nun, das wird eine interessante Möglichkeit sein, es zu implementieren. 807 01:06:07,065 --> 01:06:10,480 Natürlich ist es ein bisschen komplizierter als die Art und Weise, wie wir 808 01:06:10,480 --> 01:06:14,965 den React-Client implementiert haben, wo wir die Kommentare unabhängig von 809 01:06:14,965 --> 01:06:20,840 den Gerichten gehalten haben, aber dann liegt die zusätzliche Arbeit dann in 810 01:06:20,840 --> 01:06:22,910 der Verantwortung der Kundenseite, weil Sie 811 01:06:22,910 --> 01:06:26,765 die entsprechenden Kommentare auswählen müssen, wenn Sie eine spezifisches Gericht. 812 01:06:26,765 --> 01:06:30,370 Sie müssen die Kommentare aus allen Kommentaren hier auswählen. 813 01:06:30,370 --> 01:06:35,170 Also, das ist eine zusätzliche Arbeit, die unser React-Client tut, weil 814 01:06:35,170 --> 01:06:40,680 wir die Kommentare von den Gerichten selbst getrennt haben. 815 01:06:40,680 --> 01:06:46,165 Ebenso, wenn Sie Ihren eckigen Kunden neu gestalten können, um 816 01:06:46,165 --> 01:06:51,775 mit der Situation umzugehen, in der die Kommentare unabhängig von Ihren Gerichten gehalten werden. 817 01:06:51,775 --> 01:06:56,020 Nun, das sind alles Übungen, die Sie tun können, um zu sehen, wie Sie 818 01:06:56,020 --> 01:07:01,210 Ihre Client-Anwendungen für jede Art von Server erweitern können, 819 01:07:01,210 --> 01:07:04,430 die beiden verschiedenen Arten von Servern dort. 820 01:07:04,860 --> 01:07:11,480 Damit schließen wir das Update auf unseren Server hier ab. 821 01:07:11,480 --> 01:07:15,040 Damit haben wir alles auf der Serverseite aktualisiert. 822 01:07:15,040 --> 01:07:17,890 Lassen Sie uns also alle Änderungen auf der Serverseite speichern. 823 01:07:17,890 --> 01:07:26,755 Jetzt ist unser Server bereit, die eingehenden Anfragen von unserem React-Client zu bearbeiten. 824 01:07:26,755 --> 01:07:29,340 Damit schließen wir diese Übung ab. 825 01:07:29,340 --> 01:07:33,300 In dieser Übung haben wir nun unseren Express-Server vorbereitet, 826 01:07:33,300 --> 01:07:38,985 um eingehende Anfragen von unserem React-Client zu bearbeiten. 827 01:07:38,985 --> 01:07:43,190 In der nächsten Übung werden wir uns den React Client genauer ansehen, um zu 828 01:07:43,190 --> 01:07:48,000 verstehen, wie es mit diesem zusätzlichen Server kommuniziert. 829 01:07:48,000 --> 01:07:50,640 Dies ist ein guter Zeitpunkt für Sie, 830 01:07:50,640 --> 01:07:55,880 eine Git-Abdeckung mit der Nachricht zu erstellen, die Client und Server integriert.