Estructura FrontEnd

Los template de FrontEnd que actualmente se utilizan cuentan con una arquitectura diseñada especificamente para desacoplar responsabilidades en la comunicación con APIs. El flujo comienza en el llamado a un Hook dentro de un componente dado el cual esta dedicado a una única entidad, conteniendo todas las posibles acciones que se podrían necesitar de ésta, por ejemplo un CRUD, de esta manera diferentes componentes que utilicen la misma entidad podran reutilizar el hook. Éste, llama internamente a las asyncActions las cuales se encargan de conectar con los usesCases y mantener actualizado nuestro store. Los usesCases son los encargados de comunicarse con los services para obtener la respuesta de la API y manipular la respuesta mediante Adapters según la necesidad del componente de vista.

Este es el flujo que tenemos en los templates, sin embargo, no todos los proyectos frontEnd manejan el mismo nivel de complejidad por lo que es considerable que no siempre sea el mejor camino a seguir.

Para saber cual es el mejor camino según las necesidades de tu proyecto, establecimos algunas recomendaciones de acuerdo al nivel de complejidad que éste maneje.

Level 1

Es recomendado en proyectos pequeños, que no tienen gran cantidad de funcionalidades. No necesitan adaptar las respuestas de la API y una entidad contiene las acciones básicas: create, update, read, delete, getAll, etc. En este caso, donde el hook no posee tanta carga y no es necesario adaptar entidades, se deberia eliminar la capa de usesCases, simplificando el flujo de comunicación permitiendo que los actores principales sean:
component → hook → asyncActions → services.

Ejemplo de Diseño:

Estructura de carpetas:

Level 2

Este caso es base ya que es el que trae el template por defecto. Se debe utilizar cuando la API no brinda la respuesta acorde a tus necesidades y debas manipular los datos para adaptarlos. Para este fin es necesario hacer uso de la capa usesCase, siendo los actores principales en la comunicación:
component → hook → asyncActions → usesCases → services.

Ejemplo de Diseño:

Estructura de carpetas:

Level 3

Es recomendado en proyectos grandes, donde muchos componentes necesiten implementar las mismas entidades de manera diferentes. En este caso lo ideal seria separar las responsabilidades en módulos mas grandes, de manera que podemos agrupar componentes, hooks, actions en features específicos. En este caso, los hooks dejarian de estar dedicados a entidades y se adaptarian únicamente a la necesidad del feature.

Ejemplo de Diseño:

Estructura de carpetas:

## Level 4

Para casos extremos, con features mas grandes es preferible modularizar mas aún. Considerando que tambien necesitemos la utilización de adapters, se agregaria la capa de usesCase por cada feature y nuestro diseño quedaria asi:

y su estructura de carpeta es la siguiente:

Aclaración importante

Tener en cuenta que tanto la estructura de carpetas como en los diseños que se muestran, son ejemplos de los actores principales en la comunicación con APIs, sin embargo podría considerarse en los Level 3 y Level 4 tener carpetas o archivos extras como types, styles, interfaces pertenecientes al feature específico.

A la hora de crear un nuevo proyecto es importante tener en claro la magnitud del mismo, y considerar el nivel de complejidad que maneja para poder aplicar la estructura que mejor se adapte teniendo en cuenta estas recomendaciones.