En este artículo, exploraremos un enfoque modular sencillo y directo. El concepto central de esta arquitectura es separar claramente los módulos de la aplicación.
Aunque este enfoque parece fácil de entender, puede ser muy beneficioso. Te dará algunos conocimientos básicos sobre arquitecturas modulares y te preparará para temas más avanzados que vendrán en un futuro próximo. Empecemos.
Visión general de la arquitectura
Aunque este enfoque no es avanzado ni complejo, puede considerarse un tipo de arquitectura. Definitivamente te ayudará a organizar mejor tu proyecto con la ayuda de módulos y principios de declaración de API públicas.
Empecemos a explorar este enfoque examinando sus componentes. En la mayoría de los casos, consta de sólo cuatro partes: páginas, módulos, componentes y UI.
- UI el directorio para los componentes de UI, como botones, selectores y entradas components. El directorio para piezas de código menos independientes. Un buen ejemplo de ello puede ser
ProductCard. Sin embargo, los elementos en ese directorio no deben tener ninguna lógica de negocio específica, ya que deben permanecer altamente reutilizables - Modules el directorio para módulos independientes de tu aplicación.
- SignInForm: Es un claro ejemplo de módulo aislado con su propia lógica y objetivos.
- Pages: El directorio que contiene las rutas de la aplicación.
Ahora vamos a profundizar en cada uno de estos componentes.
Ahora vamos a intentar comprender en profundidad cada una de estas partes.
IU
La interfaz de usuario sólo debe constar de componentes altamente reutilizables (ui-kit del proyecto). En esencia, es la columna vertebral del proyecto.
Forma la base sobre la que se construyen otras capas y no debe contener ninguna forma de lógica de negocio. De lo contrario, el uso de componentes de ese módulo será difícil y poco fiable.
Tenga en cuenta que está prohibido importar entidades de otras capas.
Componentes
Todos los elementos de este directorio están compuestos por varios componentes de interfaz de usuario. Aunque pueden contener alguna lógica de negocio básica, se recomienda mantenerlos lo más simples posible. Piense en ello como una abstracción de alto nivel de la interfaz de usuario.
Tenga en cuenta que está prohibido importar entidades de las capas de módulos y páginas.
Módulos
Las entidades de este directorio deben ser altamente independientes y tener su propia zona de responsabilidad. Todas las funcionalidades necesarias, como funciones de ayuda, almacenes, constantes e interacciones API, deben declararse y utilizarse dentro del módulo.
Esto ayuda a evitar que las funcionalidades se dispersen por todo el proyecto y facilita el mantenimiento. Así mantenemos las cosas muy coherentes y desacopladas, que es nuestro objetivo global.
Un momento importante Cada módulo debe tener un archivo index.js donde se declaran las exportaciones para uso externo (conocidas como "API pública"). El objetivo principal de este archivo es aislar las partes internas del módulo. Esto ayuda a establecer conexiones claras y evitar el acoplamiento caótico.
Ten en cuenta que está prohibido importar entidades de otros módulos y páginas.
Páginas
En esencia, cada elemento del directorio pages es una combinación de diferentes módulos. Las páginas también pueden dividirse en subdirectorios más pequeños. La diferencia clave entre páginas y módulos es el grosor lógico.
Las páginas también pueden dividirse en subdirectorios más pequeños. La principal diferencia entre páginas y módulos es la cantidad de lógica de negocio que contienen.
Las páginas deben mantenerse al mínimo y toda la lógica de negocio debe ser colocada en módulos, para ser utilizada a nivel de página.
Ventajas e inconvenientes de la arquitectura Frontend
Como todas las demás arquitecturas, el Enfoque Modular Simple tiene sus propias ventajas e inconvenientes.
Ventajas:
- Aislamiento de la funcionalidad de los módulos con el concepto de "API pública".
- Flujo de datos unidireccional claro
(páginas => módulos => componentes => UI) - Alta reutilización gracias a la separación de capas
- Mantenimiento mejorado y capacidad de refactorización más sencilla
- Alta cohesión dentro de los módulos y bajo acoplamiento entre ellos.
Desventajas
- Determinar a dónde pertenece una entidad (módulos vs componentes) puede ser un reto
- ¿Qué hacer si necesitamos un módulo dentro de otro?
- No hay lugar para colocar los componentes de negocio
- Acoplamiento poco claro con estados globales y helpers
Como referencia, el "Enfoque clásico" se trató anteriormente en este artículo.
Arquitecturas Frontend: Enfoque "Clásico" (Sin Arquitectura)
Conoce los pros y los contras de la arquitectura frontend más común. javascript.plainenglish.io
En general, este enfoque es mucho mejor que el "Clásico". Ya que proporciona una estructura más fiable. Las ventajas son bastante claras
Navegación más rápida en el proyecto (más fácil de encontrar componentes, funciones y entre otros).
Podemos concluir con que una buena arquitectura de frontend deriva en:
Estructura comprensible y fácil de seguir- Menor acoplamiento y mayor cohesión en el sistema
- Mejor mantenimiento y escalabilidad
- Entrega más rápida de funciones gracias a la mejora significativa de la experiencia de los desarrolladores.
Un equipo más grande de desarrolladores puede trabajar con este enfoque
Aunque este enfoque tiene algunas ventajas obvias, sigue sin ser adecuado para proyectos grandes y complejos. Cuando hay un montón de características y lógica de negocio, se hace bastante difícil mantenerlo con esta arquitectura.
