Angular // Estructura de carpetas
En este blog explicare detalladamente como se estructura y se crea el cuerpo de un proyecto angular, el objetivo no es definir una solución estándar ya que no la hay, sino, apoyar con un granito de arena a la solución final que se pueda dar en algún futuro cercano, este ejemplo esta basado en un proyecto angular básico, si quieres visitar el blog que hice en donde explico como hacer tu primer HOLA MUNDO, puedes pinchar aquí y me cuentas como te fue.
Gracias a la interfaz de comandos de Angular llamada ANGULAR CLI podemos crear componentes, servicios, módulos de forma fácil, rápida y eficiente, en la cual podemos modelar nuestro proyecto a nuestro gusto.
Acá te dejo algunos comandos de tipo @schematics que ANGULAR CLI maneja en su core para poder hacerte la vida mucho mas fácil.
1- ng generate ->
app-shell
application
class
component
directive
enum
guard
interceptor
interface
library
module
pipe
resolver
service
service-worker
web-worker
2- ng new
3- ng serve
4- ng build
5- ng test
6- ng lint
7- ng e2eA continuación te mostraré la estructura de carpetas que usualmente uso en mis proyectos angular.
Personalmente defino la división y estructura de mis proyectos dependiendo de la complejidad, el tamaño y la cantidad de componentes que va a contener. Esto tienes que definirlo antes, al momento de armar la solución a la necesidad de tu cliente.
Como se puede apreciar dentro de la carpeta APP podemos ver 4 sub-carpetas que están al mismo nivel:
AUTH: Esta carpeta contendrá todo lo relacionado a la autenticación de usuarios, componentes de tipo login, resetear contraseñas, recuperar contraseñas, etc. La idea es separar lógicas y tener bien dividida las tareas de cada uno.
Dentro de ella tenemos las siguientes subcarpetas:
class: Acá irán todos los archivos de tipo clase que podrás ocupar dentro de la carpeta AUTH, la cual te ayudarán a encapsular lógicas para luego poder ocuparlas, estos archivos deben tener estricta relación a la carpeta padre, en este caso AUTH.
components: Acá irán todos los componentes que tengan estricta relación a la carpeta padre, en este caso AUTH.
helpers: Acá irán todos los servicios en donde solo deben contener funciones estáticas o variables para su uso puntual dentro de la SPA, estos archivos deben tener estricta relación a la carpeta padre, en este caso AUTH.
models: Acá irán todos las interfaces que tengan relación solo a la carpeta padre, en este caso AUTH
pipes: Acá irán todos pipes que serán utilizadas dentro de la carpeta padre, en este caso AUTH, recordemos que los pipes permiten transformar visualmente la información dentro del DOM.
services: Acá irán todas las clases de tipo service que encapsularán la lógica de modelos de datos, el formato de datos y las peticiones al servicios, estos serán inyectables en los componentes relacionados a la carpeta padre, en este caso AUTH.
CORE: Esta carpeta contendrá todo lo relacionado a cosas transversales que podrás ocupar dentro del proyecto. La idea es separar lógicas y tener bien dividida las tareas de cada uno.
Dentro de ella tenemos las siguientes subcarpetas:
interceptors: Acá irán todas las clases de tipo interceptor que podrás utilizar para modificar las peticiones que salen o vienen a nuestra aplicación.
services: Acá irán todas las clases de tipo service que encapsularán la lógica de modelos de datos, el formato de datos y las peticiones al servicios, estos serán inyectables en los componentes relacionados a la carpeta padre, en este caso CORE.
SHARED: Esta carpeta contendrá todo lo relacionado a cosas que se usaran de forma global y serán reutilizadas y compartidas dentro de la app. La idea es separar lógicas y tener bien dividida las tareas de cada uno.
Dentro de ella tenemos las siguientes subcarpetas:
class: Acá irán todos los archivos de tipo clase que podrás ocupar dentro de la carpeta SHARED, la cual te ayudarán a encapsular lógicas para luego poder ocuparlas, estos archivos deben tener estricta relación a la carpeta padre, en este caso SHARED.
components: Acá irán todos los componentes que tengan estricta relación a la carpeta padre, en este caso SHARED.
helpers: Acá irán todos los servicios en donde solo deben contener funciones estáticas o variables para su uso puntual dentro de la SPA, estos archivos deben tener estricta relación a la carpeta padre, en este caso SHARED.
models: Acá irán todos las interfaces que tengan relación solo a la carpeta padre, en este caso SHARED
pipes: Acá irán todos pipes que serán utilizadas dentro de la carpeta padre, en este caso SHARED, recordemos que los pipes permiten transformar visualmente la información dentro del DOM.
services: Acá irán todas las clases de tipo service que encapsularán la lógica de modelos de datos, el formato de datos y las peticiones al servicios, estos serán inyectables en los componentes relacionados a la carpeta padre, en este caso SHARED.
VIEWS: Esta carpeta contendrá todo lo relacionado a componentes de tipo vistas. La idea es separar lógicas y tener bien dividida las tareas de cada uno.
Dentro de ella tenemos las siguientes subcarpetas:
class: Acá irán todos los archivos de tipo clase que podrás ocupar dentro de la carpeta VIEWS, la cual te ayudarán a encapsular lógicas para luego poder ocuparlas, estos archivos deben tener estricta relación a la carpeta padre, en este caso VIEWS.
components: Acá irán todos los componentes que tengan estricta relación a la carpeta padre, en este caso VIEWS.
helpers: Acá irán todos los servicios en donde solo deben contener funciones estáticas o variables para su uso puntual dentro de la SPA, estos archivos deben tener estricta relación a la carpeta padre, en este caso VIEWS.
models: Acá irán todos las interfaces que tengan relación solo a la carpeta padre, en este caso VIEWS
pipes: Acá irán todos pipes que serán utilizadas dentro de la carpeta padre, en este caso VIEWS, recordemos que los pipes permiten transformar visualmente la información dentro del DOM.
services: Acá irán todas las clases de tipo service que encapsularán la lógica de modelos de datos, el formato de datos y las peticiones al servicios, estos serán inyectables en los componentes relacionados a la carpeta padre, en este caso VIEWS.
Cabe resaltar que dividiendo de esta manera los módulos beneficiará la carga de los componentes y estos podrán cargarse en el browser mucho mas rápido, claro esto también ayuda al LAZY LOADING al momento de mostrar el contenido en pantalla.
También es importante mencionar la estructura de un componente, acá tienes 2 opciones que debes manejar: componentes ruteables y componentes no ruteables.
RUTEABLES: Si deduces que estos componentes deben ser ruteables, o sea, llamados desde otro componente, inmediatamente tienes que pensar que deben tener su propio routing y su propio modulo cargando así sus propias dependencias, quedando de la siguiente manera.
El archivo routing te ayudara a que los componentes tengan su propio alias al momento de renombrar su ruta, también te ayudara a manejar de mejor manera la carga de tu SPA.
NO RUTEABLES: Este caso se da siempre cuando es un componente de tipo CHILDREN ósea un componente HIJO, Si deduces que estos componentes no serán ruteables y son children, o sea, no serán llamados desde otro componente sino cargados de forma asyncrona por el componente padre, inmediatamente tienes que pensar que no deben tener su propio routing ni su propio modulo, ya que estos módulos serán importados desde el modulo del padre, quedando de la siguiente manera.
Muchas gracias por llegar hasta acá y muy agradecido que le pongas “CLAPS” a mis publicaciones, y claro se agradecen todos los feedback posibles, así podre ayudar a los demás de la mejor manera posible.
