Nous avions déjà développé un serveur d'API REST à part entière
en utilisant Express et MongoDB dans le cadre de ce cours.
Pour que ce serveur puisse communiquer de manière significative avec notre client,
nous y apporterons quelques ajustements mineurs
afin qu'il renvoie le bon type de données afin que
notre implémentation client puisse fonctionner plus
efficacement avec les données renvoyées par notre site serveur.
Donc, pour ce faire,
nous allons travailler sur quelques ajustements à notre site serveur dans cet exercice.
Avant de commencer cet exercice,
je suppose que vous n'avez pas fait
la leçon précédente sur l'intégration du client angulaire et
du serveur parce que vous faites cette leçon en passant par la spécialisation React.
Donc, les modifications que je vais apporter au serveur supposent que
la version du serveur que vous modifiez est antérieure à la leçon précédente.
Dans le cas où vous avez fait cette leçon sur
le client angulaire, certaines des modifications que vous avez apportées à votre serveur seront répétées
dans cet exercice afin que vous puissiez ignorer cette partie des modifications.
Accédez à notre serveur dans l'éditeur.
Avant de commencer à travailler sur le serveur,
je vous suggère de télécharger toutes les images que j'ai
fournies sous forme de fichier zip dans les ressources d'exercice appelées images.zip.
Décompressez le fichier, puis obtenez toutes les images à partir de là, puis copiez ces images
dans le dossier des images publiques de notre serveur.
Donc, vous voyez qu'ici j'ai copié toutes les images dans mon dossier d'images publiques ici
déjà parce que notre serveur est celui qui va
servir toutes ces images pour notre application client.
Ensuite, nous allons au CORS et ajustons la liste blanche ici.
Donc, pour notre application client React,
si nous avons démarré avec la commande yarn start,
elle s'exécute à votre nom d'ordinateur:3001.
Donc, toute demande venant de notre emplacement vers
le serveur portera cela comme origine là-bas.
C' est pourquoi je vais ajouter cela dans ma liste blanche afin que
tous les problèmes CORS soient résolus automatiquement.
Donc, en entrant dans le fichier cors.js dans ma liste blanche ici,
permettez-moi d'ajouter le
nom de l'ordinateur http://my : 3001 et c'est
l'origine à partir de laquelle mon client
sera à l'origine des requêtes qui viennent à ce serveur.
Donc, de cette façon, mon CORS ne causerait pas de problèmes pour mon client.
Ensuite, nous devons mettre à jour quelques-unes des routes pour
gérer les paramètres de requête et aussi quelques autres ajustements mineurs.
Laissez-moi commencer par le fichier promoRouter.js.
C' est simple de se mettre à jour.
Donc, en allant dans le fichier promoRouter.js,
dans le fichier Promorouter pour la requête get que nous obtenons
ici au lieu de faire des promotions trouver avec un objet JavaScript vide,
ici je fournirais le req.query comme paramètre pour les promotions trouver ici,
même chose avec le routeur leader aussi.
Donc, laissez-moi aller au fichier leaderRouter.js.
Dans le routeur de leader aussi,
ici où vous trouvez leaders.Find avec l'objet JavaScript vide
remplacer cela par le req.query afin que les paramètres de requête soient transmis.
Donc, c'est là que nous allons passer dans le featured:true comme paramètre de requête ici.
Maintenant, après avoir ajusté ces deux,
travaillons maintenant sur le routeur à vaisselle.
Donc, allez dans le fichier dishRouter.js,
même dans le routeur plat aussi la même mise à jour ici.
Donc, allez dans ce plats.Trouver dans la méthode get ici,
changez cela en req.query.
Donc, avec cela, ma mise à jour de routeur plat a été terminée.
Donc, nous avons maintenant mis à jour le routeur promo, le leader,
et le routeur plat,
puis nous allons passer à mettre à jour le routeur préféré.
Maintenant, vous auriez implémenté le routeur favori dans le cadre de votre quatrième affectation.
Maintenant, dans le routeur préféré,
vous verrez que pour le routeur préféré,
je ne vous montre pas la partie restante parce que
vous auriez dû faire dans le cadre de votre affectation. Tout d'
abord, permettez-moi d'attirer votre attention sur la méthode get pour le favoriTerouter.route:Dishid.
Maintenant, je vais utiliser cette méthode get pour vérifier simplement que
le plat spécifique avec le plat Id est déjà un favori pour l'utilisateur.
Donc, au lieu de simplement dire getoperation.supported,
je vais juste tirer parti de la présence de cette opération get et ensuite nous dirons,
favorites.findone et nous dirons utilisateur : req.user. _id.
Donc, nous allons trouver les favoris pour cet utilisateur particulier, puis nous dirons ensuite les
favoris et attraper l'erreur suivante.
Ensuite, de même ici, nous allons ajouter dans l'erreur ici, prochaine erreur ici.
Donc, à l'intérieur de cela alors,
quand nous obtenons les favoris,
alors nous vérifierons si ce n'est pas les favoris.
Donc, s'il n'y a pas de favoris pour
cet utilisateur, alors évidemment le plat que nous vérifions n'existe pas,
donc nous allons retourner res.StatusCode 200,
setHeader, Content-Type,
application/json et ensuite nous reviendrons dire existe false.
Ce que nous spécifions ici est que s'ils obtiennent est fait à ce point final avec un ID plat,
cela existe drapeau ici sera réglé sur true si ce plat fait partie de mes favoris.
Si ce plat ne fait pas partie de mes favoris,
je vais définir il existe drapeau à false.
Donc, ici, vous voyez que puisque je n'ai pas de favoris,
il existe donc devrait être automatiquement faux à ce stade.
Donc, nous allons dire existe false et ensuite nous allons retourner les favoris ici.
Eh bien, évidemment, dans ce cas, les favoris seraient nuls à ce stade.
Sinon, ce qui signifie que les favoris n'est pas nul,
donc nous dirons si favorites.Dish.IndexOf.
Donc, nous allons chercher Req.params.Dishid.
Donc, nous allons chercher ce tableau de plats favoris pour
voir si ce plat existe et s'il n'existe pas,
évidemment cela retournera un index négatif ici.
Dans ce cas aussi,
je reviendrai exactement le même que ici.
Donc, si elle renvoie un index négatif, cela signifie que
même si cet utilisateur particulier a un ensemble de favoris,
ce plat spécifique n'existe pas dans
la liste de ses favoris donc c'est pourquoi il retournera existe false ici.
Maintenant, sinon cela signifie que le plat existe dans la liste des favoris.
Donc, dans ce cas,
je vais retourner le code d'état 200 existe est vrai.
Ainsi, lorsque l'utilisateur effectue une opération get sur ce point de terminaison avec
le /favorites/dishid où l'ID plat est fourni comme paramètre ici, en
tant que paramètre de requête ici,
nous allons vérifier si ce plat existe dans les favoris.
Si aucun des favoris n'existe pour cet utilisateur, nous retournerons un false existe.
De même, si les favoris existent mais
que ce plat particulier n'existe pas dans les favoris, alors nous retournerons false,
sinon nous retournerons true.
Donc, ce drapeau existe peut être utilisé par mon client pour vérifier si ce plat fait
partie de la liste des plats préférés pour cet utilisateur ou non.
Aussi pendant que nous sommes dans les favoris,
chaque fois que nous faisons des changements aux favoris,
nous voulons être en mesure de remplir les informations de l'utilisateur et de
la vaisselle, les favoris, avant de revenir.
Par exemple, dans le post que nous faisons,
lorsque nous enregistrons les favoris puis à ce stade,
nous aimerions d'abord faire des favoris.
FindById, donc parce que nous venons de faire les changements, nous dirons favorite_id
et nous allons remplir à la fois l'utilisateur et aussi
remplir les plats dans les favoris.
Ensuite, lorsque les favoris sont retournés,
nous retournerons ces favoris à la place.
Alors, laissez-moi faire ce changement ici.
Donc, nous allons découper cela d'ici et puis à l'intérieur de l'alors,
nous allons retourner les favoris.
Après avoir enregistré les favoris,
nous allons chercher,
pour le FavoriteById, puis retourner
ce favori ici afin que nous dirons alors retour favori et code d'état.
Ce changement que nous devrions faire.
Si vous l'avez déjà implémenté dans vos favoris,
vous n'avez pas besoin d'apporter cette modification.
Mais ce que nous faisons, c'est chaque fois que nous apportons des modifications aux favoris,
nous remplirons à la fois les informations de l'utilisateur et de la vaisselle, puis retournerons cette valeur
car notre client React s'attend à ce que cela soit là.
Maintenant, le même type de changement,
nous devrons faire la variable b, enregistrer les changements.
Donc, dans le post ici,
nous allons faire un changement à cela,
donc nous allons dire favorites.enregistrer et ensuite nous ferons favorites.FindById et faire ce changement.
De même, sous l'ID plat,
également dans le poste,
vous serez de la même manière, chaque fois que vous apportez des modifications aux favoris, d'
abord le chercher et ensuite remplir à la fois l'utilisateur et la vaisselle, puis le retourner,
puis de la même manière dans la partie autre.
Donc, vous devez avoir implémenté ceci dans votre quatrième affectation.
Donc, apportez cette modification supplémentaire où vous allez remplir
l'utilisateur et les plats avant de renvoyer la valeur.
Aussi avec la suppression,
nous allons faire les mêmes changements ici.
Donc, vous remarquez que dans la suppression,
j'ai déjà fait ce changement ici.
Donc, après avoir enregistré les modifications aux favoris,
nous allons ensuite rechercher les favoris, puis
revenir après avoir rempli à la fois l'utilisateur et les plats et les favoris.
C' est ce que notre client React attend de nous.
Donc, même pour la suppression,
nous allons faire les mêmes changements.
Maintenant, avec cela, mon routeur préféré est mis à jour
donc nous allons procéder à la mise à jour de users.js suivante.
Enfin, nous allons mettre à jour le fichier users.js.
Maintenant, dans le fichier users.js, nous devons ajouter
un autre champ router.options ici,
car parfois une demande de poste comme vous l'avez vu
avec la connexion enverra les options d'abord pour vérifier,
en particulier avec les voitures, si la demande de poste sera autorisée.
C' est pourquoi nous allons vérifier bien sûr avec les options ici et ensuite
nous allons simplement retourner
un message d'état
de 200 en réponse à cela.
Pour n'importe quel point de terminaison sous utilisateurs si nous recevons les options,
nous retournerons simplement un état 200 ici.
Maintenant, la fonction de connexion que nous avions implémenté plus tôt,
nous avions simplement fait passeport.authenticate
local ici et nous avons vérifié les valeurs restantes ici.
Maintenant, ce passeport.authenticate local,
si l'utilisateur n'est pas authentifié,
il renvoie simplement un non autorisé dans le message de réponse.
Maintenant, cela peut ne pas être très significatif pour le côté client d'afficher ces informations,
c'est pourquoi nous allons améliorer
cette méthode de post-connexion du routeur de
sorte que l'authentification retournera des informations plus significatives à ce stade.
Donc, pour ce faire,
nous ne allons pas faire le passeport.authenticate ici,
au lieu de cela, nous allons prendre.
Donc, laissez-moi supprimer cela à partir de là et vous verrez
comment je vais mettre à jour le post du routeur ici.
Donc, nous allons voir cours avec des options et ensuite nous allons inclure le req,
res et suivant ici.
A l'intérieur de ce req, res et ensuite ici,
passeport.authenticate appellera ceci avec local.
Maintenant, lorsque nous appelons ceci avec local,
si une erreur d'authentification se produit,
le passeport.authenticate peut être fait pour retourner
la valeur d'erreur et aussi il retournera l'utilisateur s'il
n'y a pas d'erreur et un troisième paramètre appelé info
qui transportera des informations supplémentaires qui pourraient être analysées vers l'utilisateur.
Cette erreur sera renvoyée lorsqu'il y a
une erreur authentique qui se produit dans passeport.authenticate.
Mais si les informations de l'utilisateur
sont envoyées dans passeport.authenticate mais que l'utilisateur n'existe pas,
cela n'est pas compté comme une erreur.
Au lieu de cela, il sera compté comme l'utilisateur n'existe pas et
que les informations sont analysées de nouveau dans l'objet info qui entre.
Ainsi, l'erreur sera renvoyée lorsqu'il y a
une erreur authentique qui se produit pendant le processus d'authentification,
mais les informations contiendront des informations si l'utilisateur n'existe pas.
Ainsi, passeport.authenticate transmet un message indiquant que
l'utilisateur n'existe pas ou que le nom d'utilisateur
est incorrect ou que le mot de passe est incorrect et ainsi de suite.
Donc, cette information sera transmise dans le message d'information.
Maintenant, nous verrons comment cela
nous est utile lorsque nous regardons le côté client un peu plus tard.
Donc, dans cette situation,
nous allons gérer cela comme suit,
et pas seulement que lorsque nous appelons ce passeport.authenticate,
nous devons également passer dans un req
, res, suivant comme les trois paramètres.
Donc, c'est la structure lorsque vous devez appeler passeport.authenticate et s'attendre à
ce qu'il vous transmette des informations comme celle-ci comme une méthode de rappel ici,
donc vous devez également fournir ce req, res,
suivant là aussi.
Maintenant, si cela se produit,
donc nous allons dire si err,
donc s'il y a une erreur qui se produit,
nous allons dire retourner la prochaine erreur, puis laisser
le gestionnaire d'erreur de notre routeur express et prendre soin de cela.
Maintenant, nous allons considérer d'autres situations, sinon l'utilisateur.
Donc, si nous avons atteint ce point,
cela signifie que ce n'est pas une erreur qui s'est produite,
mais peut-être que l'utilisateur n'a pas pu être trouvé.
Si l'utilisateur n'est pas trouvé
, l'utilisateur ici sera défini sur null dans ce cas.
Donc, dans cette situation,
si l'utilisateur n'existe pas,
alors nous devons être en mesure de transmettre des informations au côté serveur.
Donc, ce que nous ferons, c'est que nous transmettrons cette information dans ce format.
Donc, je vais découper ceci d'ici et
puis coller ici et puis nous allons éditer ceci.
Donc, si l'utilisateur est nul,
alors nous allons renvoyer un code d'état comme 401, ce qui signifie
non autorisé, puis nous allons renvoyer l'information succès false,
et ensuite nous ne transmettrons pas le jeton,
nous allons revenir le message d'état.
Donc, ici, nous allons dire
« Connexion sans succès » et puis la troisième information,
nous allons passer cette information cet objet que nous avons reçu ici comme
la troisième partie du message de réponse que nous envoyons de notre serveur ici.
Ainsi, l'indicateur de succès sera défini sur false,
l'état sera défini Connexion infructueuse et
les informations d'erreur transmises dans l'information seront transmises.
Maintenant, notez que cette situation se produira si
le nom d'utilisateur et le mot de passe sont incorrects,
et donc ce n'est pas une erreur dans le sens de l'erreur, mais
le fait que l'authentification n'a pas pu trouver l'utilisateur ou le mot de passe de l'utilisateur est incorrect.
Donc, cette information sera encodée dans l'information qui entre et de sorte que je
reviendrai comme une erreur du côté client.
La partie sinon
est gérée comme req.login.
Donc, si cela réussit,
le passeport.authenticate nous allons ajouter cette méthode appelée req.login à l'utilisateur.
Donc, à ce stade,
nous allons simplement passer l'objet utilisateur que nous avons obtenu.
Donc ici, si nous avons atteint ce point,
cela signifie que l'objet utilisateur n'est pas nul et qu'aucune erreur n'est survenue,
donc cela signifie que l'utilisateur peut être connecté.
Donc, nous allons dire erreur,
nous allons essayer de connecter l'utilisateur.
Donc, nous allons dire si err et
ensuite nous allons transmettre le même type d'information d'erreur que nous avons fait ici.
Donc, dans ce cas, en cas d'erreur,
alors nous allons passer un code d'état comme 401 et nous dirons que le succès
est faux et le statut comme Connexion infructueuse,
puis les informations d'erreur,
au lieu de l'information,
nous allons passer « Impossible de se connecter à l'utilisateur ».
Donc, c'est le message que nous transmettrons ici si l'erreur se produit.
Sinon, nous serions en bas ici.
Donc, à ce stade,
nous serions en mesure de générer le jeton.
Donc, si nous avons atteint ce point, cela
signifie que l'utilisateur s'est connecté avec succès,
et donc nous pouvons maintenant générer le jeton.
Donc, nous allons générer le jeton en fonction de l'ID de l'utilisateur,
puis nous allons retourner le jeton à l'utilisateur.
Donc, ici, nous allons dire le jeton var,
puis nous pouvons dire Res.StatusCode est 200, puis le succès res.json vrai,
donc, ce qui signifie que l'utilisateur s'est connecté avec succès.
Donc, l'état serait la connexion réussie.
Ensuite, la troisième partie,
au lieu de l'erreur,
je vais passer le jeton à l'utilisateur.
Donc, nous allons dire jeton,
ce jeton que nous venons d'obtenir plus tôt.
Ainsi, ce jeton sera transmis en tant que propriété token du message de réponse.
Donc, ici, notez que le succès est défini sur true, donc,
ce qui signifie que l'utilisateur s'est connecté avec succès,
et donc l'utilisateur peut continuer à ce stade.
Cela doit être fait dans le req.login ici.
Donc, à ce stade,
nous allons fermer le req.login.
Donc, notez que c'est à l'intérieur de ce req.Connectez-vous ici.
Donc, là-dedans, nous allons passer ces trois en arrière.
Alors, laissez-moi juste mettre ces trois lignes en retrait.
Donc, c'est ainsi que nous gérerions la méthode de journalisation de l'utilisateur.
Donc, encore une fois, en examinant ce code une fois de plus.
Donc, nous allons faire la publication du routeur,
mais au lieu de faire l'authentification du passeport juste là
, nous allons dire req, res
, ensuite, et puis à l'intérieur,
nous allons faire un passeport authentifier pour le local,
et cet authentification passera.
Donc, nous pouvons fournir une fonction de rappel à cela,
et cette fonction de rappel retournera soit l'erreur,
l'utilisateur, soit les informations ici.
Donc, si c'est une erreur,
nous allons juste permettre au gestionnaire d'erreurs express de prendre soin de cela.
Si l'utilisateur est nul,
cela signifie que la connexion de l'utilisateur a échoué,
et la raison de cela sera dans l'info.
Donc, cela reviendra comme l'erreur info dans le message de réponse ici.
Si nous arrivons à ce point,
alors l'utilisateur est vérifié avec succès.
Donc, alors nous allons nous connecter à l'utilisateur.
Donc, le passeport authentifier,
nous allons ajouter dans cette méthode appelée login au req, le message de demande.
Ainsi, nous pouvons appeler la connexion avec l'utilisateur.
Si cela renvoie une erreur,
alors nous retournerons l'erreur ici correctement.
Si ce n'est pas le cas, nous aurons atteint le point où l'utilisateur est authentifié avec succès.
Ainsi, nous pouvons générer le jeton Web JSON ici, puis retourner
le jeton Web JSON à l'utilisateur pour confirmer que l'utilisateur est correctement connecté.
Donc, c'est l'ensemble des étapes que nous allons utiliser ici.
Maintenant, la raison pour laquelle je fais une façon plus élaborée de le gérer est que
je veux faire la distinction entre la situation où une véritable erreur
se produit pendant le processus d'authentification par opposition à la situation
où le nom d'utilisateur est invalide ou le mot de passe est invalide.
Donc, ces deux cas seront traités par cette situation,
où l'information nous transportera l'information.
Donc, ce n'est pas une erreur en soi,
mais c'est une situation où l'utilisateur
n'est pas un utilisateur valide ou le mot de passe de l'utilisateur n'est pas valide.
Donc, c'est ainsi que nous allons gérer le processus de connexion de l'utilisateur.
En outre, je vais ajouter
une autre méthode ici appelée CheckJWTToken.
Il est tout à fait possible que le client se soit connecté et obtienne le jeton Web JSON,
un peu plus tard, le jeton Web JSON peut expirer.
Ainsi, si l'utilisateur tente d'accéder du côté client avec un jeton expiré au serveur,
le serveur ne sera pas en mesure d'authentifier l'utilisateur.
Par conséquent, à intervalles réguliers,
nous pouvons souhaiter effectuer une vérification croisée pour nous assurer que le jeton Web JSON est toujours valide.
Donc, c'est la raison pour laquelle j'inclus ceci,
un autre point de terminaison appelé CheckJWTToken.
Donc, si vous faites un accès au checkJWTToken en
incluant le jeton dans l'en-tête d'autorisation,
alors cet appel retournera un vrai ou faux
pour vous indiquer si le jeton Web JSON est toujours valide ou non.
S' il n'est pas valide, le côté client peut initier une autre connexion pour
que l'utilisateur obtienne un nouveau jeton Web JSON si nécessaire.
Donc, pour ce faire,
nous dirons cors.corsWithOptions et req,
res ici comme prévu.
Ici, nous dirons
passeport authentifier jwt
et session : false,
et cela reviendrait err, utilisateur, info.
Donc, rappelez-vous comment nous utilisons le passeport authentifier plus tôt.
Donc, nous appelons le JWT avec session false ici.
Donc, plus tôt ici, nous disons passeport authentifier local.
Donc, c'est pour l'authentification locale.
Donc, c'est pour l'authentification JSON Web Token.
Donc, quand nous appelons cela,
alors puisque cela va vérifier le jeton Web JSON, donc nous dirons,
si err retourne prochaine
erreur, puis laissez le gestionnaire d'erreurs express prendre soin de cette situation.
Ensuite, nous dirons, si ce n'est pas l'utilisateur,
si l'utilisateur n'existe pas, alors de la même manière.
Donc, ce qui signifie que si l'objet utilisateur a été
trouvé à partir du jeton Web JSON puis chargé sur req.user,
cela signifie que l'utilisateur est un utilisateur valide
et peut donc être autorisé à poursuivre.
Sinon, nous allons dire que l'utilisateur n'existe pas.
Donc, nous devons informer que le jeton Web JSON a expiré.
Donc, à ce stade,
nous allons envoyer une res avec
un code d'état de 401.
Donc, non autorisé, setHeader, Content-Type,
application/json, et puis nous retournerons res.
Res.json dira état JWT
invalide et ensuite,
nous retournerons un drapeau appelé success falls et ensuite,
nous retournerons les informations que nous obtenons si l'utilisateur
n'est pas authentifié comme l'erreur à ce stade.
Sinon, cela signifie que nous avons atteint ce point,
alors l'utilisateur est un utilisateur valide.
Donc, dans ce cas,
laissez-moi juste copier ce code ici,
nous allons envoyer un code d'état de 200, puis le res.json,
enverra JWT valide et réussi étant vrai.
La troisième partie, nous enverrons les informations de l'utilisateur.
Ainsi, lorsque ce point de terminaison est appelé avec la méthode get,
cela vérifiera si le jeton est valide ou non.
Si le jeton est valide,
alors vous recevrez cette réponse et de l'indicateur de succès dans la réponse,
vous pouvez vérifier si le jsonwebtoken est valide ou non.
Ceci est utile du côté client.
Maintenant, ce passeport authentifier ici devra être fourni
avec req et res comme les deux paramètres ici.
Donc, c'est comme ça que nous appelons l'authentification du passeport.
Donc, notez que chaque fois que vous appelez
passeport authentifier et que
vous attendez cette fonction de rappel ici, vous devez ajouter à ce point req.res au passeport authentifier à l'arrière ici.
Dans notre serveur d'API de repos,
nous avions implémenté nos commentaires de telle sorte que les commentaires
formaient des sous-documents à l'intérieur du document du dishe, de
sorte qu'ils achètent chaque plat inclus son propre ensemble de commentaires.
Mais la façon dont nous avons implémenté notre client React est
telle que les commentaires sont conservés indépendamment des plats,
et les commentaires eux-mêmes portaient l'ID de plat correspondant.
Maintenant, ce sont deux façons différentes d'
implémenter le côté serveur ainsi que le côté client.
Dans l'application Angular que nous sommes implémentés dans notre spécialisation Angular,
nous avions utilisé la méthode de sous-document pour
gérer les commentaires dans notre application client Angular.
Ainsi, le serveur d'API restante a été
implémenté de telle sorte qu'il était plus approprié pour le client Angular.
Mais pour les clients React puisque nous avons gardé les commentaires indépendants des plats,
puis utiliser l'ID plat à l'intérieur du commentaire,
nous devons donc restructurer notre serveur API de repos,
donc c'est que nous avons un point de terminaison de commentaire séparé indépendant du point de terminaison de plats.
Donc, nous devons restructurer notre code dans le serveur
pour introduire le point de terminaison de l'API REST /comments à ce stade.
Donc, pour ce faire,
allons de l'avant et implémentons un nouveau modèle appelé comment.js.
Donc, en allant dans les modèles,
permettez-moi d'implémenter un nouveau fichier nommé comments.js.
Dans le fichier comments.js,
nous allons déplacer le CommentSchema du
fichier dishes.js dans le fichier comments.js, puis le supprimer complètement du fichier dishes.js.
Mais avant de le faire,
nous devons copier le mongoose et le schéma d'ici,
alors laissez-moi simplement copier ceci de dishes.js dans comment.js.
Après cela, en allant dans dishes.js,
laissez-moi couper ce CommentSchema complètement à partir d'ici,
parce que nous aurons ceci séparément dans le modèle de commentaires ici.
Donc, déplacons cela dans le modèle de commentaires, puis collez-le ici.
Mais bien sûr, ce n'est pas complet,
nous allons mettre à jour un peu le CommentSchema.
Mais avant de le faire,
revenez au fichier dishes.js et dans le fichier vaisselle,
nous allons supprimer les commentaires du Dish.Schema,
parce que nous allons stocker le contenu séparément des
plats dans cette version de notre serveur.
Donc, c'est ainsi que nous allons mettre à jour le modèle de plats ici.
Donc, nous avons complètement supprimé les commentaires du modèle de vaisselle ici.
Entrer dans le modèle de commentaires,
donc nous voyons maintenant que nous avons le CommentSchema implémenté ici.
Mais en outre, dans le CommentsChema,
nous devons maintenant pointer explicitement vers
le plat spécifique pour lequel ce commentaire est le commentaire correspondant.
Maintenant, c'est là que
notre population de mangoustes et
la façon dont nous stockons les identifiants d'objets viennent à notre secours.
Donc, nous allons mettre à jour le CommentSchema disant que nous aurons la note,
le commentaire et l'auteur ici.
En plus de l'auteur,
nous allons introduire un champ de plus appelé comme le plat ici qui est
du type : Mongoose.Schema types.Objectid,
et donc cela se référera au plat ici.
Donc, ce serait une référence d'objet au modèle plat ici,
et donc avec cette modification maintenant
nos commentaires contiendront le champ d'évaluation, le champ de commentaire,
l'auteur qui est à nouveau une référence à l'utilisateur correspondant,
puis le champ plat qui est une référence au plat ici.
Donc, ce qui signifie que nous allons maintenant devoir
remplir les commentaires avec l'auteur et le champ de plat.
Une fois que nous avons terminé cela,
alors nous dirons var Comments
mongoose.model et nous appellerons ce 'Commentaire',
puis cela utilise le CommentSchema que nous venons de définir ici,
et ensuite nous devons exporter ceci à partir d'ici,
les commentaires.model d'ici.
Donc, maintenant que nous avons introduit le comments.model,
alors nous allons aller de l'avant et ensuite introduire un nouveau routeur appelé commentUter.
Donc, pour introduire le routeur de commentaires,
allons dans les routes ici,
puis créer un nouveau fichier nommé commentRouter.js.
Dans le commentRouter.js, laissez-moi copier quelques choses
à partir du Dish.Router.
Donc, nous aurons ces commentaires ici,
alors laissez-moi copier ces choses de la et aussi,
pendant que je suis à elle, laissez-moi simplement les copier aussi jusqu'à ce point,
et puis je vais mettre à jour cela un peu plus tard.
Donc, en entrant dans le commentUter,
nous avons besoin de toutes ces parties,
donc nous allons dire Com, Express, BodyParser, mongoose,
authentifier, cors, et ensuite nous allons
importer des commentaires à partir de modèles/commentaires.
Ensuite, nous appellerons ceci comme le commentrouter qui est un Express.Router ici.
Ensuite, nous dirons CommentUter utiliser BodyParser,
et puis cela deviendrait maintenant la route CommentUter.
Maintenant, nous devons aller dans le Dish.Router, puis
supprimer toutes les parties qui se réfère aux commentaires ici.
Donc, laissez-moi juste découper cette partie et ensuite nous les réutiliserons pour notre CommentUter.
Donc, tout cela ne sont plus nécessaires dans le Dish.Router.
Donc, je vais supprimer tout cela du Dish.Router ici,
alors laissez-moi les découper,
tout ce qui concerne la route des commentaires du Dish.Router,
puis nous allons dans le commentUter,
puis laissez-moi aller de l'avant et coller cela en place ici,
puis nous allons éditer cela ici.
Ensuite, nous devons exporter le commentUter.
Donc, va exporter le commentrouter pour nous.
Mais bien sûr, ce code n'est pas complètement exact.
Donc, nous devons aller de l'avant et corriger ce code ici.
Donc, pour ce code,
nous nous rendons compte maintenant que ce n'est pas la route Dish.Router,
au lieu de cela devrait être
le /endpoint car nous
allons le monter dans le point de terminaison /comments ici.
Donc, nous allons dire commentUter,
puis les options CorsWithOptions (req,
res) qui reste en tant que telles là,
puis le get cors.cors puis req.res,
puis celui-ci deviendra des commentaires.
FindById, req.
Donc, ce serait commentaires.find
et req.query ici.
Donc, lorsque les commentaires sont trouvés
, alors, à ce stade,
nous allons remplir l'auteur,
déjà là, remplir ici.
Donc, je vais juste supprimer ce commentaires.author, et puis,
nous allons simplement remplir l'auteur ici.
Ensuite, cela nous donnerait des commentaires ici.
Ensuite, nous dirons, cela peut être simplifié de manière significative.
Donc, l'erreur de capture est là de toute façon.
Donc, quand le commentaire arrivera, il reviendra simplement.
Désolé, ça devrait l'être.
Donc, si pour le get,
quand nous obtenons les commentaires,
commentaires.Trouver req.query, .populate auteur ici,
et puis, nous allons dire, .then commentaires,
et puis, nous dirons, RES.StatusCode 200,
setHeader, puis, nous allons retourner les commentaires d'ici,
res.json commentaires d'ici.
Maintenant, je ne remplis pas les plats ici parce que je n'ai pas explicitement besoin de
la vaisselle comme j'utilise cette information dans mon client de réaction.
Je n'ai besoin que de l'ID plat,
et l'ID plat est déjà présent là,
et c'est assez bon pour que je puisse utiliser ces données dans mon client de réaction.
Donc, je vais le laisser en tant que tel là.
Je vais seulement renseigner les informations de
l'auteur là-bas parce que nous avons besoin de l'information complète de l'auteur
chaque fois que nous rendons un élément de commentaire dans notre client de réaction.
Donc, le get sera mis à jour comme ceci ici.
Pour le post CorsWithOptions,
nous dirons, Authenticate.VerifyUser req, res, suivant.
Évidemment, pour qu'un commentaire soit publié,
vous devez que l'auteur soit un utilisateur connecté valide.
Seulement alors, vous autoriserez l'utilisateur à poster un commentaire.
Ensuite, le commentaire lui-même vient dans le corps du message de demande entrante.
Donc, d'abord, nous allons vérifier le corps
pour nous assurer que le commentaire est inclus dans le corps ici.
Donc, ici, je vais supprimer toutes ces parties, puis,
simplifier davantage, et ensuite,
nous allons implémenter cela correctement là.
Donc, à ce stade, nous dirons,
si req.body n'est pas égal à null,
ce qui signifie qu'il y a un commentaire qui est enfermé à l'intérieur du corps.
Donc, laissez-moi couper ceci et déplacer ceci dans la partie if ici,
et ensuite, nous allons éditer ça ici.
Donc, si le corps n'existe pas,
alors nous allons provoquer une erreur.
Donc, nous dirons, err nouvelle erreur,
Commentaire introuvable dans le corps de la requête.
Donc, nous allons soulever cette erreur ici.
L' état de l'erreur est 404.
Ensuite, nous dirons, retournez l'erreur suivante.
Donc, gérons la partie erreur ici si le corps
ne contient pas les informations de commentaire appropriées.
S' il contient, alors, bien sûr,
ce que nous ferons ensuite est,
nous dirons, req.body.author est req.user. _id.
La raison pour laquelle nous faisons cela est que nous nous souvenons que s'il s'
agit d'un utilisateur enregistré et que l'utilisateur s'est connecté,
alors req.user contiendra les informations utilisateur.
Donc, je n'ai besoin que de l'ID de l'utilisateur actuellement connecté.
Donc, nous allons dire, req.user. _id, puis,
nous allons définir req.body.author sur req.user. _id.
Maintenant, l'utilisateur de vérification s'assurera automatiquement que si vous atterrissez à ce stade,
alors vous auriez évidemment un utilisateur qui s'est connecté correctement.
Sinon, cela aurait déjà causé le problème là-bas.
Ainsi, lorsque vous atteignez à ce stade,
vous auriez un utilisateur valide qui s'est déjà connecté au système.
Donc, c'est là que vous seriez en mesure de le faire maintenant.
Donc, ce que nous faisons est que le champ auteur,
nous le définissons explicitement dans l'ID de l'utilisateur ici afin que
le req.body contienne les parties restantes du commentaire.
Donc, comme vous le savez, le commentaire contient la note,
le commentaire lui-même, et l'auteur, et les champs de plat.
Ainsi, les parties restantes auraient dû être remplies par l'utilisateur.
La note, le commentaire
et les informations sur le plat doivent déjà être remplis
dans le corps du message de demande entrante.
La partie auteur est laissée vide là,
que nous allons explicitement insérer à ce stade dans le corps ici.
Donc, maintenant, req.body contiendra toutes les informations de commentaire.
Donc, à ce stade,
au lieu de faire cela, nous dirons, commentaires.Créer.
En utilisant req.body, nous allons créer les commentaires ici.
Ensuite, cela retournera
le commentaire correspondant au commentaire que nous venons d'insérer ici.
Maintenant, une fois que le commentaire est revenu,
alors nous devrions faire commentaires.findById.
Maintenant, la raison pour laquelle nous devons le faire est que nous devons
remplir les informations de l'auteur ici.
Donc, nous allons dire, FindById commentaires. _id,
puis, nous allons remplir les informations de l'auteur dans le commentaire lui-même.
Ensuite, nous allons dire, puis commenter.
Maintenant, évidemment, ici, vous constaterez que le commentaire
existera parce que nous venons d'insérer ce commentaire en place là-bas.
Donc, ici, nous allons simplement retourner, RES.StatusCode est 200,
RES.setHeader est Content-Type, application/json.
Le commentaire lui-même dira, res.json, puis,
retourner le commentaire à ce stade.
Donc, c'est la façon dont nous allons gérer l'insertion d'
un nouveau commentaire dans notre côté client ici.
Pour le mettre, comme vous vous rendez compte,
vous ne serez pas en mesure de faire un put sur les /comments/ points de fin.
Donc, nous dirons, l'opération PUT n'est pas prise en charge sur le point final /comments/.
C' est le but. C'est le message que tu reviendras.
Donc, StatusCode est 403,
puis, l'opération PUT n'est pas prise en charge sur /comments/.
Maintenant, quand nous faisons une suppression,
laissez-moi juste couper cela d'ici, et puis, nous dirons,
commentaires.Supprimer.
écrit vide. Ainsi, lorsque vous effectuez une suppression sur le point de terminaison des commentaires barre oblique,
vous supprimez tous les commentaires de votre système.
Donc, c'est une opération très dangereuse, et donc,
vous ne devriez pas faire cela normalement.
Donc, nous allons seulement permettre à l'administrateur d'effectuer une telle opération.
Donc, nous allons supprimer tous les commentaires à partir de là.
Donc, lorsque vous obtenez la réponse,
alors nous dirons RES.StatusCode 200.
Alors, laissez-moi juste copier ces parties ici,
et ensuite venir les coller ici.
Donc, nous allons dire, commentaires.remove.
Ensuite, répondez à l'application res.StatusCode 200 json et ensuite res.json (réponse) ici.
Donc, c'est comme ça que nous gérons la suppression.
Opération de suppression sur le point de terminaison des commentaires barre oblique.
Maintenant, la route suivante est le routeur de commentaires.
Donc, ici, nous allons dire commentrouter.route et
le point final ici serait la barre oblique commentID.
Donc, ici les options resteront en tant que telles.
Ensuite, pour obtenir sur le routeur actuel,
pour le get nous dirons, commentaires.findById (req.params.
Ce serait commentID.
Donc, une fois que nous avons trouvé le commentaire spécifique,
alors nous allons remplir juste l'auteur à partir de là.
Ensuite, une fois que vous remplissez l'auteur,
nous dirons, puis commencerons.
Maintenant, toute cette partie est inutile ici,
donc je vais juste supprimer la partie.
Ce n'est pas non plus la chose appropriée ici.
Alors, laissez-moi renommer le code.
Donc, nous allons dire pour obtenir des commentaires.FindById,
puis remplir l'auteur,
puis commenter, RES.StatusCode est 200, setHeader.
Ensuite, les autres sont Json.
Nous reviendrons simplement les commentaires ici.
Donc, nous allons retourner le commentaire à ce stade, res.json (commentaire).
Vous trouverez le commentaire spécifique,
puis retournez ce commentaire pour le post.
Pour la post-opération, comme vous le savez,
la post-opération n'est pas
autorisée sur les commentaires commentID.
Donc, c'est le message que nous allons envoyer,
opération POST non supportée sur les commentaires barre oblique commentID.
Donc, c'est le message que nous dirons pour la mise.
Maintenant, pour le mettre, nous dirons commentaires.Trouver où Id (req.params.commentID).
Donc, nous allons trouver le commentaire là,
et il commentaire, donc pour le mettre.
Donc, nous allons trouver le commentaire là,
et ensuite nous dirons pour les commentaires.
Donc, si nous trouvons le commentaire,
si le commentaire n'est pas nul,
alors nous allons également vérifier si comment.author.
Si ce n'est pas le cas, commenter.arthur est égal (req.user. _id).
Donc, nous recoupons pour nous assurer que
le comments.author est le même que l'utilisateur actuel.
Seul l'utilisateur actuel qui est connecté - si l'utilisateur est le même que l'auteur des commentaires
, l'utilisateur sera autorisé à mettre à jour.
Donc, c'est la première chose que nous allons vérifier.
Donc, commentaires, puis commentaires.author.equal à rec.user. _id.
Si ce n'est pas le cas, vous direz que vous n'êtes pas autorisé à mettre à jour ce commentaire.
Comme vous voyez le .403,
puis retournez l'erreur suivante ici.
Donc, nous allons créer l'erreur là.
Ensuite, après cela, nous dirons
req.body.author, req.user. _id,
c'est important.
Maintenant, ces deux ne sont pas nécessaires ici,
parce que nous sauvegardons directement le commentaire.
Ensuite, les pilules, nous dirons commentaires.findByidAndUpdate,
et req.params.commentID.
Donc, nous trouverons ce commentaire spécifique,
car nous avons déjà reçu l'ID de commentaire.
Donc, nous allons faire des commentaires findById req.params.commentId.
Ensuite, nous dirons alors (commentaire).
Lorsque vous fournissez le req.params.commentID,
nous devrons fournir explicitement le deuxième paramètre, ce
qui est ce que nous voulons changer.
Donc, nous dirons $set : req.body.
Donc, le deuxième paramètre, essentiellement,
vous indique quelle partie vous changez.
Maintenant, puisque nous avons reçu le corps contenant le commentaire mis à jour,
nous allons juste mettre à jour le commentaire entier lui-même.
Ensuite, l'autre partie que nous demanderons est nouvelle : vraie.
Ainsi, cela garantira que le commentaire mis à jour sera retourné dans
le den de cet appel aux commentaires.findByidAndUpdate.
Donc, nous allons dire ensuite commentaires.
Lorsque ce commentaire est retourné,
nous dirons Comments.findById (commentaire. _id).
Ensuite, renseignez l'auteur là.
Nous allons remplir l'auteur là,
puis nous dirons ensuite commentaire.
Donc, vous voyez que nous allons obtenir le commentaire, puis retourner le commentaire à ce stade.
Donc, c'est ainsi que nous allons mettre à jour le commentaire.
Donc, c'est la situation où le commentaire n'est pas nul.
Donc, cette instruction si pour le commentaire n'est pas nulle.
Donc, le reste si la partie,
maintenant ce n'est pas applicable,
donc nous allons dire autre, erreur.
L' erreur dans ce cas.
Donc, si le commentaire est nul,
cela signifie que nous n'avons pas trouvé le commentaire là-dedans,
donc vous ne pouvez pas modifier un commentaire inexistant.
Donc, nous allons dire err,
nouveau commentaire d'erreur req.params.commentID introuvable et ensuite nous allons retourner l'erreur.
Donc, c'est ainsi que nous allons gérer la partie put de notre commentaire ici,
puis enfin la suppression.
Pour la suppression, encore une fois nous devrons d'abord trouver
commentaires.findById (req.params.commentId)
, puis commenter.
Donc, nous allons chercher le commentaire.
Donc, nous allons d'abord vérifier si le commentaire n'est pas égal à null.
C' est important de vérifier ici.
Ensuite, la partie suivante que nous vérifierons est si le comment.author est égal à req.user. _id.
Nous nous assurons que cet utilisateur qui tente de supprimer
ce commentaire est exactement le même utilisateur que celui qui a inséré le commentaire en premier lieu.
Si ce n'est pas le cas,
alors vous verrez « Vous n'êtes pas autorisé à supprimer ce commentaire ! »
Et puis renvoyez le statut là-bas.
Puis en bas ici,
nous dirons commentaires.findbyidandRemove ici.
Donc, nous dirons commentaires.findByidandRemove (req.params.commentID),
alors nous obtiendrons une réponse du commentaire.
Donc, à ce stade,
nous allons simplement dire, RES.StatusCode.
Donc, nous allons dire commentaires.findByIdAndRemove puis réponse.
Si elle est correctement supprimée,
nous dirons 200, puis la
réponse res.json ici et nous allons également attraper l'erreur à ce stade.
Donc, laissez-moi juste copier ça ici et ensuite nous inclurons la capture de l'erreur à ce stade.
Donc, c'est la première chose qu'on vérifiera.
Nous allons nous assurer que le commentaire n'est pas égal à null.
Sinon, c'est donc l'autre partie.
Donc, c'est la partie autre de l'erreur if else
nouveau commentaire req.params.commentId pas trouvé et puis
404 et envoyer la partie d'autre pour nous et puis la partie alors gérera de manière appropriée.
Donc, ce sont les changements que nous faisons pour le routeur de commentaires ici.
Donc, nous gérons le get put post and delete pour
les commentaires barre oblique et les commentaires barre oblique barre oblique impact commentID.
Donc, une fois que nous avons terminé cela,
alors nous devons l'inclure dans le fichier app.js.
Donc, nous allons aller dans le fichier app.js et puis nous dirons
var commentrouter
exiger routes/commentrouter.
Donc, nous avons le routeur de commentaire ici et puis nous allons
descendre dans le fichier app.js ci-dessous et
ensuite nous dirons app.use
commentaires slash, commentUter ici.
C' est ça. Alors maintenant,
mon routeur de commentaires est prêt.
Alors, allons de l'avant et sauvegardons tous les changements.
Ensuite, notre serveur est maintenant mis à jour
afin de traiter toutes les demandes de nos clients React ici.
Maintenant, si vous voulez faire l'alternative, c'est-à-dire que
vous avez vos commentaires en tant que sous-documents de votre plat et que vous voulez gérer cela,
alors vous devrez mettre à jour le client React pour
pouvoir utiliser les commentaires de chaque plat de manière appropriée.
Cela sera laissé comme un exercice pour vous.
Pensez à la façon dont vous conceviez votre client de réaction de sorte qu'il
fonctionne très bien avec
la version antérieure du serveur qui avait les commentaires comme sous-documents de vos plats eux-mêmes.
Maintenant, ce sera une façon intéressante de l'implémenter.
Bien sûr, c'est un peu plus compliqué que la façon dont nous avons
implémenté le client React où nous avons gardé
les commentaires indépendants des plats, mais le travail supplémentaire est alors
la responsabilité du côté client car vous devez sélectionner
les commentaires appropriés lorsque vous affichez un plat spécifique.
Vous devez sélectionner les commentaires de tous les commentaires ici.
Donc, c'est un travail supplémentaire que notre client React fait en raison
du fait que nous avons séparé les commentaires des plats eux-mêmes.
De même, si vous pouvez reconcevoir votre client angulaire pour être en mesure de faire
face à la situation où les commentaires sont conservés indépendamment de vos plats.
Maintenant, donc ce sont tous des exercices que vous pouvez faire pour voir comment vous pouvez
étendre vos applications clientes pour gérer n'importe quel type de serveur,
les deux types différents de serveurs là-bas.
Donc, avec cela, nous terminons la mise à jour de notre serveur ici.
Donc, avec cela, nous avons tout mis à jour sur le côté serveur.
Donc, sauvegardons toutes les modifications du côté serveur.
Maintenant, notre serveur est prêt à traiter les demandes entrantes de notre client React.
Avec cela, nous terminons cet exercice.
Dans cet exercice, nous avons maintenant préparé notre serveur express
pour traiter les demandes entrantes de notre client React.
Dans le prochain exercice, nous allons examiner le client de réaction plus en détail pour
comprendre comment il communique avec ce serveur supplémentaire.
C' est le bon moment pour vous de faire
une couverture git avec le message intégrant le client et le serveur.