Pero, estábamos un poco atrapados allí, porque nuestros componentes de React dependían de las consultas de GraphQL. Como puedes ver en nuestro componente Pokemon sensors. ¿Qué deberíamos haber hecho en su lugar? Bueno, hoy en día tendemos a crear clientes que abstraen nuestro trabajo con la API. Esto nos da más flexibilidad en cómo nos comunicamos con el back end. Así que, por ejemplo, para este ejemplo, el cliente de Pokemon con la función get Pokemon, y ahí está mi consulta en él. Pero, en mi componente, puedo hacerlo de la manera que quiera. Podría usar el use hook para obtener la información con un suspense. Si quiero la misma funcionalidad que el use query de Apollo, por ejemplo, podría usar React query de 10 stack, que solo maneja la gestión. No tiene nada que ver con la API. Si decido que quiero usar esta llamada de API en un componente de servidor, podría simplemente llamar al get Pokemon en el mismo componente, en un componente de servidor de React. También podría usarlo en una aplicación React native, porque mi API es independiente de la UI. Hay muchas piezas de código que se pueden extraer de los componentes de React, y esta es la primera.
La segunda que puedo darte, este es el último paso de hoy, es la lógica de negocio. Esta lógica corresponde a toda la lógica de negocio de tu producto, el tipo de lógica que puedes discutir con alguien que no es programador. Alguien que no conoce React, bueno, es la lógica que gira en torno al modelo de negocio de tu producto. Por ejemplo, digamos que decides hacer un sitio web de compras donde tienes un carrito, puedes añadir artículos a tu carrito, y puedes finalizar la compra y comprar todo. Bueno, el carrito de compras tendrá lógica asociada a él. Por ejemplo, no puedes tener menos uno artículo en tu carrito. Eso simplemente no es posible. Para cada artículo, solo puedes tener una cantidad positiva. Cuando abres este sitio web, el carrito debería estar inicialmente vacío. Si la cantidad de artículos cambia a cero, podría querer eliminar el artículo del carrito. Toda esta lógica se puede implementar sin la UI. Esto es pura lógica de negocio. Cuando la lógica podría ser exactamente la misma en una aplicación de una sola página, renderizado del lado del servidor, en un backend de express, en una aplicación React Native, entonces no debería estar en un componente o un hook. Debería ser extraída. Así que, además, al extraerla, puedes nombrar todo este comportamiento, y puedes incluso facilitar las pruebas automatizadas. ¿Cómo se vería como código en un componente? Podrías crear una simple clase de JavaScript que represente tu carrito con todos estos métodos que representan cómo puedes manipular el carrito. En este ejemplo, puedes actualizar la cantidad de artículos, puedes eliminar un artículo, puedes contar la cantidad total de artículos, e incluso tenemos un método para crear un carrito vacío. Luego, en tu componente, bueno, tendrás toda la lógica de UI, la lógica de estado de la aplicación.
Comments