1 00:00:03,710 --> 00:00:07,605 Ahora que hemos aprendido acerca de la Población de Mangosta, 2 00:00:07,605 --> 00:00:14,040 y cómo nos permite rellenar un documento con información de otro documento. 3 00:00:14,040 --> 00:00:20,605 En este ejercicio, modificaremos el servidor express en el que hemos estado trabajando hasta ahora. 4 00:00:20,605 --> 00:00:25,580 En el esquema de plato que hemos definido anteriormente, tuvimos comentarios. 5 00:00:25,580 --> 00:00:28,365 Para los comentarios, teníamos el campo autor 6 00:00:28,365 --> 00:00:31,490 que usamos para almacenar los detalles sobre el autor. 7 00:00:31,490 --> 00:00:40,815 En este ejercicio, vamos a convertir el campo autor en una referencia a un documento de usuario, 8 00:00:40,815 --> 00:00:46,265 y vamos a utilizar la población de mangosta para rellenar la información en 9 00:00:46,265 --> 00:00:50,330 el documento de platos como y cuando sea necesario con el 10 00:00:50,330 --> 00:00:54,440 fin de proporcionar la información al cliente. 11 00:00:54,440 --> 00:00:59,960 Ahora el uso de población poblada y mangosta debe hacerse 12 00:00:59,960 --> 00:01:05,550 con prudencia para no causar demasiada sobrecarga en el lado del servidor. 13 00:01:05,550 --> 00:01:06,890 Ahora, en este ejercicio, 14 00:01:06,890 --> 00:01:09,395 vamos a usarlo simplemente para rellenar la información 15 00:01:09,395 --> 00:01:13,280 en el campo de autor de nuestros comentarios. 16 00:01:13,280 --> 00:01:18,660 Por lo tanto, vamos a proceder con el ejercicio para aprender cómo usamos la población de mangosta. 17 00:01:18,660 --> 00:01:21,455 Para comenzar en este ejercicio, 18 00:01:21,455 --> 00:01:25,315 vaya al proyecto y abra el archivo user.js. 19 00:01:25,315 --> 00:01:27,730 Entonces, en el archivo user.js, 20 00:01:27,730 --> 00:01:29,600 almacenamos el esquema de usuario. 21 00:01:29,600 --> 00:01:35,515 Voy a modificar el esquema del usuario agregando un par de campos más allí. 22 00:01:35,515 --> 00:01:38,220 Uno es el primer nombre, 23 00:01:38,220 --> 00:01:40,070 que será 24 00:01:40,070 --> 00:01:48,115 del tipo string y 25 00:01:48,115 --> 00:01:52,025 el predeterminado sería una cadena vacía. 26 00:01:52,025 --> 00:01:56,555 Por lo tanto, el primer nombre como 27 00:01:56,555 --> 00:02:03,630 el nombre indica, almacena el primer nombre para el usuario y luego tendremos otro campo llamado apellido, 28 00:02:03,630 --> 00:02:06,540 que también es del mismo tipo. 29 00:02:06,540 --> 00:02:13,540 Por lo tanto, sólo voy a copiar estas dos piezas de información y luego copiarla 30 00:02:13,540 --> 00:02:20,735 aquí y así ahora nuestro documento de usuario contendrá, 31 00:02:20,735 --> 00:02:22,840 además del nombre de usuario y contraseña, 32 00:02:22,840 --> 00:02:26,760 nombre de usuario y silencio y sal que hemos visto anteriormente, 33 00:02:26,760 --> 00:02:34,450 que se agrega automáticamente por el módulo de mangosta local pasaporte . 34 00:02:34,450 --> 00:02:39,840 También tendremos el nombre y apellidos del usuario que se define aquí. 35 00:02:39,840 --> 00:02:43,505 Más adelante veremos cómo inicializaríamos 36 00:02:43,505 --> 00:02:50,765 estos valores modificando el proceso de registro del usuario. 37 00:02:50,765 --> 00:02:52,950 Ahora, una vez que hayamos completado 38 00:02:52,950 --> 00:02:56,599 esto, de esta manera la información del usuario 39 00:02:56,599 --> 00:03:00,880 puede ser simplemente recuperada buscando el documento de usuario aquí. 40 00:03:00,880 --> 00:03:05,200 Entonces, ahora que tenemos la información sobre el usuario en el documento de usuario, 41 00:03:05,200 --> 00:03:08,560 entrando en el esquema de plato, 42 00:03:08,560 --> 00:03:11,015 así que entramos en el archivo dishes.js. 43 00:03:11,015 --> 00:03:13,260 En el esquema de plato anterior, 44 00:03:13,260 --> 00:03:18,465 estábamos almacenando el autor del documento en forma de una cadena aquí. 45 00:03:18,465 --> 00:03:22,700 Ahora vamos a aprovechar el hecho de que 46 00:03:22,700 --> 00:03:27,425 tenemos el apoyo de la población de mangosta. 47 00:03:27,425 --> 00:03:33,740 Así que voy a convertir el campo de comentario de una cadena en 48 00:03:33,740 --> 00:03:41,975 tipos de esquema de mangosta ID de objeto. 49 00:03:41,975 --> 00:03:49,120 Así que, de esta manera, lo siento, campo equivocado. 50 00:03:49,120 --> 00:03:53,135 Quise convertir el campo de autor en 51 00:03:53,135 --> 00:04:02,295 tipos de esquema de mangosta ID de objeto. 52 00:04:02,295 --> 00:04:05,390 Por lo tanto, el campo autor ahora en lugar de almacenar una cadena, 53 00:04:05,390 --> 00:04:10,835 tendrá una referencia al documento de usuario. 54 00:04:10,835 --> 00:04:14,105 Entonces, cuando convierto el campo de autor en este tipo, 55 00:04:14,105 --> 00:04:20,180 entonces la segunda propiedad que definí aquí será una referencia, 56 00:04:20,180 --> 00:04:25,229 que sería una referencia al modelo de usuario. 57 00:04:25,229 --> 00:04:27,980 Por lo tanto, de esta manera, ahora vamos a 58 00:04:27,980 --> 00:04:31,370 conectar este campo de autor y este campo de autor 59 00:04:31,370 --> 00:04:37,585 simplemente almacenará una referencia al ID del documento de usuario, en 60 00:04:37,585 --> 00:04:43,790 lugar de almacenar los detalles sobre el autor en forma de nombre. 61 00:04:43,790 --> 00:04:45,100 Ahora, cuando hacemos eso, 62 00:04:45,100 --> 00:04:48,350 podemos usar mangosta poblar para rellenar 63 00:04:48,350 --> 00:04:53,115 esta información en nuestro documento de platos siempre que sea necesario. 64 00:04:53,115 --> 00:04:58,595 Entonces, con esta modificación al esquema de platos, en el archivo dishes.js, 65 00:04:58,595 --> 00:05:05,910 ahora actualizaremos el enrutador de platos para usar la población de mangosta. 66 00:05:05,910 --> 00:05:09,030 Entonces, yendo a dishRouter.js. 67 00:05:09,030 --> 00:05:16,120 En enrutador de platos, recuerde que cuando estábamos recibiendo un plato aquí, 68 00:05:16,120 --> 00:05:19,470 ahora cuando usted consigue el plato aquí, 69 00:05:19,470 --> 00:05:23,820 decimos que los platos encuentran entonces. 70 00:05:23,820 --> 00:05:26,610 Entonces, justo en ese punto, 71 00:05:26,610 --> 00:05:36,005 diremos que los platos encuentran y diremos después de esto, poblar. 72 00:05:36,005 --> 00:05:41,924 Por lo tanto, estamos utilizando el apoyo de la población en mangosta 73 00:05:41,924 --> 00:05:48,165 y vamos a decir poblar comentarios autor. 74 00:05:48,165 --> 00:05:49,740 Por lo tanto, al afirmar esto, 75 00:05:49,740 --> 00:05:51,060 estamos diciendo que cuando 76 00:05:51,060 --> 00:05:58,750 el documento de platos se ha construido para devolver la respuesta al usuario, 77 00:05:58,750 --> 00:06:05,810 vamos a llenar el campo de autor dentro de allí desde el documento de usuario allí dentro. 78 00:06:05,810 --> 00:06:09,095 Por lo tanto, esta llamada al relleno asegurará que 79 00:06:09,095 --> 00:06:14,665 el otro campo se rellenará con la información según sea necesario. 80 00:06:14,665 --> 00:06:18,565 Del mismo modo, ir a la identificación del plato aquí, 81 00:06:18,565 --> 00:06:21,660 incluso en el ID del plato, lo mismo. 82 00:06:21,660 --> 00:06:31,680 Vamos a decir poblar y comentarios autor añadido 83 00:06:31,680 --> 00:06:37,320 en los platos encontrar por id en 84 00:06:37,320 --> 00:06:43,395 el get del endpoint /dish ID. 85 00:06:43,395 --> 00:06:54,350 Del mismo modo, en los comentarios también cuando recuperamos el plato, 86 00:06:54,520 --> 00:07:02,370 vamos a decir poblar comentarios autor aquí y 87 00:07:02,370 --> 00:07:09,900 lo mismo también en el enrutador de plato, 88 00:07:09,900 --> 00:07:13,695 comentarios ID de plato, ID de comentario también. 89 00:07:13,695 --> 00:07:16,530 Cuanto más grande poblando esta información allí. 90 00:07:16,530 --> 00:07:22,620 Ahora, por supuesto, lo que esto significa es que cuando usted está publicando el plato, 91 00:07:22,620 --> 00:07:30,090 antes está incluyendo la información del autor en el cuerpo del mensaje. 92 00:07:30,090 --> 00:07:35,120 Entonces, ahora aquí cuando tratamos de empujar el comentario en eso, 93 00:07:35,120 --> 00:07:41,370 por lo que esta publicación corresponde al campo de comentarios ID del plato. 94 00:07:41,370 --> 00:07:46,280 Por lo tanto, así es como estábamos publicando un comentario a un plato específico. 95 00:07:46,280 --> 00:07:48,570 Entonces, ahora en este post, 96 00:07:48,570 --> 00:07:53,890 ya que ya no estamos almacenando la información sobre el autor, 97 00:07:53,890 --> 00:08:02,400 así que lo que tenemos que hacer es cuando empujamos el elemento en el campo de autor allí. 98 00:08:02,400 --> 00:08:06,720 Por lo tanto, aquí cuando se está llenando la información en el plato, 99 00:08:06,720 --> 00:08:10,680 tendremos que primero- 100 00:08:12,010 --> 00:08:16,430 Recordemos que el cuerpo contiene el comentario ya, 101 00:08:16,430 --> 00:08:21,505 pero la propiedad del autor no estará allí en el cuerpo del mensaje en el libro, 102 00:08:21,505 --> 00:08:26,020 pero dependiendo de qué usuario está publicando esta información, 103 00:08:26,020 --> 00:08:29,250 podemos rellene inmediatamente el campo de autor. 104 00:08:29,250 --> 00:08:32,535 Ahora, ¿cómo sabemos qué usuario está publicando esta información? 105 00:08:32,535 --> 00:08:38,165 El hecho de que hayamos hecho el usuario verificado aquí para la publicación, 106 00:08:38,165 --> 00:08:42,115 significa que un usuario específico está publicando esta información, 107 00:08:42,115 --> 00:08:44,250 y al hacer el usuario verificado, 108 00:08:44,250 --> 00:08:50,415 ya habríamos cargado en el req.user en el objeto de solicitud. 109 00:08:50,415 --> 00:08:51,925 En el objeto de solicitud, 110 00:08:51,925 --> 00:08:55,565 podemos entrar y decir usuario de naufragio, 111 00:08:55,565 --> 00:08:59,010 y luego subrayar ID aquí. 112 00:08:59,010 --> 00:09:01,910 Así que, una vez más, permítanme reiterar este punto, 113 00:09:01,910 --> 00:09:05,760 ¿cómo obtenemos la información del autor aquí? 114 00:09:05,760 --> 00:09:10,470 Ahora, recuerde que hemos actualizado el esquema de platos, de 115 00:09:10,470 --> 00:09:13,875 modo que el campo autor en el comentario simplemente almacenará 116 00:09:13,875 --> 00:09:20,915 el ID del objeto que se refiere al usuario que está publicando este comentario. 117 00:09:20,915 --> 00:09:24,450 Ahora, ¿cómo sabemos qué usuario está publicando este comentario? 118 00:09:24,450 --> 00:09:27,085 Ahora de nuevo, para reiterar este punto, 119 00:09:27,085 --> 00:09:31,825 recuerde que cuando verificamos el usuario aquí llamando a autenticar verificar usuario, 120 00:09:31,825 --> 00:09:37,590 el pasaporte autorizado JWT habría cargado 121 00:09:37,590 --> 00:09:45,120 la información del usuario en el cuerpo de la solicitud en forma de req.user. 122 00:09:45,120 --> 00:09:48,470 Por lo tanto, ese usuario contendrá el ID 123 00:09:48,470 --> 00:09:52,520 del usuario específico que realmente está publicando este comentario. 124 00:09:52,520 --> 00:09:55,730 Por lo tanto, ya hemos verificado la autenticidad del usuario, 125 00:09:55,730 --> 00:10:01,400 por lo que el ID de usuario se puede obtener simplemente diciendo req.user. 126 00:10:01,400 --> 00:10:04,400 _ID, y el ID de ese usuario, 127 00:10:04,400 --> 00:10:09,380 asignaré esto al campo de autor fuera del comentario. 128 00:10:09,380 --> 00:10:10,990 Ahora, cuando llegue el comentario, 129 00:10:10,990 --> 00:10:13,880 el comentario en el cuerpo del mensaje de solicitud 130 00:10:13,880 --> 00:10:17,355 solo contendrá el campo de calificación y el campo de comentario. 131 00:10:17,355 --> 00:10:23,425 Ahora no queremos enviar explícitamente el campo de autor más desde el lado del cliente, 132 00:10:23,425 --> 00:10:26,090 en lugar de eso debería insertarse automáticamente 133 00:10:26,090 --> 00:10:28,990 en el lado del servidor basado en 134 00:10:28,990 --> 00:10:32,180 la autenticidad del usuario Ese es el punto que había estado 135 00:10:32,180 --> 00:10:36,830 reiterando en esta modificación que he hecho aquí. 136 00:10:36,830 --> 00:10:43,400 Por lo tanto, la información de los usuarios se obtiene automáticamente del req.user que se 137 00:10:43,400 --> 00:10:50,200 carga en el cuerpo del mensaje de solicitud por el usuario de verificación de autenticación, 138 00:10:50,200 --> 00:10:55,250 que va a usar Passport authenticate con la estrategia JWT allí. 139 00:10:55,250 --> 00:10:59,795 Además, ahora cuando recibimos el plato actualizado aquí, 140 00:10:59,795 --> 00:11:03,695 necesitamos rellenar la información del autor en el plato. 141 00:11:03,695 --> 00:11:05,500 Entonces, en este punto, 142 00:11:05,500 --> 00:11:08,675 cuando recibamos el plato aquí 143 00:11:08,675 --> 00:11:15,370 , vamos a buscar los platos aquí. 144 00:11:15,370 --> 00:11:20,150 Por lo tanto, vamos a decir dishes.FindById 145 00:11:21,000 --> 00:11:28,090 y luego proporcionar el ID del plato como el parámetro aquí, 146 00:11:28,090 --> 00:11:33,175 así que vamos 147 00:11:33,175 --> 00:11:43,405 a decir encontrar por ID, ID del plato, y luego, tenemos que llenar el autor comentarios aquí, 148 00:11:43,405 --> 00:11:55,600 y luego vamos a decir entonces plato. 149 00:11:55,600 --> 00:12:04,370 Dentro de allí, vamos a enviar esta información del plato de vuelta al usuario aquí. 150 00:12:04,370 --> 00:12:07,260 Así que, déjame cortar eso y pegarlo aquí. 151 00:12:07,260 --> 00:12:12,670 Por lo tanto, esta modificación es necesaria porque ahora necesito rellenar 152 00:12:12,670 --> 00:12:15,190 la información del autor en 153 00:12:15,190 --> 00:12:18,760 el comentario antes de poder enviar la información actual al usuario. 154 00:12:18,760 --> 00:12:22,220 Por lo tanto, esta es la modificación adicional que tenemos que 155 00:12:22,220 --> 00:12:26,105 hacer cuando usamos la población de mangosta aquí. 156 00:12:26,105 --> 00:12:29,950 Del mismo modo, ahora entrando en el punto, 157 00:12:29,950 --> 00:12:34,450 cuando modificamos un comentario específico con el ID de comentario, 158 00:12:34,450 --> 00:12:40,830 por lo que esto está debajo de la parte ID de comentario de ID del plato. 159 00:12:40,830 --> 00:12:42,890 Por lo tanto, cuando hacemos el puesto aquí, por 160 00:12:42,890 --> 00:12:49,230 lo que primero encontramos los platos encontrar por id req params plato ID, 161 00:12:49,230 --> 00:12:50,840 luego en el plato. Por lo 162 00:12:50,840 --> 00:12:57,160 tanto, lo primero que comprobamos es asegurarse de que si el plato no es nulo, 163 00:12:57,160 --> 00:13:01,430 y los comentarios del plato ID no es 164 00:13:01,430 --> 00:13:08,665 nulo, por lo que comprobamos para asegurarse de que el comentario está realmente presente en el plato, 165 00:13:08,665 --> 00:13:12,320 y luego cuando se devuelve el plato en sí, 166 00:13:12,320 --> 00:13:16,385 entonces tenemos que buscar de nuevo 167 00:13:16,385 --> 00:13:21,230 el plato porque tenemos que rellenar los comentarios autor en el plato. 168 00:13:21,230 --> 00:13:27,950 Así que aquí, diremos dishes.findbyId (ID del plato), 169 00:13:31,750 --> 00:13:36,880 la razón por la que necesitamos hacer una búsqueda más es porque 170 00:13:36,880 --> 00:13:42,240 necesitamos rellenar el comments.author aquí, por 171 00:13:42,240 --> 00:13:46,355 lo que esa es la única razón por la que necesitamos hacer una búsqueda más aquí. 172 00:13:46,355 --> 00:13:50,720 Luego, cuando recibimos el plato aquí, 173 00:13:52,260 --> 00:13:57,700 obviamente porque acabamos de actualizar el plato para que la información del plato se 174 00:13:57,700 --> 00:14:03,640 encuentre en la base de datos, 175 00:14:03,640 --> 00:14:07,490 por lo que debería funcionar bien y luego dentro se dirá el 176 00:14:07,490 --> 00:14:12,215 código de estado de riesgo 200 res conjunto de contenido de encabezado aplicación json, 177 00:14:12,215 --> 00:14:14,960 y luego devolver el plato aquí, 178 00:14:14,960 --> 00:14:16,740 y luego manejaremos el error aquí, 179 00:14:16,740 --> 00:14:19,630 y luego los otros si los platos 180 00:14:19,630 --> 00:14:24,095 ahora y también los otros errores que hemos configurado anteriormente, 181 00:14:24,095 --> 00:14:27,050 se manejarán como de costumbre aquí. 182 00:14:27,050 --> 00:14:32,790 Por lo tanto, estos son los cambios adicionales que necesitamos para asegurarnos cuando actualices el plato, 183 00:14:32,790 --> 00:14:39,175 cuando estás enviando el comentario actualizado o el plato actualizado, 184 00:14:39,175 --> 00:14:44,485 entonces rellenaremos el comentario en el plato aquí. 185 00:14:44,485 --> 00:14:48,160 Del mismo modo, yendo a la eliminación aquí, 186 00:14:48,160 --> 00:14:50,575 y luego después de eliminar el comentario, de 187 00:14:50,575 --> 00:14:59,310 nuevo vamos a ir a buscar el plato y llenar la información del autor. 188 00:14:59,310 --> 00:15:01,275 Por lo tanto, déjame copiar esta parte, 189 00:15:01,275 --> 00:15:04,130 y luego vamos a estar haciendo exactamente lo mismo aquí, 190 00:15:04,130 --> 00:15:06,770 así que vamos a decir guardar plato, 191 00:15:06,770 --> 00:15:16,210 entonces vamos a ser entonces chequeando dish.FindbyId (autor del plato), 192 00:15:16,210 --> 00:15:19,760 y luego vamos a llenar el autor de comentarios, 193 00:15:19,760 --> 00:15:21,925 y luego vamos a decir (entonces) plato, 194 00:15:21,925 --> 00:15:24,920 y luego res.statusCode, y así sucesivamente, 195 00:15:24,920 --> 00:15:29,350 y el manejo de errores restante como antes aquí. 196 00:15:29,350 --> 00:15:33,040 Por lo tanto, con esta modificación en el enrutador de plato, 197 00:15:33,040 --> 00:15:41,420 ahora el último punto que debemos considerar es el hecho de que en el archivo user.js, 198 00:15:41,420 --> 00:15:43,740 ahora hemos añadido a los campos, 199 00:15:43,740 --> 00:15:49,050 el campo de nombre y apellido que por defecto serán cadenas vacías. 200 00:15:49,050 --> 00:15:51,880 Por lo tanto, cuando el usuario se está registrando, 201 00:15:51,880 --> 00:15:54,670 debemos permitir que el usuario proporcione el nombre y 202 00:15:54,670 --> 00:15:58,040 apellidos en el proceso de registro. 203 00:15:58,040 --> 00:16:00,040 Ahora, ¿dónde tiene lugar eso? 204 00:16:00,040 --> 00:16:03,025 Eso tiene lugar en el archivo.js del usuario. 205 00:16:03,025 --> 00:16:05,390 Entonces, yendo a los usuarios users.js, 206 00:16:05,390 --> 00:16:09,885 cuando el usuario publica en la barra de registro, 207 00:16:09,885 --> 00:16:13,050 antes solo estábamos publicando el nombre de usuario y la contraseña. 208 00:16:13,050 --> 00:16:15,105 Además de esos dos, 209 00:16:15,105 --> 00:16:21,785 en el objeto json que incluimos en el cuerpo del mensaje de solicitud entrando, 210 00:16:21,785 --> 00:16:25,530 el mensaje de solicitud posterior que viene desde el lado del cliente, 211 00:16:25,530 --> 00:16:29,590 también podemos incluir el nombre y apellidos para el usuario. 212 00:16:29,590 --> 00:16:33,740 Entonces, cuando se incluye el nombre y el apellido del usuario, 213 00:16:33,740 --> 00:16:35,590 ¿qué voy a hacer aquí? 214 00:16:35,590 --> 00:16:42,450 Por lo tanto, recuerde que cuando dice user.register en este punto la información del usuario entra, 215 00:16:42,450 --> 00:16:45,785 y luego ha enviado el nombre de usuario aquí, 216 00:16:45,785 --> 00:16:49,460 y también ha asignado la contraseña aquí que se 217 00:16:49,460 --> 00:16:53,380 convertirá en el hash y sal por la mangosta local pasaporte. 218 00:16:53,380 --> 00:17:00,000 Ahora, si no hay ningún error eso significa que el registro del usuario fue exitoso, por 219 00:17:00,000 --> 00:17:08,740 lo que en este punto lo que haremos es decir si req.body. 220 00:17:08,740 --> 00:17:13,420 Nombre de pila. Entonces, lo que significa que el cuerpo del mensaje de solicitud entrante, 221 00:17:13,420 --> 00:17:16,345 si contiene el nombre, 222 00:17:16,345 --> 00:17:24,770 entonces diremos user.firstname es igual a req.body.firstname. 223 00:17:26,160 --> 00:17:29,675 Del mismo modo, para el apellido también. 224 00:17:29,675 --> 00:17:32,040 Así que en este punto, 225 00:17:32,040 --> 00:17:34,780 tendríamos al usuario disponible aquí. 226 00:17:34,780 --> 00:17:40,125 Vea que el usuario está entrando como el segundo parámetro de esta función de devolución de llamada aquí. 227 00:17:40,125 --> 00:17:43,455 Por lo tanto, estamos configurando el primer nombre cambiando 228 00:17:43,455 --> 00:17:51,490 la propiedad de nombre dentro del documento de usuario aquí diciendo, req.body.firstname. 229 00:17:51,490 --> 00:17:55,395 Si existe, entonces estableceremos el nombre del usuario en eso. 230 00:17:55,395 --> 00:18:03,220 Del mismo modo, si el req.body.last name está disponible, 231 00:18:03,220 --> 00:18:09,630 por lo que también actualizaremos el apellido del usuario como req.body.lastname. 232 00:18:09,770 --> 00:18:16,650 Y una vez que hayamos hecho estos dos cambios en el nombre y el apellido, 233 00:18:16,650 --> 00:18:23,160 entonces tenemos que guardar la modificación que hemos hecho al usuario. 234 00:18:23,160 --> 00:18:25,030 Por lo tanto, acabamos de actualizar al usuario. 235 00:18:25,030 --> 00:18:30,550 Entonces, diremos user.save, esto 236 00:18:30,550 --> 00:18:37,190 devolverá el error o el usuario. 237 00:18:37,190 --> 00:18:41,025 Por lo tanto, si la modificación se ha guardado correctamente, 238 00:18:41,025 --> 00:18:43,765 entonces devolverá el error, de 239 00:18:43,765 --> 00:18:49,380 lo contrario devolverá el valor de usuario y este pasaporte autenticará 240 00:18:49,380 --> 00:18:55,710 lo haremos dentro de este usuario aquí. 241 00:18:55,710 --> 00:19:00,505 Entonces, diremos, user.save (err, user). 242 00:19:00,505 --> 00:19:04,740 Y luego también tenemos que cruzar la verificación para asegurarnos de que 243 00:19:04,740 --> 00:19:10,660 si hay un error al guardar los cambios en el usuario, 244 00:19:10,660 --> 00:19:15,180 entonces diremos el código de estado de res 500, 245 00:19:15,180 --> 00:19:18,485 así que permítanme copiar esto desde allí. 246 00:19:18,485 --> 00:19:23,275 Por lo tanto, diremos código de estado res 500, 247 00:19:23,275 --> 00:19:30,220 res establecer el tipo de contenido de encabezado aplicación json y res.jason aquí. 248 00:19:30,220 --> 00:19:35,995 Entonces, y volveremos a este punto. 249 00:19:35,995 --> 00:19:37,960 Si no hay ningún error, 250 00:19:37,960 --> 00:19:40,480 entonces, por supuesto, autenticar al usuario llamando a 251 00:19:40,480 --> 00:19:43,550 autenticar pasaporte con el local para asegurarse de que 252 00:19:43,550 --> 00:19:48,835 el registro del usuario ha sido exitoso 253 00:19:48,835 --> 00:19:56,390 y esto debe hacerse correctamente y en qué caso devolverá este mensaje al lado del cliente. 254 00:19:56,390 --> 00:20:03,215 Tenemos que cerrar este user.save aquí. 255 00:20:03,215 --> 00:20:07,520 Por lo tanto, asegúrese de cerrar este extremo correctamente. 256 00:20:07,520 --> 00:20:11,005 Entonces, user.save está cerrado aquí, y eso es todo. 257 00:20:11,005 --> 00:20:14,730 Estos son los cambios que tenemos que hacer al usuario. 258 00:20:14,730 --> 00:20:21,740 Por lo tanto, después de que el usuario esté registrado con el nombre de usuario dado y la contraseña dada, 259 00:20:21,740 --> 00:20:24,940 luego de que el usuario se registre con éxito, 260 00:20:24,940 --> 00:20:28,235 entonces estableceremos el campo 261 00:20:28,235 --> 00:20:32,925 de nombre y apellido del documento de usuario utilizando estos dos aquí. 262 00:20:32,925 --> 00:20:35,900 Queremos asegurarnos de que el usuario se ha 263 00:20:35,900 --> 00:20:39,160 registrado correctamente antes de enviar el nombre y apellidos para eso. Por 264 00:20:39,160 --> 00:20:42,540 lo tanto, es por eso que estamos llevando a cabo esta operación después de que el usuario 265 00:20:42,540 --> 00:20:46,360 se registra con éxito. Eso es todo. 266 00:20:46,360 --> 00:20:53,785 Vamos a guardar los cambios e ir a revisar el servidor. 267 00:20:53,785 --> 00:20:56,185 Después de guardar los cambios, 268 00:20:56,185 --> 00:20:59,980 vamos ahora a la terminal y 269 00:20:59,980 --> 00:21:06,925 luego antes de iniciar el servidor, 270 00:21:06,925 --> 00:21:16,690 permítanme primero revisar mi MongoDB y eliminar el usuario que nos hemos registrado anteriormente. 271 00:21:16,690 --> 00:21:25,640 Entonces, diremos usar confusión y luego diremos db.usersfind. 272 00:21:25,650 --> 00:21:30,690 Por lo tanto, sabemos que este usuario en particular se ha registrado anteriormente, 273 00:21:30,690 --> 00:21:32,580 pero cuando registramos a ese usuario, 274 00:21:32,580 --> 00:21:35,700 no registramos el nombre y apellidos del usuario. 275 00:21:35,700 --> 00:21:39,155 Por lo tanto, voy a eliminar este usuario y luego volver a registrar al usuario. 276 00:21:39,155 --> 00:21:48,370 Entonces, para hacer eso usando la ondulación de Mongo, diré que los usuarios de db caen, 277 00:21:48,370 --> 00:21:52,220 y luego diremos que los usuarios de db encuentran, 278 00:21:52,220 --> 00:21:54,620 y eso debería devolver un vacío. 279 00:21:54,620 --> 00:22:01,685 No hay usuarios registrados allí y luego saldremos de la ondulación de Mongo. 280 00:22:01,685 --> 00:22:05,285 Y así, una vez que hayamos eliminado ese usuario registrado, 281 00:22:05,285 --> 00:22:08,760 entonces, permítanme iniciar mi servidor. 282 00:22:09,490 --> 00:22:12,275 Y una vez que el servidor esté en funcionamiento, 283 00:22:12,275 --> 00:22:16,240 vayamos a Postman y luego registremos 284 00:22:16,240 --> 00:22:20,930 un nuevo usuario junto con el nombre y apellidos del usuario. 285 00:22:20,930 --> 00:22:26,845 Luego, iniciarán sesión como ese usuario y luego veremos cómo 286 00:22:26,845 --> 00:22:31,650 la población de Mongoose nos ayuda a rellenar la información sobre 287 00:22:31,650 --> 00:22:37,000 el usuario automáticamente en el documento allí. 288 00:22:37,000 --> 00:22:40,029 Ahora yendo a Cartero, 289 00:22:40,029 --> 00:22:42,660 déjame hacer un registro de un nuevo usuario. 290 00:22:42,660 --> 00:22:48,310 Por lo tanto, estoy haciendo una publicación localhost: 3000 usuarios se registran. 291 00:22:48,310 --> 00:22:50,715 En el cuerpo del mensaje, 292 00:22:50,715 --> 00:22:54,910 teníamos el nombre de usuario y la contraseña ya dentro. 293 00:22:54,910 --> 00:22:59,199 Permítanme añadir dos campos adicionales: 294 00:22:59,199 --> 00:23:09,350 nombre, apellido. 295 00:23:14,880 --> 00:23:18,530 A continuación, registre ese usuario. 296 00:23:20,850 --> 00:23:23,680 Por lo tanto, una vez que registre al usuario, 297 00:23:23,680 --> 00:23:26,350 puede ver que el registro fue exitoso. 298 00:23:26,350 --> 00:23:29,810 Ahora, déjame iniciar sesión como este usuario. 299 00:23:29,820 --> 00:23:32,640 Por lo tanto, para iniciar sesión como usuario, 300 00:23:32,640 --> 00:23:37,620 permítanme hacer una publicación y verificación cruzada para asegurarme. 301 00:23:37,620 --> 00:23:40,475 Por lo tanto, estoy haciendo una publicación para que los usuarios inicien sesión. 302 00:23:40,475 --> 00:23:45,725 Permítanme cruzar la comprobación y veo que el nombre de usuario y la contraseña están correctamente escritos allí. 303 00:23:45,725 --> 00:23:47,775 Entonces, cuando inicio sesión, 304 00:23:47,775 --> 00:23:53,165 debería iniciar sesión con éxito y debería poder obtener este token allí. 305 00:23:53,165 --> 00:24:02,660 Debido a que este token es esencial para que podamos agregar en un plato a nuestro sitio de servidor. 306 00:24:02,660 --> 00:24:05,915 Por lo tanto, después de obtener el token, 307 00:24:05,915 --> 00:24:10,250 copie esta cadena de token y guárdela porque lo necesitará en 308 00:24:10,250 --> 00:24:13,220 el encabezado de autorización para las 309 00:24:13,220 --> 00:24:16,910 operaciones de publicación de poner y eliminar que va a realizar más adelante. 310 00:24:16,910 --> 00:24:20,540 Así que déjame copiar ese token. 311 00:24:20,540 --> 00:24:23,890 Ahora, normalmente la forma en que mantendría estos tokens es, 312 00:24:23,890 --> 00:24:28,400 que simplemente abriré un documento de texto y luego lo copiaré y pegaré en el documento de texto. 313 00:24:28,400 --> 00:24:31,190 Para que para las solicitudes posteriores de cartero, 314 00:24:31,190 --> 00:24:34,230 simplemente puedo copiar esta cadena y luego 315 00:24:34,230 --> 00:24:37,770 pegarla en el encabezado de autorización, si es necesario. 316 00:24:37,770 --> 00:24:44,070 Entonces, déjame copiar ese token y aquí tengo un documento de texto abierto aquí. 317 00:24:44,070 --> 00:24:50,815 Por lo tanto, voy a pegar esa cadena en este documento de texto. 318 00:24:50,815 --> 00:24:57,170 Por lo tanto, aquí tenemos el token que hemos obtenido. 319 00:24:57,170 --> 00:25:03,120 Vamos ahora a publicar un plato en nuestro servidor. 320 00:25:03,120 --> 00:25:05,135 Volviendo al cartero, 321 00:25:05,135 --> 00:25:07,535 déjame poner un plato en el servidor. 322 00:25:07,535 --> 00:25:12,690 Por lo tanto, aquí es donde voy a elegir el puesto aquí. 323 00:25:12,690 --> 00:25:21,334 Dentro de aquí, tengo la información de plato que había utilizado antes, pero para los comentarios, 324 00:25:21,334 --> 00:25:25,345 ahora, recuerde que antes teníamos campo autor que estaba almacenando una cadena. 325 00:25:25,345 --> 00:25:28,770 Por lo tanto, todos estos comentarios no son válidos. 326 00:25:28,770 --> 00:25:35,110 Por lo tanto, voy a eliminar todos estos comentarios de la presentación porque, 327 00:25:35,110 --> 00:25:42,570 ahora, esperamos que el usuario publique comentarios por su cuenta. 328 00:25:42,570 --> 00:25:44,460 Cuando el usuario publique comentarios, 329 00:25:44,460 --> 00:25:52,155 agregaremos automáticamente el ID del usuario en el campo de autor de los comentarios. 330 00:25:52,155 --> 00:25:55,390 Así que, déjame publicar este plato aquí. 331 00:25:55,390 --> 00:25:57,325 Ir al encabezado, 332 00:25:57,325 --> 00:26:01,550 en el encabezado de autorización, voy a decir, 333 00:26:02,310 --> 00:26:12,785 portador y luego, pegar el token y luego enviar. 334 00:26:12,785 --> 00:26:17,055 Debería hacer un post sobre eso. 335 00:26:17,055 --> 00:26:21,950 Entonces, diré post y así cuando publique ahora, 336 00:26:21,950 --> 00:26:26,785 ves que este plato se ha publicado en el lado del servidor, 337 00:26:26,785 --> 00:26:31,340 y con la matriz de comentarios está vacía en este momento. 338 00:26:31,340 --> 00:26:34,450 Entonces, después de publicar este plato, 339 00:26:34,450 --> 00:26:37,660 déjame copiar la identificación de este plato. 340 00:26:37,660 --> 00:26:40,835 Por lo tanto, permítanme copiar este ID para el plato porque 341 00:26:40,835 --> 00:26:44,735 necesitaré que para publicar comentarios para este plato. 342 00:26:44,735 --> 00:26:47,075 Luego, yendo a mi editor de texto, 343 00:26:47,075 --> 00:26:51,485 voy a guardar esa identificación del plato aquí. 344 00:26:51,485 --> 00:26:54,550 Ahora, por supuesto, una vez que construya su lado cliente, 345 00:26:54,550 --> 00:26:57,770 su cliente tendrá automáticamente toda esta información. 346 00:26:57,770 --> 00:27:02,565 Por lo tanto, su cliente podrá enviar automáticamente el token y así sucesivamente. 347 00:27:02,565 --> 00:27:06,385 Por lo tanto, no es necesario hacer esto de cortar y pegar, pero con el cartero, 348 00:27:06,385 --> 00:27:11,750 esta es la única forma en que podemos agregar cualquier información a nuestras solicitudes de cartero, 349 00:27:11,750 --> 00:27:17,185 que van del cartero al servidor. 350 00:27:17,185 --> 00:27:22,090 Ahora, con el fin de convencernos de que este plato realmente existe, 351 00:27:22,090 --> 00:27:26,310 permítanme obtener en el anfitrión local: 3000/platos. 352 00:27:26,570 --> 00:27:30,750 Cuando hago un get, en realidad se puede ver que 353 00:27:30,750 --> 00:27:34,175 este plato en particular existe en el lado del servidor. 354 00:27:34,175 --> 00:27:37,600 Por lo tanto, vamos a tratar de publicar un comentario. 355 00:27:37,600 --> 00:27:39,515 Entonces, para publicar un comentario, 356 00:27:39,515 --> 00:27:45,550 hagamos un post y diremos, 357 00:27:49,940 --> 00:27:54,950 localhost: 3000/platos, barra y la identificación del plato que 358 00:27:54,950 --> 00:27:59,910 acabo de copiar, y recortar comentarios. 359 00:27:59,910 --> 00:28:03,090 Cuando publique en los comentarios, 360 00:28:03,090 --> 00:28:11,285 debe asegurarse de que en el cuerpo agreguemos el comentario aquí. 361 00:28:11,285 --> 00:28:13,605 Por lo tanto, un comentario típico contiene 362 00:28:13,605 --> 00:28:20,555 una calificación de digamos 363 00:28:20,555 --> 00:28:26,140 cinco y luego comentario. 364 00:28:29,030 --> 00:28:33,535 Así que, déjame escribir algún comentario aleatorio, 365 00:28:33,535 --> 00:28:34,915 solo para demostrarte. 366 00:28:34,915 --> 00:28:41,085 Por lo tanto, esto debería estar en el cuerpo de la publicación para los comentarios y en el encabezado, 367 00:28:41,085 --> 00:28:44,665 deberíamos agregar el encabezado de autorización. 368 00:28:44,665 --> 00:28:50,525 Por lo tanto, para el encabezado de autorización, diremos, portador. 369 00:28:50,525 --> 00:28:54,875 Necesito pegar el token aquí, 370 00:28:54,875 --> 00:28:59,065 pegando el valor del token que he guardado anteriormente. 371 00:28:59,065 --> 00:29:02,575 Vamos a publicar este comentario. 372 00:29:02,575 --> 00:29:05,265 Luego, cuando se publique el comentario, 373 00:29:05,265 --> 00:29:07,705 veamos el valor devuelto aquí. 374 00:29:07,705 --> 00:29:09,510 Por lo tanto, a medida que navega hacia abajo, 375 00:29:09,510 --> 00:29:14,975 puede ver que el plato al que se ha agregado el comentario, ha sido devuelto. 376 00:29:14,975 --> 00:29:19,300 Tenga en cuenta que la información del plato está allí, pero tenga en cuenta en particular, 377 00:29:19,300 --> 00:29:22,620 lo que está contenido en el comentario que se ha publicado aquí. 378 00:29:22,620 --> 00:29:25,740 Entonces, como puede ver, ya sabe que los 379 00:29:25,740 --> 00:29:29,050 campos actualizados y creados en se agregan automáticamente por mangosta. 380 00:29:29,050 --> 00:29:31,900 La calificación y el comentario que enviamos están 381 00:29:31,900 --> 00:29:34,780 ahí, pero tenga en cuenta cómo el campo autor 382 00:29:34,780 --> 00:29:40,675 contiene ahora el ID correspondiente al usuario. 383 00:29:40,675 --> 00:29:47,190 Ahora, como vimos en el código cómo se agrega la información del campo de autor, ahora, 384 00:29:47,190 --> 00:29:49,965 si usted hace un get en los platos, 385 00:29:49,965 --> 00:29:52,900 se dará cuenta de que este campo de autor será 386 00:29:52,900 --> 00:29:56,890 rellenado automáticamente por la información de los usuarios aquí. 387 00:29:56,890 --> 00:30:02,180 Por lo tanto, vamos a hacer ahora un get en el localhost: 3000/platos. 388 00:30:02,300 --> 00:30:06,820 Por lo tanto, cuando ahora hacemos un conseguir en este punto, 389 00:30:06,820 --> 00:30:12,215 ahora se dará cuenta de que en los platos aquí, 390 00:30:12,215 --> 00:30:15,460 justo allí, la información sobre el plato ya está 391 00:30:15,460 --> 00:30:20,110 presente, pero tenga en cuenta cómo se construye el comentario. 392 00:30:20,110 --> 00:30:23,500 El comentario ahora contiene, 393 00:30:23,500 --> 00:30:27,240 los campos de comentarios de calificación como vimos anteriormente, 394 00:30:27,240 --> 00:30:28,780 el actualizado y creado en, 395 00:30:28,780 --> 00:30:32,910 pero tenga en cuenta lo que pasó con el campo de autor aquí. 396 00:30:32,910 --> 00:30:36,890 Por lo tanto, cuando hace una solicitud get porque hicimos un relleno en 397 00:30:36,890 --> 00:30:42,230 el lado del servidor cuando se invoca la operación get, 398 00:30:42,230 --> 00:30:45,750 el poblado ha rellenado automáticamente la 399 00:30:45,750 --> 00:30:51,390 información del autor en su posición en el campo de autor aquí. 400 00:30:51,390 --> 00:30:54,215 Así que, allí, puede ver que desde el autor, 401 00:30:54,215 --> 00:30:56,260 ahora puede buscar 402 00:30:56,260 --> 00:30:58,970 automáticamente el apellido y la información del nombre desde el campo de autor. 403 00:30:58,970 --> 00:31:01,645 Por lo tanto, si necesita construir un comentario, 404 00:31:01,645 --> 00:31:04,050 ahora tiene la calificación, 405 00:31:04,050 --> 00:31:08,210 el comentario y también el nombre y apellidos 406 00:31:08,210 --> 00:31:12,485 del autor incluidos automáticamente en este documento. 407 00:31:12,485 --> 00:31:15,645 Además, el nombre de usuario también se incluye en este documento. 408 00:31:15,645 --> 00:31:21,495 Por lo tanto, así es como puede agregar información de otro documento y rellenar 409 00:31:21,495 --> 00:31:27,905 un segundo documento con esa información antes de responder desde el sitio del servidor. 410 00:31:27,905 --> 00:31:32,315 Por lo tanto, este es el uso de la población de mangosta y cómo 411 00:31:32,315 --> 00:31:37,580 podemos llenar automáticamente la información en un documento de mangosta. 412 00:31:37,580 --> 00:31:41,280 Con esto, completamos este ejercicio. 413 00:31:41,280 --> 00:31:46,075 En este ejercicio, hemos visto el uso de la población de mangosta y también hemos visto 414 00:31:46,075 --> 00:31:51,785 cómo podemos rellenar la información de un documento a otro documento. Por lo 415 00:31:51,785 --> 00:31:57,340 cual, cuando modificamos el servidor para hacer la población para las solicitudes, 416 00:31:57,340 --> 00:32:02,200 mangosta se encargará automáticamente de rellenar esta información para nosotros. 417 00:32:02,200 --> 00:32:04,190 Todo lo que tenemos que hacer, 418 00:32:04,190 --> 00:32:10,900 es almacenar la referencia al otro documento en forma de ID de objeto, 419 00:32:10,900 --> 00:32:16,240 en el documento en el que desea rellenar esta información. 420 00:32:16,240 --> 00:32:18,965 Con esto, completamos este ejercicio. 421 00:32:18,965 --> 00:32:25,230 Este es un buen momento para que hagas un git-commit con el mensaje, población de mangosta.