Estructura de Carpetas en Angular 🔥

· 6 min de lectura
Estructura de Carpetas en Angular 🔥

La estructura de carpetas, se convierte en el arte de organizar tus aplicaciones Angular.

Se puede tener la práctica de solo seguir la estructura básica en Angular CLI, sin embargo, ¿Es suficiente?  En ocasiones esta estructura básica es dolorosa especialmente cuando tu proyecto comienza a administrar muchos módulos.

Es por ello que al momento de iniciar tu proyecto en angular es de vital importancia estructurar las carpetas para que sean escalables, teniendo ello como finalidad una mejor organización del código

Definir una estructura de carpetas altamente escalable para tus proyectos Angular, requiere de sugerencias prácticas, son tantas las circunstancias que se pueden evitar trabajando bajo una estructura de carpetas.

¿Qué sucede si necesito crear una aplicación con más de 15 módulos, 50 componentes y múltiples widgets compartidos o componentes?

Además nuestra aplicación podría aumentar las características principales y debemos mantenerla durante un largo período de tiempo. En Angular, todo está organizado en módulos y cada aplicación tiene al menos uno de ellos, por ejemplo el módulo raíz de la aplicación.

El módulo de la aplicación es el punto de entrada de la aplicación y es el módulo que Angular usa para iniciar la aplicación, por lo que debemos crear nuestra aplicación Angular basada en 3 módulos (módulos centrales, compartidos y de funciones)

Redux como patrón de datos resuelve toda la arquitectura y manejo de datos en un solo sentido. Lo que hacemos con redux es manejar un solo flujo de información donde uno de sus principios es que tiene una sola fuente de la verdad la cual llama storage, donde siempre va a estar disponible la data, permitiendo obtener un mayor control sobre el flujo de datos y el estado de la aplicación con un estado global inmutable.

El proyecto sigue de cerca la estructura de Folders by features (carpetas por característica de la aplicación) de la guía de estilo angular, lo que permite a su vez el desarrollo de una aplicación modularizada.

via GIPHY

CORE MODULO

El Core Module es responsable de mantener los servicios globales. Lo más probable es que estos servicios sean servicios HTTP para comunicarse con una API.

También se utiliza para almacenar guards, modelos y otras dependencias globales, como el interceptor http y el controlador de errores global. Para mantener una base de código bien estructurada y escrita, vamos a agrupar entidades typescript en su propia carpeta dentro del core module (clases, enums, interfaces).

Core Module asume el rol del AppModule raíz, pero no es el módulo que Angular arranca en tiempo de ejecución.

El CoreModule debe contener servicios singleton (que suele ser el caso), componentes universales y otras características en las que solo hay una instancia por aplicación.
  1. Guards: son servicios especiales que ayudan a otorgar o revocar el acceso a las rutas.
  2. Interceptores: ayudan a interceptar o modificar solicitudes y respuestas.
  3. Modelos: deberíamos poner modelos generales en módulos.
  4. Servicios: servicios básicos en todos los módulos
  5. Utilidades: funciones o ayudantes comunes.
  6. Componentes: contendrá los componentes que son comunes en toda la aplicación, como encabezado, barra de navegación y pie de página.

El Core Module agrupa “componentes” que si y sólo si se van a compartir a través de toda la aplicación pero generando una referencia única. (Es la única diferencia con el Shared Módulo).

El Shared módulo debe ser importado, en cambio el Core Module por defecto va a estar en todos los módulos, sirve para guardar servicios que tengan una sola referencia de los datos.

Root Module

El AppModule es punto de entrada de la aplicación y tiene las siguientes responsabilidades (Por convención y por defecto, este NgModule se llama AppModule):

  1. Arranque de la aplicación con el AppComponent.
  2. Importa dependencias globales como BrowserModule, CoreModule y LoggerModule.
  3. Configura el enrutamiento para toda la aplicación, permitiendo la carga diferida para los módulos de características.

SharedModule

Es donde deben ir los componentes, tuberías / filtros y servicios compartidos. El SharedModule se puede importar en cualquier otro módulo cuando esos elementos se vuelvan a reutilizar. El módulo compartido no debería depender del resto de la aplicación y, por lo tanto, no debería depender de ningún otro módulo.

Si llegados a esté punto te interesa aprender de manera más rápida, dinámica y sencilla te invito a ver el video que te dejo

¿Cómo saber si algunos componentes deben ir en un módulo compartido o carpeta compartida?

La respuesta es simple, solo tenga en cuenta que los módulos compartidos deben tener componentes en todos los módulos, pero si su componente se usa en un módulo, simplemente cree una carpeta compartida y colóquela en un solo módulo.

El Shared Module contiene código que se usará en todos los módulos de features, se utiliza solo para mantener componentes, pipes y directivas comunes en toda la aplicación.

Feature Module

A medida que la aplicación crezca, deberá considerar la posibilidad de subdividirla en varios módulos de funciones, algunos de los cuales pueden cargarse de forma diferida. Estos módulos solo deben depender del SharedModule, y su funcionalidad debe estar limitada al módulo.

Definir módulos de funciones probablemente no sea fácil, pero podría ayudar si supiera mucho sobre su negocio. Antes de crear módulos de funciones, debe hablar con el propietario del producto o los clientes para obtener más información sobre su aplicación.

Los módulos de features se utilizan para organizar cada feature distinta de una aplicación.

Un Feature Module no exporta nada excepto el componente superior, por lo que todo lo que definimos dentro de él no se utilizará en ningún otro lado.
Siguiendo el patrón Smart and Dumb components, cada módulo debe tener un directorio de components (Contiene componentes Dumb) y un directorio containers (Contiene Smart Components).

Dumb Component


Un Dumb Component define un componente que no tiene muchos estados, no tiene acceso a los servicios, no almacena datos en un backend. Lo que realmente hace es mantener el enfoque del componente en la presentación, encargándose de renderizar las vistas usando inputs y outputs.

También podemos llamarlos componentes aislados.

Smart Component


Un Smart Component contiene estados, servicios de implementación o cualquier tipo de lógica de negocios que ocurra en ese componente.

No se centra en la presentación, sino en lo que sucede en el componente. Luego, simplemente emite las propiedades a Dumb Component las cuales son recibidas por el decorador @Input. (Se encargan de obtener datos).

Routing


AppModule habilita rutas cargadas de manera diferida para presentar módulos (lazy-loading), lo que significa que el módulo no se carga antes de que el usuario acceda a la ruta.
Esto permite que cada módulo de feature tenga su propia configuración de enrutamiento, que mantiene las rutas en los módulos de features correspondientes. (Esto está dentro del Root Module)

Folder Layout


La carpeta de Layout es un contenedor de componentes que se declaran en el AppModule. Este directorio contiene componentes de contenido a nivel de página, como footer, navegación y headers comunes. (Esto está dentro del Root Module)

Folder Styles


El directorio ~/src/styles se utiliza para almacenar hojas de estilo scss para la aplicación. Puede contener temas, Bootstrap, material angular y cualquier otro estilo.

El directorio ~/src/styles/themes debe contener los temas de toda la aplicación. Ejem: Un aplicación puede incluir dos archivos de tema, black-theme.scss y light-theme.scss. (Esto está dentro del Root Module)


Folder Store (Administración del Estado)


El directorio ~/src/store se utiliza para manejar el estado de la aplicación aplicando el patrón redux que actúa como un contenedor del estado global de nuestra aplicación. Almacena toda la información en un sólo lugar, la cual es representada bajo un objeto JavaScript accesible en todo momento.

Es conveniente crear módulos para cada feature de la aplicación en este directorio, en los cuales se crearán las configuraciones de manejo de estado propias del patrón redux (State, Action, Reducer, Effect).

Cada módulo de feature deberá importar su módulo de manejo de estado correspondiente.

Es probable que para proyectos pequeños la estructura de carpetas generadas por el Angular CLI sea suficiente (components, services, pipes…), sin embargo, cuando el proyecto se torna grande, la estructura de carpetas debe ser escalable, así evitar desorganización y hacer mas fácil las tareas de incluir y mejorar funcionalidades.

No hay una regla general a la hora de crear una estructura de carpetas en Angular, sobre todo en proyectos grandes.

La estructura cambiará mucho según las características del proyecto . La idea general en este artículo es mantener un aplicación ordenada, consistente y que en la medida de lo posible se explique por sí sola.

Fuente

Referencia

Quiero más

Por supuesto! gracias al apoyo que se ha conseguido por todos ustedes (comentando, suscribiéndote y compartiendo) se agregaron nuevos videos, en esta ocasión iniciamos el curso de testing en angular, curso de node, curso mongo y mucho más

Artículos Relacionados

Sin Junior no hay Senior ¿Cómo podemos ayudar?
· 3 min de lectura
Paquete npm single-spa
· 16 min de lectura
Server Side Render para Angular
· 5 min de lectura
Angular y Nest, una combinación perfecta
· 7 min de lectura