1 00:00:02,250 --> 00:00:07,800 Así que ahora, para terminar este módulo, quiero asegurarme de que también guardamos los pedidos en un servidor 2 00:00:07,800 --> 00:00:10,530 y, por supuesto, también los recuperamos desde allí. 3 00:00:10,540 --> 00:00:16,810 Ahora tenemos el creador de acciones de órdenes aquí y allá, podemos aprovechar nuevamente Redux Thunk y devolver nuestra 4 00:00:16,810 --> 00:00:22,780 función aquí, que obtiene esa función de envío, que debe ser asíncrona con la palabra clave asíncrona para 5 00:00:22,810 --> 00:00:25,280 que podamos usar async wait y en 6 00:00:25,570 --> 00:00:32,110 esa función aquí que devolvemos, finalmente, por supuesto, enviaré mi objeto de acción, pero antes de hacerlo, ahora podemos enviar 7 00:00:32,110 --> 00:00:38,320 una solicitud para almacenar ese pedido en un servidor y podemos pedir prestada esa solicitud al creador de 8 00:00:38,320 --> 00:00:41,650 la acción de productos. Realmente no hay una 9 00:00:41,710 --> 00:00:46,930 gran diferencia si creamos un producto o ese pedido, por lo que podemos copiar todo este 10 00:00:46,930 --> 00:00:59,170 código de creación de producto aquí hasta aquí y pasarlo a los pedidos. archivo js. 11 00:00:59,180 --> 00:01:00,450 Ahora, por supuesto, también puede 12 00:01:00,470 --> 00:01:05,530 agregar el manejo de errores aquí, no lo tengo aquí, una cosa que quiero agregar al menos es que 13 00:01:05,540 --> 00:01:07,880 no recibo un cheque si la respuesta no está 14 00:01:07,880 --> 00:01:13,130 bien, en cuyo caso quiero para lanzar un nuevo error, algo salió mal, pero ese no debería ser el foco 15 00:01:13,130 --> 00:01:14,500 aquí porque cubrimos el manejo 16 00:01:14,510 --> 00:01:16,410 de errores y la carga de hilanderos, 17 00:01:16,440 --> 00:01:20,420 no realmente la parte en la que quiero centrarme aquí, en cambio, asegurémonos de enviar 18 00:01:20,450 --> 00:01:21,080 esta 19 00:01:21,110 --> 00:01:25,150 solicitud al dirección correcta y ese no debería ser el nodo de productos, pero supongamos 20 00:01:25,520 --> 00:01:32,260 que el nodo de pedidos tiene sentido, supongo porque queremos almacenar nuestros pedidos. Tal vez también queramos almacenar nuestros pedidos específicos para ese usuario para poder almacenarlos en 21 00:01:32,260 --> 00:01:38,740 / orders / U1, que es mi ID de usuario ficticio, supongo aquí. Más tarde, eso será diferente, más adelante 22 00:01:38,740 --> 00:01:42,040 tendremos una ID real aquí, una ID dinámica, por 23 00:01:42,040 --> 00:01:48,350 ahora simplemente codifiquemos esto aquí para que tengamos una subcarpeta, una subcarpeta por usuario más adelante. 24 00:01:48,610 --> 00:01:53,980 Debería ser una solicitud posterior porque estamos agregando, agregamos algunos datos nuevos, estamos agregando un nuevo pedido. 25 00:01:53,980 --> 00:01:55,360 Este encabezado debe configurarse y, por 26 00:01:55,360 --> 00:01:58,170 supuesto, los datos que enviamos son diferentes. Ahí quiero enviar 27 00:01:58,210 --> 00:02:05,020 los artículos de mi tarjeta y el monto total y otra cosa importante, la fecha del pedido. 28 00:02:05,890 --> 00:02:12,820 Quiero enviar mi fecha aquí convertida en una cadena con toISOString en el objeto de fecha para que creamos esto localmente 29 00:02:12,820 --> 00:02:17,530 en la aplicación y luego guardemos la marca de tiempo en el servidor. 30 00:02:17,530 --> 00:02:22,180 Ahora en su aplicación, es posible que también desee crear esa fecha en el servidor, pero como este 31 00:02:22,180 --> 00:02:27,100 curso no debe centrarse en la programación del lado del servidor, lo haremos aquí y lo enviaremos al servidor sin 32 00:02:27,100 --> 00:02:29,450 preocuparnos demasiado por qué más podría hacer un servidor 33 00:02:29,530 --> 00:02:34,500 por nosotros, en su lugar hagamos todas las cosas aquí y simplemente enviemos esa marca de tiempo terminada al servidor. 34 00:02:34,570 --> 00:02:40,300 Ahora, esto agregará un pedido aquí y una vez que hayamos terminado, recuperaremos nuestros datos de 35 00:02:40,330 --> 00:02:46,090 respuesta que incluirán esa ID generada automáticamente, si recuerdas, también lo hicimos en la creación del producto. 36 00:02:46,090 --> 00:02:51,820 Por lo tanto, ahora cuando agregamos un pedido, por supuesto reenviamos nuestros artículos y la cantidad, pero ahora también quiero 37 00:02:51,820 --> 00:02:55,990 reenviar el ID que obtengo de resData. nombre, esa es la misma 38 00:02:56,170 --> 00:03:02,710 lógica que usamos cuando creamos un producto y hay una cosa adicional, mi instantánea de la fecha, por supuesto, debería 39 00:03:02,710 --> 00:03:05,040 ser la misma que se creó aquí. 40 00:03:05,050 --> 00:03:14,010 Entonces, lo que haré es crear mi instantánea aquí, fechar con una nueva fecha y luego usar esta constante aquí para crear mi 41 00:03:14,010 --> 00:03:20,840 versión de cadena y usar la misma constante aquí para reenviarla con los datos de mi pedido. 42 00:03:20,850 --> 00:03:23,730 Entonces, la fecha se refiere a esta constante de fecha, 43 00:03:23,730 --> 00:03:29,400 de modo que uso una misma marca de tiempo, tanto localmente en mis datos administrados con Redux, que son los datos 44 00:03:29,400 --> 00:03:35,670 con los que trabajo aquí en esta aplicación en ejecución y, por supuesto, también tengo la misma marca de tiempo en el servidor cuál 45 00:03:35,670 --> 00:03:41,880 es la información que cargaré en el futuro u otros dispositivos cargarán. Y ahora solo tenemos que trabajar 46 00:03:41,900 --> 00:03:45,500 en el reductor de pedidos para agregar pedidos. 47 00:03:45,500 --> 00:03:48,450 La identificación ahora es algo que obtengo de 48 00:03:48,470 --> 00:03:52,910 afuera, así que aquí tengo orderData. Id porque eso es lo que 49 00:03:52,940 --> 00:03:58,700 estamos reenviando aquí, es que la ID generada automáticamente por Firebase nos da y la fecha 50 00:03:58,910 --> 00:04:06,100 también se recibe desde afuera, aquí ahora podemos usar orderData. fecha como esta y con eso, tenemos toda la lógica para 51 00:04:06,250 --> 00:04:07,600 agregar un pedido. 52 00:04:07,630 --> 00:04:14,710 Ahora volvamos aquí y agreguemos esto al carrito y haga clic en ordenar ahora, parece que funciona, si regresamos ahora vemos un 53 00:04:14,740 --> 00:04:20,890 nodo de pedidos aquí en Firebase con una subcarpeta U1 para nuestro usuario con la ID única generada y 54 00:04:20,890 --> 00:04:27,400 allí, los datos del pedido con la marca de tiempo con el precio, con los artículos de la tarjeta, que era 55 00:04:27,400 --> 00:04:31,570 esta camisa blanca y que no se ve tan mal, diría yo.