1
00:00:03,650 --> 00:00:08,385
Ya habíamos desarrollado un servidor API REST completo

2
00:00:08,385 --> 00:00:12,485
usando Express y MongoDB como parte de este curso.

3
00:00:12,485 --> 00:00:16,965
Para que ese servidor pueda comunicarse de manera significativa con nuestro cliente,

4
00:00:16,965 --> 00:00:19,590
haremos algunos ajustes menores para que

5
00:00:19,590 --> 00:00:22,440
devuelva el tipo correcto de datos para que

6
00:00:22,440 --> 00:00:24,780
nuestra implementación del cliente pueda trabajar de

7
00:00:24,780 --> 00:00:28,935
manera más eficiente con los datos devueltos desde nuestro sitio de servidor.

8
00:00:28,935 --> 00:00:30,410
Por lo tanto, para hacer eso,

9
00:00:30,410 --> 00:00:36,580
trabajemos en algunos ajustes en nuestro sitio de servidor en este ejercicio.

10
00:00:36,580 --> 00:00:39,215
Antes de comenzar este ejercicio,

11
00:00:39,215 --> 00:00:42,410
supongo que no ha hecho

12
00:00:42,410 --> 00:00:46,430
la lección anterior sobre la integración del cliente angular y

13
00:00:46,430 --> 00:00:55,395
el servidor porque está haciendo esta lección a través de la especialización React.

14
00:00:55,395 --> 00:01:01,190
Por lo tanto, los cambios que haré en el servidor supondrán que

15
00:01:01,190 --> 00:01:07,430
la versión del servidor que está modificando es anterior a la lección anterior.

16
00:01:07,430 --> 00:01:11,540
En caso de que haya realizado esa lección en el cliente angular,

17
00:01:11,540 --> 00:01:16,505
algunos de los cambios que ha hecho en el servidor se repetirán de nuevo

18
00:01:16,505 --> 00:01:22,495
en este ejercicio para que pueda omitir esa parte de los cambios.

19
00:01:22,495 --> 00:01:26,055
Entra a nuestro servidor en el editor.

20
00:01:26,055 --> 00:01:29,125
Antes de comenzar a trabajar en el servidor,

21
00:01:29,125 --> 00:01:33,530
le sugiero que descargue todas las imágenes que he

22
00:01:33,530 --> 00:01:38,380
proporcionado como un archivo zip en los recursos del ejercicio llamados images.zip.

23
00:01:38,380 --> 00:01:43,160
Descomprima el archivo y luego obtenga todas las imágenes desde allí y luego copie esas imágenes

24
00:01:43,160 --> 00:01:48,290
en la carpeta de imágenes públicas en nuestro servidor.

25
00:01:48,290 --> 00:01:55,010
Por lo tanto, ven que aquí he copiado todas las imágenes en mi carpeta de imágenes públicas aquí

26
00:01:55,010 --> 00:01:58,160
ya porque nuestro servidor es el que va

27
00:01:58,160 --> 00:02:02,275
a servir todas estas imágenes para nuestra aplicación cliente.

28
00:02:02,275 --> 00:02:07,835
A continuación, vamos al CORS y ajustamos la lista blanca aquí.

29
00:02:07,835 --> 00:02:11,565
Por lo tanto, para nuestra aplicación cliente React,

30
00:02:11,565 --> 00:02:15,275
si comenzamos con el comando yarn start,

31
00:02:15,275 --> 00:02:18,470
se ejecuta en el nombre de su computadora: 3001.

32
00:02:18,470 --> 00:02:22,040
Por lo tanto, cualquier solicitud que llegue desde nuestra ubicación

33
00:02:22,040 --> 00:02:25,760
al servidor llevará eso como el origen allí.

34
00:02:25,760 --> 00:02:30,380
Así que es por eso que voy a agregar eso a mi lista blanca para que

35
00:02:30,380 --> 00:02:35,390
cualquier problema CORS se aborde automáticamente.

36
00:02:35,390 --> 00:02:40,985
Entonces, al entrar en el archivo cors.js en mi lista blanca aquí,

37
00:02:40,985 --> 00:02:49,460
permítanme agregar el

38
00:02:49,460 --> 00:02:55,640
nombre de la computadora http://my: 3001 y este es

39
00:02:55,640 --> 00:02:58,610
el origen desde el cual mi cliente

40
00:02:58,610 --> 00:03:02,075
originará las solicitudes que vienen a este servidor.

41
00:03:02,075 --> 00:03:07,075
Por lo tanto, de esa manera mi CORS no causaría problemas a mi cliente.

42
00:03:07,075 --> 00:03:11,690
A continuación, necesitamos actualizar algunas de las rutas para

43
00:03:11,690 --> 00:03:17,690
manejar los parámetros de consulta y también algunos otros ajustes menores.

44
00:03:17,690 --> 00:03:21,280
Permítanme comenzar con el archivo promoRouter.js.

45
00:03:21,280 --> 00:03:25,010
Eso es fácil de actualizar.

46
00:03:25,010 --> 00:03:27,570
Entonces, entrando en el archivo promoRouter.js,

47
00:03:27,570 --> 00:03:32,360
en el archivo PromoRouter para la solicitud get que obtenemos

48
00:03:32,360 --> 00:03:37,610
aquí en lugar de hacer promociones encontrar con un objeto JavaScript vacío,

49
00:03:37,610 --> 00:03:47,320
aquí proporcionaría el req.query como parámetro para las promociones encontrar aquí,

50
00:03:47,320 --> 00:03:49,680
lo mismo con el enrutador líder también.

51
00:03:49,680 --> 00:03:52,745
Entonces, déjame ir al archivo leaderRouter.js.

52
00:03:52,745 --> 00:03:54,815
En el enrutador líder también,

53
00:03:54,815 --> 00:04:00,545
aquí donde encontrará Leaders.Find con el objeto JavaScript vacío en su lugar

54
00:04:00,545 --> 00:04:06,685
reemplace eso con el req.query para que los parámetros de consulta se pasen.

55
00:04:06,685 --> 00:04:14,260
Entonces, aquí es donde pasaremos la característica: true como parámetro de consulta aquí.

56
00:04:14,260 --> 00:04:16,945
Ahora, después de haber ajustado estos dos,

57
00:04:16,945 --> 00:04:19,340
ahora trabajemos en el enrutador de platos.

58
00:04:19,340 --> 00:04:22,115
Por lo tanto, vaya al archivo dishRouter.js,

59
00:04:22,115 --> 00:04:26,310
incluso en el enrutador de plato también la misma actualización aquí.

60
00:04:26,310 --> 00:04:31,200
Por lo tanto, vaya a estos platos.Encuentre en el método get aquí,

61
00:04:31,200 --> 00:04:33,945
cambie eso a req.query.

62
00:04:33,945 --> 00:04:38,070
Entonces, con esto, mi actualización del enrutador de platos se ha completado.

63
00:04:38,070 --> 00:04:42,085
Por lo tanto, ahora hemos actualizado el enrutador promocional, el líder

64
00:04:42,085 --> 00:04:43,850
y el enrutador de plato,

65
00:04:43,850 --> 00:04:48,050
luego pasaremos a actualizar el enrutador favorito.

66
00:04:48,050 --> 00:04:54,380
Ahora, habría implementado el router favorito como parte de su cuarta asignación.

67
00:04:54,380 --> 00:04:56,530
Ahora, en el enrutador favorito,

68
00:04:56,530 --> 00:04:58,910
verá que para el enrutador favorito,

69
00:04:58,910 --> 00:05:01,010
no le estoy mostrando la parte restante porque

70
00:05:01,010 --> 00:05:03,435
debería haber hecho como parte de su asignación.

71
00:05:03,435 --> 00:05:11,520
Primero, permítanme llamar su atención sobre el método get para Favoriterouter.route:DISHID.

72
00:05:11,520 --> 00:05:17,405
Ahora voy a usar este método get para verificar que

73
00:05:17,405 --> 00:05:25,460
el plato específico con el ID del plato ya sea un favorito para el usuario.

74
00:05:25,460 --> 00:05:29,130
Entonces, en lugar de simplemente decir getoperation.supported,

75
00:05:29,130 --> 00:05:36,165
solo voy a aprovechar la presencia de esta operación get y luego diremos,

76
00:05:36,165 --> 00:05:47,500
Favorites.Findone y diremos usuario: req.user. _id

77
00:05:49,220 --> 00:05:59,340
Por lo tanto, vamos a encontrar los favoritos para ese usuario en particular y luego vamos a decir luego

78
00:06:03,070 --> 00:06:25,530
favoritos y atrapar el error siguiente.

79
00:06:25,530 --> 00:06:35,265
Entonces, de manera similar aquí, vamos a añadir en el error aquí, el siguiente error aquí.

80
00:06:35,265 --> 00:06:37,380
Entonces, dentro de esto entonces,

81
00:06:37,380 --> 00:06:39,495
cuando obtengamos los favoritos,

82
00:06:39,495 --> 00:06:45,360
entonces verificaremos si no los favoritos.

83
00:06:45,360 --> 00:06:47,690
Por lo tanto, si no hay favoritos para

84
00:06:47,690 --> 00:06:53,900
este usuario, obviamente el plato que estamos comprobando no existe, por

85
00:06:53,900 --> 00:07:07,520
lo que devolveremos 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 y luego volveremos diciendo que existe false.

88
00:07:36,735 --> 00:07:44,215
Lo que estamos especificando aquí es que si llegan se hace hasta este punto final con un ID de plato,

89
00:07:44,215 --> 00:07:52,835
esta bandera existe aquí se establecerá en verdadero si este plato es parte de mis favoritos.

90
00:07:52,835 --> 00:07:55,290
Si este plato no es parte de mis favoritos,

91
00:07:55,290 --> 00:07:58,100
estableceré que existe bandera en falso.

92
00:07:58,100 --> 00:08:01,190
Así que aquí, ves que dado que no tengo ningún favorito, así que

93
00:08:01,190 --> 00:08:04,770
existe debería ser automáticamente falso en este punto.

94
00:08:04,770 --> 00:08:13,020
Entonces, diremos que existe falso y luego devolveremos los favoritos aquí.

95
00:08:13,180 --> 00:08:19,090
Bueno, obviamente, en este caso los favoritos serían nulos en este punto.

96
00:08:19,090 --> 00:08:26,440
De lo contrario, lo que significa que los favoritos no es nulo,

97
00:08:26,440 --> 00:08:32,750
así que vamos a decir si Favorites.Dishes.IndexOf.

98
00:08:36,840 --> 00:08:45,995
Así que vamos a estar buscando a Req.Params.Dishid.

99
00:08:45,995 --> 00:08:51,220
Por lo tanto, vamos a buscar esta matriz de platos favoritos para

100
00:08:51,220 --> 00:08:56,605
ver si este plato existe allí y si no existe,

101
00:08:56,605 --> 00:09:00,525
obviamente esto devolverá un índice negativo aquí.

102
00:09:00,525 --> 00:09:02,340
En ese caso también,

103
00:09:02,340 --> 00:09:05,440
volveré exactamente lo mismo que aquí.

104
00:09:05,440 --> 00:09:08,630
Por lo tanto, si devuelve un índice negativo entonces eso significa que

105
00:09:08,630 --> 00:09:12,260
aunque este usuario en particular tiene un conjunto de favoritos,

106
00:09:12,260 --> 00:09:16,190
este plato específico no existe en

107
00:09:16,190 --> 00:09:22,340
la lista de sus favoritos, por lo que devolverá existe falso aquí.

108
00:09:22,340 --> 00:09:30,255
Ahora, de lo contrario eso significa que el plato existe en la lista de favoritos.

109
00:09:30,255 --> 00:09:31,859
Por lo tanto, en este caso,

110
00:09:31,859 --> 00:09:36,670
voy a devolver el código de estado 200 existe es verdadero.

111
00:09:36,670 --> 00:09:43,825
Así, cuando el usuario realiza una operación get en este extremo con

112
00:09:43,825 --> 00:09:52,015
el /Favorites/Dishid donde se suministra el Id de plato

113
00:09:52,015 --> 00:09:55,630
como el parámetro aquí, como el parámetro de solicitud aquí,

114
00:09:55,630 --> 00:10:00,650
entonces comprobaremos si ese plato existe en los favoritos.

115
00:10:00,650 --> 00:10:05,775
Si ninguno de los favoritos existe para este usuario, entonces devolveremos un false.

116
00:10:05,775 --> 00:10:08,120
Del mismo modo, si los favoritos existen pero

117
00:10:08,120 --> 00:10:12,320
ese plato en particular no existe en los favoritos, entonces devolveremos false, de

118
00:10:12,320 --> 00:10:13,910
lo contrario devolveremos true.

119
00:10:13,910 --> 00:10:20,260
Así que esta bandera existe puede ser utilizada por mi cliente para comprobar si este plato es

120
00:10:20,260 --> 00:10:27,755
parte de la lista de platos favoritos para este usuario o no.

121
00:10:27,755 --> 00:10:30,139
También mientras estamos en favoritos,

122
00:10:30,139 --> 00:10:33,410
cada vez que hacemos cambios en los favoritos,

123
00:10:33,410 --> 00:10:37,870
queremos poder rellenar la información del usuario y los platos,

124
00:10:37,870 --> 00:10:39,535
los favoritos, antes de regresar.

125
00:10:39,535 --> 00:10:43,240
Por ejemplo, en el post que hacemos,

126
00:10:43,240 --> 00:10:48,470
cuando guardamos los favoritos a continuación, en este punto,

127
00:10:48,470 --> 00:10:55,470
nos gustaría hacer primero favoritos.

128
00:10:55,620 --> 00:11:06,380
FindById, así que como acabamos de hacer los cambios

129
00:11:07,740 --> 00:11:15,325
diremos favorite_id y rellenaremos tanto el usuario como también

130
00:11:15,325 --> 00:11:25,490
los platos en los favoritos.

131
00:11:25,740 --> 00:11:32,420
Luego, cuando se devuelvan los favoritos,

132
00:11:32,610 --> 00:11:36,940
devolveremos esos favoritos en su lugar.

133
00:11:36,940 --> 00:11:40,440
Así que, permítanme hacer este cambio aquí.

134
00:11:40,440 --> 00:11:46,910
Por lo tanto, vamos a cortar esto desde aquí y luego dentro del entonces,

135
00:11:46,910 --> 00:11:49,645
vamos a devolver los favoritos.

136
00:11:49,645 --> 00:11:53,510
Después de guardar los favoritos,

137
00:11:53,510 --> 00:11:54,980
entonces lo buscaremos,

138
00:11:54,980 --> 00:11:58,285
para el FavoriteByID y luego devolveremos

139
00:11:58,285 --> 00:12:03,940
ese favorito aquí, así que diremos luego código de retorno y estado favorito.

140
00:12:03,940 --> 00:12:05,355
Este cambio debemos hacer.

141
00:12:05,355 --> 00:12:08,180
Si ya ha implementado esto en sus favoritos,

142
00:12:08,180 --> 00:12:09,760
entonces no necesita realizar este cambio.

143
00:12:09,760 --> 00:12:13,310
Pero lo que estamos haciendo es que cada vez que hacemos cambios en los favoritos,

144
00:12:13,310 --> 00:12:17,380
rellenaremos tanto la información del usuario como de los platos y luego devolveremos este valor

145
00:12:17,380 --> 00:12:22,360
porque nuestro cliente React espera que esto esté allí.

146
00:12:22,360 --> 00:12:24,685
Ahora, el mismo tipo de cambio,

147
00:12:24,685 --> 00:12:28,350
tendremos que hacer la variable b, guardar los cambios.

148
00:12:28,350 --> 00:12:33,125
Así que en la publicación aquí,

149
00:12:33,125 --> 00:12:36,090
haremos un cambio a eso,

150
00:12:36,090 --> 00:12:42,705
así que diremos favorites.save y luego haremos Favorites.findById y haremos ese cambio.

151
00:12:42,705 --> 00:12:45,210
Del mismo modo, debajo de la identificación del plato

152
00:12:45,210 --> 00:12:47,095
, también en el post,

153
00:12:47,095 --> 00:12:51,070
será de manera similar, cada vez que haga cambios en los favoritos,

154
00:12:51,070 --> 00:12:57,715
primero buscará y luego rellenará tanto el usuario como los platos y luego devolverlo,

155
00:12:57,715 --> 00:12:59,910
y luego de manera similar en la otra parte.

156
00:12:59,910 --> 00:13:06,290
Por lo tanto, debe haber implementado esto en su cuarta asignación.

157
00:13:06,290 --> 00:13:09,010
Por lo tanto, haga este cambio adicional donde rellenará

158
00:13:09,010 --> 00:13:12,350
el usuario y los platos antes de devolver el valor.

159
00:13:12,350 --> 00:13:14,685
También con la eliminación,

160
00:13:14,685 --> 00:13:17,385
haremos los mismos cambios aquí.

161
00:13:17,385 --> 00:13:19,890
Por lo tanto, nota que en la eliminación,

162
00:13:19,890 --> 00:13:21,830
ya he hecho este cambio aquí.

163
00:13:21,830 --> 00:13:27,085
Por lo tanto, después de guardar los cambios en los favoritos,

164
00:13:27,085 --> 00:13:29,480
buscaremos los favoritos y luego

165
00:13:29,480 --> 00:13:33,465
regresaremos después de rellenar tanto el usuario como los platos y los favoritos.

166
00:13:33,465 --> 00:13:36,505
Esto es lo que nuestro cliente React espera que hagamos.

167
00:13:36,505 --> 00:13:38,145
Por lo tanto, incluso para la eliminación,

168
00:13:38,145 --> 00:13:39,995
haremos los mismos cambios.

169
00:13:39,995 --> 00:13:44,115
Ahora, con esto, mi enrutador favorito se actualiza,

170
00:13:44,115 --> 00:13:48,575
así que procederemos a actualizar users.js a continuación.

171
00:13:48,575 --> 00:13:52,370
Finalmente, actualizaremos el archivo users.js.

172
00:13:52,370 --> 00:13:57,060
Ahora, en el archivo users.js necesitamos agregar

173
00:13:57,060 --> 00:14:05,245
otro campo router.options aquí,

174
00:14:05,245 --> 00:14:10,610
porque a veces una solicitud de publicación como vio

175
00:14:10,610 --> 00:14:16,315
con el inicio de sesión enviará las opciones primero para verificar,

176
00:14:16,315 --> 00:14:21,610
especialmente con los coches, si se permitirá la solicitud de publicación.

177
00:14:21,610 --> 00:14:30,080
Así que es por eso que revisaremos el curso con opciones aquí y luego

178
00:14:31,860 --> 00:14:35,450
simplemente devolveremos

179
00:14:39,960 --> 00:14:43,045
un mensaje

180
00:14:43,045 --> 00:14:46,180
de estado de 200 en respuesta a eso.

181
00:14:46,180 --> 00:14:52,960
Para cualquier endpoint bajo los usuarios si recibimos las opciones,

182
00:14:52,960 --> 00:14:56,530
simplemente devolveremos un estado 200 aquí.

183
00:14:56,530 --> 00:15:03,580
Ahora la función de inicio de sesión que

184
00:15:03,580 --> 00:15:07,470
habíamos implementado anteriormente, simplemente habíamos hecho passport.authenticate

185
00:15:07,470 --> 00:15:12,930
local aquí y el comprobamos los valores restantes aquí.

186
00:15:12,930 --> 00:15:15,215
Ahora, este passport.authenticate local,

187
00:15:15,215 --> 00:15:17,600
si el usuario no se autentica,

188
00:15:17,600 --> 00:15:21,800
simplemente devuelve un mensaje no autorizado en el mensaje de respuesta.

189
00:15:21,800 --> 00:15:28,380
Ahora eso puede no ser muy significativo para el lado del cliente para mostrar esta información,

190
00:15:28,380 --> 00:15:30,480
por lo que vamos a mejorar

191
00:15:30,480 --> 00:15:36,310
este método de inicio de sesión después del enrutador para

192
00:15:36,310 --> 00:15:41,765
que la autenticación devuelva información más significativa en este punto.

193
00:15:41,765 --> 00:15:43,210
Así que para hacer eso,

194
00:15:43,210 --> 00:15:49,395
no vamos a hacer el passport.authenticate aquí, en

195
00:15:49,395 --> 00:15:51,955
lugar de eso vamos a tomar.

196
00:15:51,955 --> 00:15:55,140
Entonces, déjame eliminar eso desde allí y luego verás

197
00:15:55,140 --> 00:15:58,930
cómo actualizaré la publicación del enrutador aquí.

198
00:15:58,930 --> 00:16:08,620
Por lo tanto, vamos a ver curso con opciones y luego vamos a incluir el req,

199
00:16:08,620 --> 00:16:12,160
res y siguiente aquí.

200
00:16:12,160 --> 00:16:16,885
Dentro de este req, res y el siguiente aquí,

201
00:16:16,885 --> 00:16:27,954
passport.authenticate llamará a esto con local.

202
00:16:27,954 --> 00:16:31,210
Ahora, cuando llamamos a esto con local,

203
00:16:31,210 --> 00:16:34,970
si se produce un error de autenticación, se

204
00:16:34,970 --> 00:16:38,240
puede hacer que el passport.authenticate devuelva

205
00:16:38,240 --> 00:16:44,230
el valor del error y también devolverá al usuario si

206
00:16:44,230 --> 00:16:48,960
no hay error y un tercer parámetro llamado info

207
00:16:48,960 --> 00:16:54,000
que llevará información adicional que podría ser analizada de nuevo a el usuario.

208
00:16:54,000 --> 00:16:56,580
Este error se devolverá cuando se

209
00:16:56,580 --> 00:16:59,950
produzca un error genuino en passport.authenticate.

210
00:16:59,950 --> 00:17:03,400
Pero si la información del usuario

211
00:17:03,400 --> 00:17:07,645
se envía a passport.authenticate pero el usuario no existe,

212
00:17:07,645 --> 00:17:10,490
entonces eso no se cuenta como un error.

213
00:17:10,490 --> 00:17:14,690
En su lugar, se contará ya que el usuario no existe y

214
00:17:14,690 --> 00:17:19,305
esa información se analiza de nuevo en el objeto info que entra.

215
00:17:19,305 --> 00:17:21,500
Por lo tanto, el error se devolverá cuando haya

216
00:17:21,500 --> 00:17:24,925
un error genuino que ocurre durante el proceso de autenticación,

217
00:17:24,925 --> 00:17:30,820
pero la información contendrá información si el usuario no existe.

218
00:17:30,820 --> 00:17:36,920
Por lo tanto, passport.authenticate está devolviendo un mensaje diciendo que

219
00:17:36,920 --> 00:17:39,575
el usuario no existe o que el nombre de usuario

220
00:17:39,575 --> 00:17:42,850
es incorrecto o la contraseña es incorrecta, etc.

221
00:17:42,850 --> 00:17:46,870
Por lo tanto, esa información será transmitida en el mensaje de información.

222
00:17:46,870 --> 00:17:49,230
Ahora veremos cómo esto es útil para

223
00:17:49,230 --> 00:17:52,060
nosotros cuando miramos el lado del cliente un poco más tarde.

224
00:17:52,060 --> 00:17:55,400
Entonces, en esta situación,

225
00:17:55,400 --> 00:18:01,455
manejaremos esto de la siguiente manera,

226
00:18:01,455 --> 00:18:06,810
y no solo eso cuando llamamos a este passport.authenticate,

227
00:18:06,810 --> 00:18:10,220
también necesitamos pasar un req,

228
00:18:10,220 --> 00:18:15,080
res, al lado de los tres parámetros a él.

229
00:18:15,080 --> 00:18:20,130
Por lo tanto, esta es la estructura cuando necesita llamar a passport.authenticate y esperar que

230
00:18:20,130 --> 00:18:25,270
le transmita información como esta como un método de devolución de llamada aquí,

231
00:18:25,270 --> 00:18:27,630
por lo que también necesita proporcionar este req, res, el

232
00:18:27,630 --> 00:18:30,250
siguiente justo allí también.

233
00:18:30,250 --> 00:18:32,270
Ahora, si esto ocurre,

234
00:18:32,270 --> 00:18:36,780
entonces diremos si err,

235
00:18:36,780 --> 00:18:40,425
así que si ocurre un error,

236
00:18:40,425 --> 00:18:45,395
diremos que devuelve el siguiente error y luego dejemos que

237
00:18:45,395 --> 00:18:51,480
el manejador de errores de nuestro router express y se encargue de eso.

238
00:18:51,480 --> 00:18:56,755
Ahora, consideraremos otras situaciones, si no el usuario.

239
00:18:56,755 --> 00:18:59,630
Por lo tanto, si hemos llegado a este punto,

240
00:18:59,630 --> 00:19:02,580
entonces eso significa que no fue un error que ocurrió

241
00:19:02,580 --> 00:19:05,615
, sino que quizás el usuario no pudo ser encontrado.

242
00:19:05,615 --> 00:19:07,100
Si no se encuentra el usuario,

243
00:19:07,100 --> 00:19:11,190
entonces el usuario aquí se establecerá como nulo en este caso.

244
00:19:11,190 --> 00:19:14,634
Por lo tanto, en esa situación,

245
00:19:14,634 --> 00:19:17,375
si el usuario no existe,

246
00:19:17,375 --> 00:19:23,680
entonces necesitamos poder pasar información de vuelta al lado del servidor.

247
00:19:23,680 --> 00:19:28,435
Entonces, lo que haremos es pasar esta información en este formato.

248
00:19:28,435 --> 00:19:32,020
Así que, voy a cortar esto desde aquí y

249
00:19:32,020 --> 00:19:36,640
luego pegarlo aquí y luego editaremos esto.

250
00:19:36,640 --> 00:19:40,704
Por lo tanto, si el usuario es nulo,

251
00:19:40,704 --> 00:19:45,830
entonces enviaremos un código de estado como 401 lo que significa

252
00:19:45,830 --> 00:19:53,975
no autorizado y luego devolveremos la información de éxito falso,

253
00:19:53,975 --> 00:19:57,405
y luego no vamos a pasar de nuevo el token,

254
00:19:57,405 --> 00:20:00,795
vamos a pasar de nuevo el mensaje de estado.

255
00:20:00,795 --> 00:20:03,135
Por lo tanto, aquí vamos a decir

256
00:20:03,135 --> 00:20:12,670
'Iniciar sesión sin éxito' y luego la tercera información,

257
00:20:12,670 --> 00:20:18,070
vamos a pasar esta información ese objeto que hemos recibido aquí como

258
00:20:18,070 --> 00:20:25,635
la tercera parte en el mensaje de respuesta que enviamos de vuelta desde nuestro servidor aquí.

259
00:20:25,635 --> 00:20:28,935
Por lo tanto, el indicador de éxito se establecerá en falso,

260
00:20:28,935 --> 00:20:32,385
el estado se establecerá Iniciar sesión sin éxito y

261
00:20:32,385 --> 00:20:36,725
la información de error que se pasa en la información se volverá a transferir.

262
00:20:36,725 --> 00:20:39,855
Ahora, tenga en cuenta que esta situación ocurrirá si

263
00:20:39,855 --> 00:20:43,125
el nombre de usuario y la contraseña son incorrectos,

264
00:20:43,125 --> 00:20:48,600
por lo que esto no es un error en el sentido del error, pero

265
00:20:48,600 --> 00:20:54,040
el hecho de que el autenticado no pudo encontrar el usuario o la contraseña del usuario es incorrecto.

266
00:20:54,040 --> 00:20:58,530
Por lo tanto, esa información se codificará en la información que entra y así voy a

267
00:20:58,530 --> 00:21:04,590
pasar de nuevo como un error al lado de mi cliente.

268
00:21:04,590 --> 00:21:09,615
La parte de lo contrario

269
00:21:09,615 --> 00:21:15,355
se maneja como req.login.

270
00:21:15,355 --> 00:21:17,220
Por lo tanto, si esto es exitoso,

271
00:21:17,220 --> 00:21:22,710
el passport.authenticate vamos a añadir este método llamado req.login al usuario.

272
00:21:22,710 --> 00:21:24,340
Por lo tanto, en este punto,

273
00:21:24,340 --> 00:21:27,950
simplemente pasaremos el objeto de usuario que hemos obtenido.

274
00:21:27,950 --> 00:21:31,055
Así que aquí, si hemos llegado a este punto,

275
00:21:31,055 --> 00:21:36,195
entonces eso significa que el objeto de usuario no es nulo y tampoco se produjo ningún error,

276
00:21:36,195 --> 00:21:40,090
por lo que significa que el usuario puede iniciar sesión.

277
00:21:41,080 --> 00:21:44,550
Entonces, diremos err,

278
00:21:48,960 --> 00:21:51,460
intentaremos iniciar sesión con el usuario.

279
00:21:51,460 --> 00:21:58,000
Por lo tanto, diremos si err y

280
00:21:58,000 --> 00:22:05,345
luego pasaremos el mismo tipo de información de error que hicimos aquí.

281
00:22:05,345 --> 00:22:09,840
Así que en este caso, si hay error,

282
00:22:13,290 --> 00:22:19,430
entonces pasaremos un código de estado como 401 y diremos que el éxito

283
00:22:19,430 --> 00:22:25,125
es falso y el estado como Inicio de sesión no exitoso,

284
00:22:25,125 --> 00:22:28,340
y luego la información del error,

285
00:22:29,280 --> 00:22:31,840
en lugar de la información,

286
00:22:31,840 --> 00:22:42,380
pasaremos en 'No se pudo iniciar sesión en el usuario».

287
00:22:42,380 --> 00:22:48,960
Por lo tanto, ese es el mensaje que pasaremos aquí si se produce el error.

288
00:22:48,960 --> 00:22:53,200
De lo contrario, estaríamos abajo aquí abajo.

289
00:22:53,200 --> 00:22:55,960
Entonces, en este punto,

290
00:22:55,960 --> 00:22:59,440
seríamos capaces de generar el token.

291
00:22:59,440 --> 00:23:02,495
Por lo tanto, si hemos llegado hasta este punto,

292
00:23:02,495 --> 00:23:06,370
eso significa que el usuario ha iniciado sesión con éxito,

293
00:23:06,370 --> 00:23:08,430
por lo que ahora podemos generar el token.

294
00:23:08,430 --> 00:23:12,705
Por lo tanto, generaremos el token basado en el ID del usuario,

295
00:23:12,705 --> 00:23:18,350
y luego devolveremos el token al usuario.

296
00:23:18,350 --> 00:23:21,635
Entonces, aquí, diremos token var,

297
00:23:21,635 --> 00:23:30,730
y luego podemos decir Res.statusCode es 200 y luego res.json verdadero éxito,

298
00:23:30,730 --> 00:23:33,600
por lo que, lo que significa que el usuario inició sesión con éxito.

299
00:23:33,600 --> 00:23:38,490
Por lo tanto, el estado sería el inicio de sesión exitoso.

300
00:23:38,490 --> 00:23:40,605
Luego, la tercera parte,

301
00:23:40,605 --> 00:23:42,360
en lugar del error,

302
00:23:42,360 --> 00:23:46,200
volveré a pasar el token al usuario.

303
00:23:46,200 --> 00:23:48,760
Entonces, diremos token,

304
00:23:51,100 --> 00:23:54,675
este token que acabamos de obtener antes.

305
00:23:54,675 --> 00:24:01,030
Por lo tanto, ese token se pasará como la propiedad token del mensaje de respuesta.

306
00:24:01,030 --> 00:24:04,560
Por lo tanto, aquí, observe que el éxito se establece en verdadero, por lo

307
00:24:04,560 --> 00:24:08,340
que, lo que significa que el usuario inició sesión con éxito,

308
00:24:08,340 --> 00:24:12,290
y por lo tanto, el usuario puede continuar más allá en este punto.

309
00:24:12,290 --> 00:24:19,050
Esto tiene que hacerse dentro del req.login aquí.

310
00:24:19,820 --> 00:24:22,970
Por lo tanto, en este punto,

311
00:24:22,970 --> 00:24:27,180
cerraremos el req.login.

312
00:24:27,180 --> 00:24:33,735
Por lo tanto, observe que esto está dentro de este req.login aquí.

313
00:24:33,735 --> 00:24:37,320
Así que, ahí dentro, pasaremos estos tres de vuelta.

314
00:24:37,320 --> 00:24:41,370
Así que, déjame sangrar estas tres líneas.

315
00:24:41,720 --> 00:24:48,850
Entonces, así es como manejaríamos el método de registro del usuario.

316
00:24:48,850 --> 00:24:52,230
Entonces, de nuevo, revisando este código una vez más.

317
00:24:52,230 --> 00:24:53,950
Por lo tanto, haremos la publicación del enrutador,

318
00:24:53,950 --> 00:24:56,815
pero en lugar de hacer la autenticación del pasaporte justo allí

319
00:24:56,815 --> 00:24:58,960
, diremos req, res

320
00:24:58,960 --> 00:25:01,240
, siguiente, y luego dentro de aquí,

321
00:25:01,240 --> 00:25:04,285
haremos una autenticación de pasaporte para el local,

322
00:25:04,285 --> 00:25:06,560
y esta autenticación pasará de nuevo.

323
00:25:06,560 --> 00:25:09,250
Por lo tanto, podemos proporcionar una función de devolución de llamada a eso,

324
00:25:09,250 --> 00:25:11,810
y esta función de devolución de llamada devolverá

325
00:25:11,810 --> 00:25:14,730
el error, el usuario o la información aquí.

326
00:25:14,730 --> 00:25:16,300
Por lo tanto, si se trata de un error,

327
00:25:16,300 --> 00:25:20,735
permitiremos que el manejador de errores expresos se encargue de eso.

328
00:25:20,735 --> 00:25:22,730
Si el usuario es nulo,

329
00:25:22,730 --> 00:25:26,940
entonces eso significa que el inicio de sesión del usuario no tuvo éxito,

330
00:25:26,940 --> 00:25:29,730
y el motivo de eso estará en la información.

331
00:25:29,730 --> 00:25:36,870
Por lo tanto, eso pasará como el error de información en el mensaje de respuesta aquí.

332
00:25:36,870 --> 00:25:38,790
Si llegamos a este punto,

333
00:25:38,790 --> 00:25:43,555
entonces el usuario se verifica con éxito.

334
00:25:43,555 --> 00:25:45,400
Entonces, iniciaremos sesión al usuario.

335
00:25:45,400 --> 00:25:47,630
Por lo tanto, el pasaporte se autentica,

336
00:25:47,630 --> 00:25:53,385
vamos a agregar en este método llamado inicio de sesión a la req, el mensaje de solicitud.

337
00:25:53,385 --> 00:25:56,770
Por lo tanto, podemos llamar al inicio de sesión con el usuario.

338
00:25:56,770 --> 00:25:59,355
Si esto devuelve un error,

339
00:25:59,355 --> 00:26:03,105
entonces devolveremos el error aquí apropiadamente.

340
00:26:03,105 --> 00:26:08,590
Si no, habremos llegado al punto en el que el usuario se autentica con éxito.

341
00:26:08,590 --> 00:26:12,630
Por lo tanto, podemos generar el token web JSON aquí y luego devolver

342
00:26:12,630 --> 00:26:18,315
el token web JSON al usuario para confirmar que el usuario ha iniciado sesión correctamente.

343
00:26:18,315 --> 00:26:21,545
Por lo tanto, ese es el conjunto de pasos que vamos a usar aquí.

344
00:26:21,545 --> 00:26:25,735
Ahora, la razón por la que hago una forma más elaborada de manejarlo es que

345
00:26:25,735 --> 00:26:30,035
quiero distinguir entre la situación en la que

346
00:26:30,035 --> 00:26:34,170
ocurre un error genuino durante el proceso de autenticación en lugar de la situación en la que

347
00:26:34,170 --> 00:26:39,095
el nombre de usuario no es válido o la contraseña no es válida.

348
00:26:39,095 --> 00:26:42,860
Por lo tanto, esos dos casos serán manejados por esta situación,

349
00:26:42,860 --> 00:26:46,550
donde la información nos llevará la información de vuelta.

350
00:26:46,550 --> 00:26:48,900
Por lo tanto, eso no es un error per se,

351
00:26:48,900 --> 00:26:52,090
pero esa es una situación en la que el usuario

352
00:26:52,090 --> 00:26:55,710
no es un usuario válido o la contraseña del usuario no es válida.

353
00:26:55,710 --> 00:27:01,070
Entonces, así es como manejaremos el proceso de inicio de sesión del usuario.

354
00:27:01,070 --> 00:27:03,660
Además, agregaré un

355
00:27:03,660 --> 00:27:14,825
método más aquí llamado CheckJWTToken.

356
00:27:14,825 --> 00:27:21,100
Es muy posible que mientras el cliente haya iniciado sesión y obtenga el token web JSON, en

357
00:27:21,100 --> 00:27:24,855
algún momento más tarde, el token web JSON puede caducar.

358
00:27:24,855 --> 00:27:32,840
Por lo tanto, si el usuario intenta acceder desde el lado del cliente con un token caducado al

359
00:27:32,840 --> 00:27:35,610
servidor, entonces el servidor no podrá autenticar al usuario.

360
00:27:35,610 --> 00:27:37,780
Por lo tanto, a intervalos periódicos, es

361
00:27:37,780 --> 00:27:42,180
posible que desee verificar cruzada para asegurarnos de que el token web JSON sigue siendo válido.

362
00:27:42,180 --> 00:27:44,975
Entonces, esa es la razón por la que estoy incluyendo esto,

363
00:27:44,975 --> 00:27:49,620
otro punto final llamado CheckJWTToken.

364
00:27:49,620 --> 00:27:53,155
Por lo tanto, si hace un llegar al CheckJWTToken

365
00:27:53,155 --> 00:27:58,700
incluyendo el token en el encabezado de autorización,

366
00:27:58,700 --> 00:28:02,490
entonces esta llamada devolverá un verdadero o falso

367
00:28:02,490 --> 00:28:06,535
para indicarle si el token web JSON sigue siendo válido o no.

368
00:28:06,535 --> 00:28:10,930
Si no es válido, el lado del cliente puede iniciar otro inicio de sesión para

369
00:28:10,930 --> 00:28:15,945
que el usuario obtenga un nuevo token web JSON si es necesario.

370
00:28:15,945 --> 00:28:17,285
Entonces, para hacer esto,

371
00:28:17,285 --> 00:28:27,109
diremos cors.corsWithOptions y req,

372
00:28:27,109 --> 00:28:31,385
res aquí como se esperaba.

373
00:28:31,385 --> 00:28:35,670
Aquí, diremos que el

374
00:28:39,820 --> 00:28:49,360
pasaporte autentica jwt

375
00:28:49,360 --> 00:28:57,150
y session: false,

376
00:29:00,020 --> 00:29:07,270
y esto devolvería err, usuario, info.

377
00:29:09,020 --> 00:29:13,770
Por lo tanto, recuerde cómo usamos el pasaporte autenticar antes.

378
00:29:13,770 --> 00:29:17,195
Entonces, llamamos al JWT con sesión falsa aquí.

379
00:29:17,195 --> 00:29:21,745
Así que, antes aquí, decimos que el pasaporte autentica local.

380
00:29:21,745 --> 00:29:23,535
Por lo tanto, esto es para la autenticación local.

381
00:29:23,535 --> 00:29:27,330
Por lo tanto, esto es para la autenticación JSON Web Token.

382
00:29:27,330 --> 00:29:29,430
Entonces, cuando llamemos a eso,

383
00:29:29,430 --> 00:29:33,435
ya que eso va a verificar el token web JSON, entonces diremos,

384
00:29:33,435 --> 00:29:40,335
si err devuelve el siguiente error,

385
00:29:40,335 --> 00:29:44,895
y luego dejemos que el manejador de errores expresos se ocupe de esa situación.

386
00:29:44,895 --> 00:29:50,469
Luego, diremos, si no es usuario,

387
00:29:53,330 --> 00:30:00,330
si el usuario no existe, entonces de manera similar.

388
00:30:00,330 --> 00:30:03,510
Entonces, lo que significa que si el objeto de usuario se

389
00:30:03,510 --> 00:30:07,810
encontró desde el token web JSON y luego se cargó en el req.user,

390
00:30:07,810 --> 00:30:11,400
entonces eso significa que el usuario es un usuario válido,

391
00:30:11,400 --> 00:30:13,485
por lo que se puede permitir continuar más adelante.

392
00:30:13,485 --> 00:30:20,330
De lo contrario, vamos a decir que el usuario no existe.

393
00:30:20,330 --> 00:30:24,995
Por lo tanto, tenemos que informar que el JSON Web Token ha caducado.

394
00:30:24,995 --> 00:30:26,180
Entonces, en este punto,

395
00:30:26,180 --> 00:30:29,090
enviaremos una resolución con

396
00:30:29,090 --> 00:30:36,545
un código de estado de 401.

397
00:30:36,545 --> 00:30:47,130
Entonces, no autorizado, setHeader, Content-Type,

398
00:30:49,900 --> 00:30:56,280
application/json, y luego devolveremos res.

399
00:30:58,680 --> 00:31:13,750
Res.json dirá que el estado JWT

400
00:31:13,750 --> 00:31:17,090
no es válido y luego,

401
00:31:17,730 --> 00:31:23,690
devolveremos un indicador llamado éxito cae y luego,

402
00:31:23,880 --> 00:31:29,080
devolveremos la información que obtenemos si el usuario

403
00:31:29,080 --> 00:31:34,460
no está autenticado como el error en este punto.

404
00:31:36,420 --> 00:31:40,480
De lo contrario, eso significa que llegamos a este punto,

405
00:31:40,480 --> 00:31:43,220
entonces el usuario es un usuario válido.

406
00:31:43,220 --> 00:31:44,850
Entonces, en este caso,

407
00:31:44,850 --> 00:31:47,230
déjame copiar ese código aquí,

408
00:31:47,230 --> 00:31:54,070
estaremos enviando un código de estado de 200 y luego el res.json,

409
00:31:54,070 --> 00:32:02,720
enviará JWT válido y exitoso siendo verdadero.

410
00:32:02,940 --> 00:32:09,820
En la tercera parte, enviaremos la información del usuario.

411
00:32:09,820 --> 00:32:16,000
De esa manera, cuando se llama a este extremo con el método get

412
00:32:16,000 --> 00:32:19,170
, esto verificará si el token es válido o no.

413
00:32:19,170 --> 00:32:20,220
Si el token es válido,

414
00:32:20,220 --> 00:32:24,020
entonces recibirá esta respuesta y desde el indicador de éxito en la respuesta,

415
00:32:24,020 --> 00:32:27,770
puede verificar si el jsonwebtoken es válido o no.

416
00:32:27,770 --> 00:32:32,155
Esto es útil en el lado del cliente.

417
00:32:32,155 --> 00:32:37,825
Ahora, este pasaporte autenticar aquí tendrá que ser suministrado

418
00:32:37,825 --> 00:32:43,790
con req y res como los dos parámetros aquí.

419
00:32:43,790 --> 00:32:47,630
Entonces, así es como llamamos autenticar el pasaporte.

420
00:32:47,630 --> 00:32:49,355
Por lo tanto, observe que cada vez que llame a la

421
00:32:49,355 --> 00:32:52,840
autenticación de pasaporte y espere esta función de devolución de llamada aquí,

422
00:32:52,840 --> 00:33:01,825
debe anexar a este punto req.res a la autenticación de pasaporte en la parte posterior aquí.

423
00:33:01,825 --> 00:33:03,890
En nuestro servidor API de descanso,

424
00:33:03,890 --> 00:33:07,490
habíamos implementado nuestros comentarios de tal manera que los comentarios

425
00:33:07,490 --> 00:33:12,245
formaban sub-documentos dentro del documento del dishe,

426
00:33:12,245 --> 00:33:16,540
por lo que compran cada plato adjunto su propio conjunto de comentarios.

427
00:33:16,540 --> 00:33:19,520
Pero la forma en que implementamos nuestro cliente React es

428
00:33:19,520 --> 00:33:22,965
tal que los comentarios se mantienen independientes de los platos,

429
00:33:22,965 --> 00:33:27,680
y los comentarios mismos llevan el ID de plato correspondiente.

430
00:33:27,680 --> 00:33:30,400
Ahora, estas son dos formas diferentes de

431
00:33:30,400 --> 00:33:34,445
implementar tanto el lado del servidor como el lado del cliente.

432
00:33:34,445 --> 00:33:39,685
En la aplicación Angular que estamos implementados en nuestra especialización Angular,

433
00:33:39,685 --> 00:33:43,470
habíamos utilizado el método de subdocumento para

434
00:33:43,470 --> 00:33:47,560
manejar comentarios en nuestra aplicación cliente Angular.

435
00:33:47,560 --> 00:33:50,050
Por lo tanto, el resto del servidor API

436
00:33:50,050 --> 00:33:54,090
se implementó de tal manera que era más adecuado para el cliente angular.

437
00:33:54,090 --> 00:34:00,600
Pero para los clientes React, ya que mantuvimos los comentarios independientes de los platos,

438
00:34:00,600 --> 00:34:03,985
y luego usamos el ID del plato dentro del comentario,

439
00:34:03,985 --> 00:34:09,300
por lo que necesitamos reestructurar nuestro servidor API de descanso,

440
00:34:09,300 --> 00:34:16,835
por lo que tenemos un punto final de comentario independiente del punto final de los platos.

441
00:34:16,835 --> 00:34:22,310
Por lo tanto, necesitamos reestructurar nuestro código en el servidor

442
00:34:22,310 --> 00:34:29,140
para introducir el punto final de la API REST /comments en esta etapa.

443
00:34:29,140 --> 00:34:30,600
Entonces, para hacer eso,

444
00:34:30,600 --> 00:34:37,540
sigamos adelante e implementemos un nuevo modelo llamado como comment.js.

445
00:34:37,540 --> 00:34:39,260
Entonces, al entrar en los modelos,

446
00:34:39,260 --> 00:34:45,790
permítanme implementar un nuevo archivo llamado comments.js.

447
00:34:47,220 --> 00:34:50,015
En el archivo comments.js,

448
00:34:50,015 --> 00:34:56,110
vamos a mover el CommentSchema del

449
00:34:56,110 --> 00:35:02,660
archivo dishes.js al archivo comments.js y luego eliminarlo completamente del archivo dishes.js.

450
00:35:02,660 --> 00:35:03,900
Pero antes de hacer eso,

451
00:35:03,900 --> 00:35:08,770
necesitamos copiar la mangosta y el esquema desde aquí,

452
00:35:08,770 --> 00:35:13,860
así que permítanme copiar esto de dishes.js en comment.js.

453
00:35:13,860 --> 00:35:16,590
Después de eso, al entrar en dishes.js,

454
00:35:16,590 --> 00:35:21,040
permítanme cortar este CommentSchema completamente desde aquí,

455
00:35:21,040 --> 00:35:28,300
porque tendremos esto por separado en el modelo de comentarios aquí.

456
00:35:28,300 --> 00:35:33,070
Entonces, vamos a mover eso al modelo de comentarios y luego pegarlo aquí.

457
00:35:33,070 --> 00:35:35,050
Pero, por supuesto, este no es el completo,

458
00:35:35,050 --> 00:35:37,870
vamos a actualizar un poco el CommentSchema.

459
00:35:37,870 --> 00:35:39,300
Pero antes de hacerlo,

460
00:35:39,300 --> 00:35:43,455
vuelva al archivo dishes.js y en el archivo de platos,

461
00:35:43,455 --> 00:35:47,925
eliminaremos los comentarios del dishessChema,

462
00:35:47,925 --> 00:35:51,510
porque vamos a almacenar el contenido por separado de

463
00:35:51,510 --> 00:35:55,550
los platos en esta versión de nuestro servidor.

464
00:35:55,550 --> 00:36:00,450
Entonces, así es como actualizaremos el modelo de platos aquí.

465
00:36:00,450 --> 00:36:08,180
Por lo tanto, hemos eliminado los comentarios completamente del modelo de platos aquí.

466
00:36:08,180 --> 00:36:10,270
Al entrar en el modelo de comentarios,

467
00:36:10,270 --> 00:36:15,355
por lo que ahora vemos que tenemos el CommentSchema implementado aquí.

468
00:36:15,355 --> 00:36:19,525
Pero además, en el CommentsSchema,

469
00:36:19,525 --> 00:36:23,330
ahora necesitamos señalar explícitamente

470
00:36:23,330 --> 00:36:28,885
el plato específico para el que este comentario es el comentario correspondiente.

471
00:36:28,885 --> 00:36:30,700
Ahora, aquí es donde

472
00:36:30,700 --> 00:36:37,435
nuestra población de mangostas y

473
00:36:37,435 --> 00:36:41,580
la forma en que almacenamos los identificadores de objetos viene a nuestro rescate.

474
00:36:41,580 --> 00:36:45,860
Por lo tanto, vamos a actualizar el CommentSchema diciendo que tendremos la calificación,

475
00:36:45,860 --> 00:36:47,800
el comentario y el autor aquí.

476
00:36:47,800 --> 00:36:49,110
Además del autor,

477
00:36:49,110 --> 00:36:56,080
vamos a introducir un campo más llamado como el plato aquí que es

478
00:36:56,080 --> 00:37:05,540
del tipo: mongoose.schema tipes.objectID,

479
00:37:06,390 --> 00:37:19,870
y por lo que esto se referirá al plato aquí.

480
00:37:19,870 --> 00:37:29,060
Por lo tanto, esto sería una referencia de objeto al modelo de plato aquí,

481
00:37:29,060 --> 00:37:32,255
y así con esta modificación ahora

482
00:37:32,255 --> 00:37:36,640
nuestros comentarios contendrán el campo de calificación, el campo de comentario,

483
00:37:36,640 --> 00:37:42,355
el autor que es de nuevo una referencia al usuario correspondiente,

484
00:37:42,355 --> 00:37:47,660
y luego el campo de plato que es una referencia al correspondiente plato aquí.

485
00:37:47,660 --> 00:37:50,060
Entonces, lo que significa que ahora necesitaremos

486
00:37:50,060 --> 00:37:53,640
rellenar los comentarios tanto con el autor como con el campo de plato.

487
00:37:53,640 --> 00:37:55,565
Una vez que hayamos completado esto,

488
00:37:55,565 --> 00:38:01,585
entonces diremos var Comentarios

489
00:38:01,585 --> 00:38:09,910
mongoose.model y llamaremos a este 'Comentario',

490
00:38:09,910 --> 00:38:16,765
y luego esto usa el CommentSchema que acabamos de definir aquí,

491
00:38:16,765 --> 00:38:21,970
y luego necesitamos exportar esto desde aquí,

492
00:38:21,970 --> 00:38:25,280
el comments.model desde aquí.

493
00:38:25,280 --> 00:38:28,395
Por lo tanto, ahora que hemos introducido el comments.model,

494
00:38:28,395 --> 00:38:35,045
entonces vamos a seguir adelante y luego introducir un nuevo Router llamado CommentRouter.

495
00:38:35,045 --> 00:38:37,060
Entonces, para introducir el enrutador de comentarios,

496
00:38:37,060 --> 00:38:39,630
vayamos a las rutas aquí

497
00:38:39,630 --> 00:38:45,990
y luego creemos un nuevo archivo llamado commentRouter.js.

498
00:38:47,090 --> 00:38:52,415
En commentRouter.js, permítanme copiar algunas cosas

499
00:38:52,415 --> 00:38:59,890
desde el DishRouter.

500
00:38:59,890 --> 00:39:07,720
Por lo tanto, tendremos estos comentarios aquí,

501
00:39:07,720 --> 00:39:14,865
así que permítanme copiar sobre estas cosas desde y también,

502
00:39:14,865 --> 00:39:21,070
mientras estoy en ello déjeme copiar estos también hasta ese punto,

503
00:39:21,070 --> 00:39:24,625
y luego lo actualizaré un poco más tarde.

504
00:39:24,625 --> 00:39:26,680
Entonces, al entrar en el CommentRouter,

505
00:39:26,680 --> 00:39:28,040
necesitamos todas estas partes,

506
00:39:28,040 --> 00:39:33,640
por lo que diremos Com, Express, BodyParser, mangosta

507
00:39:33,640 --> 00:39:37,735
, autenticar, cors, y luego

508
00:39:37,735 --> 00:39:46,490
importaremos comentarios de modelos/comentarios.

509
00:39:49,950 --> 00:40:00,460
Entonces llamaremos a esto como el CommentRouter, que es un Express.Router aquí.

510
00:40:02,060 --> 00:40:11,950
Luego diremos que CommentRouter use BodyParser,

511
00:40:11,950 --> 00:40:17,915
y luego esto ahora se convertiría en ruta CommentRouter.

512
00:40:17,915 --> 00:40:22,030
Ahora, tenemos que ir al DishRouter y luego

513
00:40:22,030 --> 00:40:27,200
eliminar todas las partes que se refieren a los comentarios aquí.

514
00:40:27,200 --> 00:40:34,330
Por lo tanto, déjame recortar esta parte y luego reutilizaremos estos para nuestro CommentRouter.

515
00:40:34,330 --> 00:40:38,200
Por lo tanto, todos estos ya no son necesarios en el DishRouter.

516
00:40:38,200 --> 00:40:42,080
Por lo tanto, voy a eliminar todo esto del DishRouter aquí,

517
00:40:42,080 --> 00:40:43,770
así que permítanme cortarlos,

518
00:40:43,770 --> 00:40:48,715
todo lo relacionado con la ruta de comentarios del DishRouter,

519
00:40:48,715 --> 00:40:50,770
luego iremos al CommentRouter,

520
00:40:50,770 --> 00:40:54,405
y luego dejaremos que siga adelante y pegue eso en su lugar aquí,

521
00:40:54,405 --> 00:40:57,100
luego lo editaremos aquí.

522
00:40:57,100 --> 00:41:02,660
Luego, después de esto, necesitamos exportar el CommentRouter.

523
00:41:05,160 --> 00:41:08,205
Por lo tanto, exportará el CommentRouter para nosotros.

524
00:41:08,205 --> 00:41:12,060
Pero, por supuesto, este código no es completamente preciso.

525
00:41:12,060 --> 00:41:14,995
Por lo tanto, tenemos que seguir adelante y arreglar este código aquí.

526
00:41:14,995 --> 00:41:16,585
Por lo tanto, para este código,

527
00:41:16,585 --> 00:41:20,180
ahora nos damos cuenta de que esta no es la ruta DishRouter,

528
00:41:20,180 --> 00:41:21,785
en lugar de eso debería ser

529
00:41:21,785 --> 00:41:27,700
el endpoint /endpoint porque

530
00:41:27,700 --> 00:41:33,685
vamos a montar esto en el endpoint /comments aquí.

531
00:41:33,685 --> 00:41:35,685
Entonces, diremos CommentRouter,

532
00:41:35,685 --> 00:41:39,859
y luego las opciones CorsWithOptions (req,

533
00:41:39,859 --> 00:41:42,550
res) que permanece como tal allí,

534
00:41:42,550 --> 00:41:48,429
y luego el get cors.cors y luego req.res,

535
00:41:48,429 --> 00:41:52,460
y luego este se convertirá en comentarios.

536
00:41:53,880 --> 00:41:58,430
FindById, req.

537
00:42:00,600 --> 00:42:05,330
Por lo tanto, esto sería comments.find

538
00:42:07,050 --> 00:42:17,080
y req.query aquí.

539
00:42:17,080 --> 00:42:20,920
Por lo tanto, cuando se encuentran los comentarios

540
00:42:20,920 --> 00:42:22,974
, entonces, en este punto,

541
00:42:22,974 --> 00:42:25,940
vamos a llenar el autor,

542
00:42:26,880 --> 00:42:30,430
ya tenemos allí, poblar aquí.

543
00:42:30,430 --> 00:42:33,380
Por lo tanto, solo voy a eliminar este comments.author, y luego,

544
00:42:33,380 --> 00:42:37,410
simplemente rellenaremos el autor aquí.

545
00:42:37,410 --> 00:42:44,425
Entonces, esto nos daría comentarios aquí.

546
00:42:44,425 --> 00:42:49,310
Entonces, diremos, esto se puede simplificar significativamente.

547
00:42:49,310 --> 00:42:53,835
Entonces, el error de captura está allí de todos modos.

548
00:42:53,835 --> 00:43:00,805
Entonces, cuando llegue el comentario, simplemente regresará.

549
00:43:00,805 --> 00:43:03,910
Lo siento, eso debería ser.

550
00:43:03,910 --> 00:43:06,525
Por lo tanto, si para obtener,

551
00:43:06,525 --> 00:43:09,305
cuando obtenemos los comentarios,

552
00:43:09,305 --> 00:43:13,760
comentarios.Find req.query, .populate autor aquí,

553
00:43:13,760 --> 00:43:18,010
y luego, vamos a decir, .then comentarios,

554
00:43:18,010 --> 00:43:21,619
y luego, vamos a decir, res.statusCode 200,

555
00:43:21,619 --> 00:43:27,605
setHeader, y luego, vamos a devolver los comentarios de aquí,

556
00:43:27,605 --> 00:43:30,850
res.json comentarios desde aquí.

557
00:43:30,850 --> 00:43:36,970
Ahora, no estoy llenando los platos aquí porque no necesito explícitamente

558
00:43:36,970 --> 00:43:45,300
los platos de la forma en que uso esta información en mi cliente de reacción.

559
00:43:45,300 --> 00:43:46,840
Solo necesito el ID del plato,

560
00:43:46,840 --> 00:43:49,085
y el ID del plato ya está presente allí,

561
00:43:49,085 --> 00:43:55,310
y eso es lo suficientemente bueno para usar estos datos en mi cliente de reacción.

562
00:43:55,310 --> 00:43:57,685
Así que, voy a dejarlo ahí como tal.

563
00:43:57,685 --> 00:43:59,530
Solo voy a rellenar

564
00:43:59,530 --> 00:44:02,910
la información del autor allí porque necesitamos toda la información del autor

565
00:44:02,910 --> 00:44:08,930
cada vez que representamos un elemento de comentario en nuestro cliente reaccionar.

566
00:44:08,930 --> 00:44:12,655
Por lo tanto, el get se actualizará así aquí.

567
00:44:12,655 --> 00:44:22,015
Para la publicación CorsWithOptions,

568
00:44:22,015 --> 00:44:26,070
diremos, Authenticate.VerifyUser req, res, siguiente.

569
00:44:26,070 --> 00:44:29,540
Obviamente, para que se publique un comentario,

570
00:44:29,540 --> 00:44:38,315
necesita que el autor sea un usuario válido que haya iniciado sesión.

571
00:44:38,315 --> 00:44:42,910
Solo entonces, permitirá que el usuario publique un comentario.

572
00:44:42,910 --> 00:44:49,020
Luego, el comentario en sí viene en el cuerpo del mensaje de solicitud entrante.

573
00:44:49,020 --> 00:44:51,810
Entonces, primero, revisaremos el cuerpo

574
00:44:51,810 --> 00:44:58,865
para asegurarnos de que el comentario esté incluido en el cuerpo aquí.

575
00:44:58,865 --> 00:45:03,730
Entonces, aquí, voy a eliminar todas estas partes, y luego,

576
00:45:03,730 --> 00:45:06,100
simplificarlo aún más, y luego,

577
00:45:06,100 --> 00:45:09,430
vamos a implementar esto correctamente allí.

578
00:45:09,430 --> 00:45:17,755
Entonces, justo en este punto, diremos,

579
00:45:17,755 --> 00:45:27,465
si req.body no

580
00:45:27,465 --> 00:45:35,030
es igual a nulo, por lo que significa que hay un comentario que está encerrado dentro del cuerpo.

581
00:45:37,380 --> 00:45:45,025
Así que, déjame cortar esto y mover esto a la parte if aquí,

582
00:45:45,025 --> 00:45:47,155
y luego, vamos a editar eso aquí.

583
00:45:47,155 --> 00:45:52,245
Entonces, si el cuerpo no existe,

584
00:45:52,245 --> 00:45:56,140
entonces causaremos un error.

585
00:45:56,140 --> 00:46:01,220
Por lo tanto, diremos, errr nuevo Error,

586
00:46:01,500 --> 00:46:08,965
Comentario no encontrado en el cuerpo de la solicitud.

587
00:46:08,965 --> 00:46:12,440
Por lo tanto, vamos a plantear este error aquí.

588
00:46:12,450 --> 00:46:16,425
El estado del error es 404.

589
00:46:16,425 --> 00:46:20,385
Luego, diremos, devuelve el siguiente error.

590
00:46:20,385 --> 00:46:26,560
Por lo tanto, vamos a manejar la parte del error aquí si el cuerpo

591
00:46:26,560 --> 00:46:33,280
no contiene la información de comentario apropiada.

592
00:46:33,280 --> 00:46:35,450
Si contiene, entonces, por supuesto,

593
00:46:35,450 --> 00:46:38,170
lo que haremos a continuación es,

594
00:46:38,170 --> 00:46:48,310
diremos, req.body.author es req.user. _id.

595
00:46:50,420 --> 00:46:55,610
La razón por la que estamos haciendo esto es que recordamos que si

596
00:46:55,610 --> 00:46:59,950
es un usuario registrado y el usuario ha iniciado sesión,

597
00:46:59,950 --> 00:47:03,050
entonces el req.user contendrá la información del usuario.

598
00:47:03,050 --> 00:47:07,260
Por lo tanto, solo necesito el ID del usuario que está conectado actualmente.

599
00:47:07,260 --> 00:47:10,310
Por lo tanto, diremos, req.user. _id y, a continuación,

600
00:47:10,310 --> 00:47:14,645
estableceremos el req.body.author en req.user. _id.

601
00:47:14,645 --> 00:47:20,070
Ahora, el usuario de verificación se asegurará automáticamente de que si aterriza en este punto,

602
00:47:20,070 --> 00:47:25,710
obviamente tendría un usuario que ha iniciado sesión correctamente.

603
00:47:25,710 --> 00:47:28,605
De lo contrario, eso ya habría causado el problema allí.

604
00:47:28,605 --> 00:47:30,260
Por lo tanto, cuando llegue a este punto,

605
00:47:30,260 --> 00:47:37,660
tendría un usuario válido que ya haya iniciado sesión en el sistema allí.

606
00:47:37,660 --> 00:47:43,460
Así que, aquí es donde usted sería capaz de hacerlo ahora. Por

607
00:47:43,460 --> 00:47:46,040
lo tanto, lo que estamos haciendo es que el campo autor,

608
00:47:46,040 --> 00:47:50,625
lo estamos configurando explícitamente en el ID del usuario aquí para que

609
00:47:50,625 --> 00:47:57,490
el req.body contenga las partes restantes del comentario.

610
00:47:57,490 --> 00:48:01,315
Entonces, como te das cuenta, el comentario contiene la calificación,

611
00:48:01,315 --> 00:48:04,540
el comentario en sí, y el autor, y los campos de plato.

612
00:48:04,540 --> 00:48:11,510
Por lo tanto, las partes restantes deberían haber sido rellenadas por el usuario.

613
00:48:11,510 --> 00:48:14,730
La calificación, el comentario

614
00:48:14,730 --> 00:48:17,775
y la información del plato ya deben rellenarse

615
00:48:17,775 --> 00:48:20,840
en el cuerpo del mensaje de solicitud entrante.

616
00:48:20,840 --> 00:48:23,460
La parte del autor se deja sin llenar allí,

617
00:48:23,460 --> 00:48:28,380
que insertaremos explícitamente en este punto en el cuerpo aquí.

618
00:48:28,380 --> 00:48:32,515
Entonces, ahora, el req.body contendrá toda la información del comentario.

619
00:48:32,515 --> 00:48:34,440
Entonces, en este punto,

620
00:48:34,440 --> 00:48:43,400
en lugar de hacer esto, diremos, comentarios.Create.

621
00:48:44,550 --> 00:48:49,940
Usando el req.body, vamos a crear los comentarios aquí.

622
00:48:50,010 --> 00:48:53,304
A continuación, esto devolverá

623
00:48:53,304 --> 00:48:58,735
el comentario correspondiente al comentario que acabamos de insertar aquí.

624
00:48:58,735 --> 00:49:00,755
Ahora, una vez que el comentario ha regresado,

625
00:49:00,755 --> 00:49:07,050
entonces deberíamos hacer Comments.FindById.

626
00:49:07,050 --> 00:49:09,680
Ahora, la razón por la que necesitamos hacer esto es porque necesitamos

627
00:49:09,680 --> 00:49:13,070
rellenar la información del autor aquí.

628
00:49:13,780 --> 00:49:18,144
Entonces, diremos, comentarios de FindById. _id

629
00:49:18,144 --> 00:49:26,155
y, a continuación, rellenaremos la información del autor en el propio comentario.

630
00:49:26,155 --> 00:49:34,610
Entonces, diremos, luego comentar.

631
00:49:36,570 --> 00:49:41,115
Ahora, obviamente, aquí, usted encontrará que el comentario

632
00:49:41,115 --> 00:49:44,880
existirá porque acabamos de insertar ese comentario en su lugar allí.

633
00:49:44,880 --> 00:49:54,470
Entonces, aquí, simplemente devolveremos, Res.statusCode es 200,

634
00:49:54,900 --> 00:50:10,040
Res.setHeader es Content-Type, application/json.

635
00:50:14,610 --> 00:50:18,430
El comentario en sí dirá, res.json, y luego,

636
00:50:18,430 --> 00:50:21,745
devolverá el comentario en este punto.

637
00:50:21,745 --> 00:50:26,255
Por lo tanto, esta es la forma en que manejaremos la inserción de

638
00:50:26,255 --> 00:50:30,805
un nuevo comentario en nuestro lado cliente aquí.

639
00:50:30,805 --> 00:50:33,925
Para poner, como te das cuenta,

640
00:50:33,925 --> 00:50:38,360
no podrás hacer un put en los puntos finales /comments/.

641
00:50:38,360 --> 00:50:47,610
Por lo tanto, diremos, la operación PUT no es compatible con /comments/ punto final.

642
00:50:52,050 --> 00:50:56,180
Ese es el punto. Ese es el mensaje que devolverás.

643
00:50:56,180 --> 00:50:58,570
Por lo tanto, StatusCode es 403,

644
00:50:58,570 --> 00:51:02,610
y luego, la operación PUT no es compatible con /comments/.

645
00:51:02,610 --> 00:51:05,260
Ahora, cuando hagamos una eliminación,

646
00:51:13,230 --> 00:51:22,840
permítanme cortar esto desde aquí, y luego, diremos,

647
00:51:30,440 --> 00:51:32,835
comentarios.Eliminar.

648
00:51:32,835 --> 00:51:37,710
escrito vacío. Por lo tanto, cuando haga una eliminación en el extremo de comentarios barra diagonal,

649
00:51:37,710 --> 00:51:40,990
eliminará todos los comentarios de su sistema.

650
00:51:40,990 --> 00:51:43,680
Por lo tanto, esta es una operación muy peligrosa, y por lo tanto,

651
00:51:43,680 --> 00:51:48,990
no debería estar haciendo esto normalmente.

652
00:51:48,990 --> 00:51:53,860
Por lo tanto, solo permitiremos que el administrador realice tal operación.

653
00:51:53,860 --> 00:51:59,410
Por lo tanto, eliminaremos todos los comentarios de allí.

654
00:51:59,410 --> 00:52:01,940
Entonces, cuando obtenga la respuesta,

655
00:52:01,940 --> 00:52:07,700
diremos Res.statusCode 200.

656
00:52:07,700 --> 00:52:11,080
Así que, déjame copiar estas partes aquí,

657
00:52:12,090 --> 00:52:18,130
y luego venir y pegarlas aquí.

658
00:52:18,130 --> 00:52:21,330
Entonces, diremos, comentarios.remove.

659
00:52:21,330 --> 00:52:30,480
Luego responda Res.statusCode 200 aplicación json y luego res.json (respuesta) aquí.

660
00:52:30,480 --> 00:52:33,100
Entonces, así es como manejamos la eliminación.

661
00:52:33,100 --> 00:52:37,280
Operación de eliminación en el extremo de comentarios de barra diagonal.

662
00:52:37,280 --> 00:52:43,135
Ahora, la siguiente ruta es el enrutador de comentarios.

663
00:52:43,135 --> 00:52:49,490
Por lo tanto, aquí diremos CommentRouter.route y

664
00:52:49,490 --> 00:52:56,820
el punto final aquí sería la barra diagonal CommentID.

665
00:53:01,190 --> 00:53:05,580
Entonces, aquí las opciones permanecerán como tales.

666
00:53:05,580 --> 00:53:09,760
Luego, para obtener en el enrutador actual,

667
00:53:09,760 --> 00:53:20,455
para el get diremos, comments.FindById (req.params.

668
00:53:20,455 --> 00:53:25,040
Esto sería CommentID.

669
00:53:25,380 --> 00:53:31,029
Por lo tanto, una vez que

670
00:53:31,029 --> 00:53:37,525
encontremos el comentario específico, entonces rellenaremos solo el autor desde allí.

671
00:53:37,525 --> 00:53:39,985
Luego, una vez que rellene el autor,

672
00:53:39,985 --> 00:53:45,830
diremos, luego comentaremos.

673
00:53:47,880 --> 00:53:51,310
Ahora, toda esta parte es innecesaria aquí,

674
00:53:51,310 --> 00:53:54,440
así que voy a borrar la parte.

675
00:53:54,480 --> 00:54:00,985
Esto tampoco es lo apropiado aquí.

676
00:54:00,985 --> 00:54:04,540
Entonces, déjame cambiar el nombre del código.

677
00:54:04,540 --> 00:54:08,990
Por lo tanto, diremos para obtener comentarios. FindById,

678
00:54:11,550 --> 00:54:15,385
luego rellene el autor,

679
00:54:15,385 --> 00:54:20,365
luego comente, Res.StatusCode es 200, setHeader.

680
00:54:20,365 --> 00:54:22,435
Entonces el resto son JSON.

681
00:54:22,435 --> 00:54:29,960
Simplemente devolveremos los comentarios aquí.

682
00:54:39,240 --> 00:54:46,750
Por lo tanto, vamos a devolver el comentario en este punto, res.json (comentario).

683
00:54:46,750 --> 00:54:49,340
Encontrará el comentario específico

684
00:54:49,340 --> 00:54:52,415
y, a continuación, devolverá ese comentario para la publicación.

685
00:54:52,415 --> 00:54:55,185
Para la post-operación, como se da cuenta,

686
00:54:55,185 --> 00:54:56,900
la post-operación no está

687
00:54:56,900 --> 00:55:06,740
permitida en comentarios CommentID.

688
00:55:10,080 --> 00:55:13,805
Por lo tanto, ese es el mensaje que vamos a enviar,

689
00:55:13,805 --> 00:55:19,110
operación POST no es compatible con comentarios barra diagonal CommentID.

690
00:55:19,110 --> 00:55:23,640
Entonces, ese es el mensaje que diremos para el puesto.

691
00:55:23,640 --> 00:55:33,730
Ahora, para el punto, diremos comentarios.Find donde Id (req.Params.CommentID).

692
00:55:34,890 --> 00:55:39,230
Entonces, encontraremos el comentario allí,

693
00:55:40,890 --> 00:55:48,070
y allí comentario, así que para el puesto.

694
00:55:48,070 --> 00:55:50,805
Entonces, encontraremos el comentario allí,

695
00:55:50,805 --> 00:55:53,400
y luego diremos por los comentarios.

696
00:55:53,400 --> 00:55:55,305
Por lo tanto, si encontramos el comentario,

697
00:55:55,305 --> 00:56:07,080
si el comentario no es nulo,

698
00:56:07,080 --> 00:56:19,455
entonces también verificaremos si comment.author.

699
00:56:19,455 --> 00:56:32,625
Si no, comment.arthur es igual a (req.user. _id).

700
00:56:32,625 --> 00:56:38,095
Por lo tanto, estamos cruzando para asegurarnos de que

701
00:56:38,095 --> 00:56:43,755
el comments.author sea el mismo que el usuario actual.

702
00:56:43,755 --> 00:56:50,950
Sólo el usuario actual que ha iniciado sesión - si el usuario es el mismo que el autor de los comentarios,

703
00:56:50,950 --> 00:56:53,760
entonces el usuario podrá actualizar.

704
00:56:53,760 --> 00:56:57,190
Entonces, eso es lo primero que verificaremos.

705
00:56:57,190 --> 00:57:01,900
Entonces, comentarios, luego comments.author.equal a rec.user. _id

706
00:57:01,900 --> 00:57:07,860
Si no, dirás que no estás autorizado a actualizar este comentario.

707
00:57:07,860 --> 00:57:10,859
Como ve.403,

708
00:57:10,859 --> 00:57:13,090
y luego devuelva el siguiente error aquí.

709
00:57:13,090 --> 00:57:16,705
Por lo tanto, crearemos el error allí.

710
00:57:16,705 --> 00:57:21,800
Luego, después de esto, diremos

711
00:57:29,910 --> 00:57:36,860
req.body.author, req.user. _id,

712
00:57:40,010 --> 00:57:42,215
eso es importante.

713
00:57:42,215 --> 00:57:45,580
Ahora bien, estos dos no son necesarios aquí,

714
00:57:45,580 --> 00:57:51,385
porque estamos guardando directamente el comentario.

715
00:57:51,385 --> 00:58:05,980
Luego píldoras, vamos a decir Comments.FindByidandUpdate,

716
00:58:05,980 --> 00:58:14,965
y req.Params.CommentID.

717
00:58:14,965 --> 00:58:18,395
Por lo tanto, encontraremos ese comentario específico,

718
00:58:18,395 --> 00:58:21,925
porque ya se nos ha proporcionado el ID del comentario.

719
00:58:21,925 --> 00:58:27,205
Por lo tanto, vamos a hacer comentarios findById req.params.commentID.

720
00:58:27,205 --> 00:58:30,260
Entonces diremos entonces (comentario).

721
00:58:32,730 --> 00:58:38,705
Cuando suministre el req.params.commentID,

722
00:58:38,705 --> 00:58:42,275
tendremos que proporcionar explícitamente el segundo parámetro,

723
00:58:42,275 --> 00:58:45,825
que es lo que queremos cambiar.

724
00:58:45,825 --> 00:58:52,285
Entonces, diremos $set: req.body.

725
00:58:52,285 --> 00:58:54,970
Por lo tanto, el segundo parámetro, esencialmente,

726
00:58:54,970 --> 00:58:58,740
le dice qué parte está cambiando.

727
00:58:58,740 --> 00:59:03,710
Ahora, ya que se nos ha suministrado el cuerpo que contiene el comentario actualizado,

728
00:59:03,710 --> 00:59:09,140
vamos a actualizar todo el comentario en sí mismo.

729
00:59:09,510 --> 00:59:18,205
Entonces la otra parte que vamos a pedir es nueva: verdadera.

730
00:59:18,205 --> 00:59:23,240
Por lo tanto, esto asegurará que el comentario actualizado será devuelto en

731
00:59:23,240 --> 00:59:29,815
el estudio de esta llamada a los comments.FindByidAndUpdate.

732
00:59:29,815 --> 00:59:32,565
Entonces, diremos luego comentarios.

733
00:59:32,565 --> 00:59:35,214
Cuando se devuelve ese comentario,

734
00:59:35,214 --> 00:59:38,440
entonces diremos Comments.FindById (comentario. _id).

735
00:59:46,200 --> 00:59:51,460
A continuación, rellene el autor allí.

736
00:59:51,460 --> 00:59:53,785
Vamos a llenar el autor allí,

737
00:59:53,785 --> 00:59:58,490
y luego vamos a decir luego comentario.

738
00:59:58,700 --> 01:00:09,680
Por lo tanto, verá que obtendremos el comentario y luego devolveremos el comentario en este punto.

739
01:00:09,680 --> 01:00:13,095
Por lo tanto, así es como vamos a actualizar el comentario.

740
01:00:13,095 --> 01:00:17,395
Entonces, esta es la situación en la que el comentario no es nulo.

741
01:00:17,395 --> 01:00:20,625
Por lo tanto, esta declaración if para el comentario no es nula.

742
01:00:20,625 --> 01:00:23,785
Por lo tanto, el resto si parte,

743
01:00:23,785 --> 01:00:29,020
ahora esto no es aplicable,

744
01:00:29,020 --> 01:00:33,325
así que diremos otra cosa, error.

745
01:00:33,325 --> 01:00:35,470
El error en este caso.

746
01:00:35,470 --> 01:00:37,825
Por lo tanto, si el comentario es nulo,

747
01:00:37,825 --> 01:00:40,850
eso significa que no encontramos el comentario allí,

748
01:00:40,850 --> 01:00:43,650
por lo que no puede modificar un comentario inexistente.

749
01:00:43,650 --> 01:00:44,805
Así que vamos a decir err,

750
01:00:44,805 --> 01:00:54,700
nuevo comentario de error req.params.commentid no encontrado y luego devolveremos el error.

751
01:00:54,700 --> 01:01:01,255
Entonces, así es como manejaremos la parte puesta de nuestro comentario aquí,

752
01:01:01,255 --> 01:01:04,099
y luego finalmente la eliminación.

753
01:01:06,120 --> 01:01:11,130
Para la eliminación, nuevamente tendremos que encontrar primero

754
01:01:11,130 --> 01:01:12,900
comments.findById (req.params.commentID)

755
01:01:12,900 --> 01:01:25,720
y luego comentar.

756
01:01:25,720 --> 01:01:28,150
Por lo tanto, vamos a buscar el comentario.

757
01:01:28,150 --> 01:01:34,160
Por lo tanto, primero verificaremos si el comentario no es igual a nulo.

758
01:01:36,180 --> 01:01:39,955
Eso es importante comprobarlo aquí.

759
01:01:39,955 --> 01:01:50,990
Luego, la siguiente parte que comprobaremos es si comment.author es igual a req.user. _id.

760
01:01:58,830 --> 01:02:03,400
Nos aseguramos de que este usuario que está tratando de eliminar

761
01:02:03,400 --> 01:02:08,060
este comentario sea exactamente el mismo usuario que insertó el comentario en primer lugar.

762
01:02:08,060 --> 01:02:10,750
Si no, así que si esta es la situación

763
01:02:10,750 --> 01:02:13,920
, verá «¡No está autorizado a eliminar este comentario!»

764
01:02:13,920 --> 01:02:16,365
Y luego devuelve el estado allí.

765
01:02:16,365 --> 01:02:20,920
Luego abajo aquí,

766
01:02:20,920 --> 01:02:41,310
diremos Comments.FindByIDandRemove aquí.

767
01:02:41,310 --> 01:02:48,750
Por lo tanto, diremos Comments.FindByIDandRemove (req.Params.CommentID),

768
01:02:48,750 --> 01:02:54,035
luego obtendremos alguna respuesta del comentario.

769
01:02:54,035 --> 01:02:55,630
Entonces, en este punto,

770
01:02:55,630 --> 01:02:59,830
simplemente diremos, Res.statusCode.

771
01:02:59,830 --> 01:03:05,365
Entonces diremos Comments.findByidandRemove luego respuesta.

772
01:03:05,365 --> 01:03:07,210
Si se elimina correctamente,

773
01:03:07,210 --> 01:03:10,915
diremos 200 y luego res.json

774
01:03:10,915 --> 01:03:17,260
respuesta aquí y también detectaremos el error en este punto.

775
01:03:17,260 --> 01:03:25,195
Así que, déjame copiar eso aquí y luego incluiremos la captura del error en este punto.

776
01:03:25,195 --> 01:03:28,895
Así que, eso es lo primero que comprobaremos.

777
01:03:28,895 --> 01:03:33,500
Nos aseguraremos de que el comentario no sea igual a nulo.

778
01:03:33,630 --> 01:03:38,360
De lo contrario, así que esta es la parte más.

779
01:03:39,810 --> 01:03:44,170
Por lo tanto, esta es la parte más del

780
01:03:44,170 --> 01:03:48,040
nuevo comentario if else req.params.commentid no encontrado y luego

781
01:03:48,040 --> 01:03:56,220
404 y enviar la parte de lo demás para nosotros y luego la parte entonces manejará apropiadamente.

782
01:03:56,220 --> 01:04:01,460
Entonces, estos son los cambios que hacemos para el enrutador de comentarios aquí.

783
01:04:01,460 --> 01:04:05,025
Por lo tanto, estamos manejando la publicación get put y delete para

784
01:04:05,025 --> 01:04:10,330
los comentarios de barra diagonal y los comentarios de barra diagonal barra diagonal impacto CommentID.

785
01:04:10,330 --> 01:04:12,495
Entonces, una vez que

786
01:04:12,495 --> 01:04:17,500
hayamos completado esto, entonces necesitamos incluirlo en el archivo app.js.

787
01:04:17,500 --> 01:04:27,345
Por lo tanto, entraremos en el archivo app.js y luego diremos

788
01:04:27,345 --> 01:04:30,070
var CommentRouter

789
01:04:31,130 --> 01:04:42,280
requiere rutas/CommentRouter.

790
01:04:42,280 --> 01:04:45,960
Entonces, tenemos el enrutador de comentarios aquí y luego

791
01:04:45,960 --> 01:04:49,390
bajaremos al archivo app.js abajo aquí y

792
01:04:49,390 --> 01:04:54,610
luego diremos app.use

793
01:04:55,040 --> 01:05:04,695
slash comments, CommentRouter aquí.

794
01:05:04,695 --> 01:05:07,365
Eso es todo. Así que ahora,

795
01:05:07,365 --> 01:05:09,390
mi enrutador de comentarios está listo.

796
01:05:09,390 --> 01:05:12,935
Entonces, sigamos adelante y guardemos todos los cambios.

797
01:05:12,935 --> 01:05:19,020
Entonces nuestro servidor se actualiza

798
01:05:19,020 --> 01:05:24,420
para manejar todas las solicitudes de nuestros clientes React aquí.

799
01:05:24,420 --> 01:05:27,800
Ahora, si quieres hacer la forma alternativa, es decir,

800
01:05:27,800 --> 01:05:34,120
tienes tus comentarios como sub-documentos de tu plato y luego quieres manejarlo,

801
01:05:34,120 --> 01:05:37,680
entonces necesitarás actualizar el cliente React

802
01:05:37,680 --> 01:05:42,185
para poder usar los comentarios desde dentro de cada plato apropiadamente.

803
01:05:42,185 --> 01:05:44,830
Eso se dejará como un ejercicio para ti.

804
01:05:44,830 --> 01:05:48,920
Piense en cómo diseñaría su cliente de reacción de tal manera que

805
01:05:48,920 --> 01:05:53,465
funcione muy bien con la versión anterior

806
01:05:53,465 --> 01:06:03,735
del servidor que tenía los comentarios como sub-documentos de sus propios platos.

807
01:06:03,735 --> 01:06:07,065
Ahora, esa será una forma interesante de implementarlo.

808
01:06:07,065 --> 01:06:10,480
Por supuesto, es un poco más complicado que la forma en que

809
01:06:10,480 --> 01:06:14,965
implementamos el cliente React donde mantuvimos

810
01:06:14,965 --> 01:06:20,840
los comentarios independientes de los platos, pero luego el trabajo adicional es responsabilidad

811
01:06:20,840 --> 01:06:22,910
del lado del cliente porque necesitas seleccionar

812
01:06:22,910 --> 01:06:26,765
los comentarios apropiados cuando estás mostrando un plato específico.

813
01:06:26,765 --> 01:06:30,370
Debe seleccionar los comentarios de todos los comentarios aquí.

814
01:06:30,370 --> 01:06:35,170
Por lo tanto, ese es un trabajo adicional que nuestro cliente React hace debido a

815
01:06:35,170 --> 01:06:40,680
que separamos los comentarios de los propios platos.

816
01:06:40,680 --> 01:06:46,165
Del mismo modo, si puedes rediseñar tu cliente angular para poder

817
01:06:46,165 --> 01:06:51,775
lidiar con la situación en la que los comentarios se mantienen independientes de tus platos.

818
01:06:51,775 --> 01:06:56,020
Ahora, estos son todos los ejercicios que puede hacer para ver cómo puede

819
01:06:56,020 --> 01:07:01,210
extender sus aplicaciones cliente para manejar cualquier tipo de servidor,

820
01:07:01,210 --> 01:07:04,430
los dos tipos diferentes de servidores allí.

821
01:07:04,860 --> 01:07:11,480
Por lo tanto, con esto, completamos la actualización de nuestro servidor aquí.

822
01:07:11,480 --> 01:07:15,040
Por lo tanto, con esto, hemos actualizado todo en el lado del servidor.

823
01:07:15,040 --> 01:07:17,890
Por lo tanto, guardemos todos los cambios en el lado del servidor.

824
01:07:17,890 --> 01:07:26,755
Así que ahora, nuestro servidor está listo para manejar las solicitudes entrantes de nuestro cliente React.

825
01:07:26,755 --> 01:07:29,340
Con esto, completamos este ejercicio.

826
01:07:29,340 --> 01:07:33,300
En este ejercicio, ahora hemos preparado nuestro servidor express

827
01:07:33,300 --> 01:07:38,985
para manejar las solicitudes entrantes de nuestro cliente React.

828
01:07:38,985 --> 01:07:43,190
En el próximo ejercicio, vamos a ver el cliente reaccionar con más detalle para

829
01:07:43,190 --> 01:07:48,000
entender cómo se está comunicando con este servidor adicional.

830
01:07:48,000 --> 01:07:50,640
Este es un buen momento para que haga

831
01:07:50,640 --> 01:07:55,880
una cobertura git con el mensaje que integra cliente y servidor.