DEV Community: Gerson Umanzor

Como estructurar aplicaciones en Angular

Gerson Umanzor — Mon, 02 May 2022 21:29:20 +0000

Cuando se trata de estructurar aplicaciones, podemos pensar que no es necesario tener un orden definido, pero a medida el desarrollo crece, el equipo cambia y nuevos requerimientos son añadidos, se hace mas necesario tener consistencia en nuestro trabajo para facilitar la integración de nuevos miembros, nuevos requerimientos y para la mantenibilidad del proyecto.

Angular tiene una estructura bien definida de como deberían ordenarse los archivos y carpetas y hoy me gustaría profundizar en ello.

Patrón LIFT

LIFT es el patrón principal creado por el equipo de Angular para ayudarte a definir bien la estructura de tus proyectos, significa lo siguiente:

Locate = Localizar
Identify = Identificar
Flat = Plano
T-DRY = Intentar no repetirse.

Ahora, veamos mas a detalle lo que cada uno significa.

Locate

Debemos hacer que el localizar código en nuestra aplicación sea algo fácil e intuitivo, que ya sea que tengamos mucho o poco tiempo en un proyecto siempre sepamos a donde ir para encontrar cada cosa.

Para cumplir con este paso, podemos guardar archivos en sub carpetas con nombres descriptivos y que tengan relación, por ejemplo, una carpeta para componentes (components), una carpeta para directivas, servicios, interfaces y pipes. De esta manera, sabremos que cada modulo que trabajemos tendrá este grupo de carpetas y sabremos a donde dirigirnos.

Identify

Para cumplir con este paso, lo que debemos hacer es nombrar nuestros archivos de manera que identificarlos sea fácil, es decir, si estamos creando un componente, podemos colocar el nombre y la terminación .component.ext, si estamos trabajando con servicios sería .service.ts y así sucesivamente.

Para este paso, lo que debemos evitar es que un archivo contenga más de un componente, así podremos saber que el nombre del archivo hace relación explícitamente a su contenido y no usar nombres más generales. Siempre debemos preferir nombres descriptivos (aunque largos) a tener nombres cortos pero confusos.

Flat

La estructura de nuestras aplicaciones debe ser lo mas plana posible, a nadie le gusta navegar a cinco niveles de profundidad en carpetas para encontrar el componente que andamos buscando.

Una recomendación importante es que cuando una carpeta tenga más de diez archivos dentro de ella, deberíamos considerar crear sub-carpetas, porque si bien es cierto no queremos que se llene de anidaciones, tampoco es lo correcto dejar todo dentro de una sola carpeta.

T-DRY

T-DRY significa Try Don't Repeat Yourself y lo que significa es que, en la medida de lo posible intentemos no repetirnos, pero si es inevitable, o si haremos sacrificios en nuestro código para no repetirnos, que elijamos legibilidad sobre el DRY.

Como ejemplo, debemos evitar nombrar con cosas obvias nuestros componentes, como agregar login-view.component.html cuando la extensión ya nos esta indicando que es una vista, o nombrar sign-up-style.component.scss cuando la extensión claramente nos dice que es un archivo de estilos.

Qué son Discriminated Unions y Exhaustiveness Checking en TypeScript?

Gerson Umanzor — Mon, 18 Apr 2022 04:02:23 +0000

Hola, yo soy Gerson Umanzor, Front-End Developer, y en esta ocasión me gustaría hablarles sobre los Discriminated Unions y Exhaustiveness Checkings en TypeScript.

Disclaimer: No me considero un experto en TypeScript, solamente quiero compartir con ustedes lo que he aprendido y encuentro muy interesante.

Discriminated Unions

Alguna vez han tenido una situación en la que necesiten basado en una propiedad de un parámetro actuar con otros keys o realizar cálculos?

Por ejemplo, si ustedes tienen dos perfiles de una persona, y quieren usar diferente información de estos perfiles para mostrarla, por ejemplo, asumamos que de un perfil, podríamos tener a un doctor, y a un ingeniero (de software, por supuesto) y que cada uno podria tener diferentes propiedades, como especialidad (para el doctor) y tecnología (para el ingeniero):

interface Perfil {
  tipo: 'doctor' | 'ingeniero';
  especialidad?: string;
  tecnologia?: string;
  hospital?: string;
  empresa: string;
}

Ahora bien, si yo quisiera mostrar información basado en el tipo de perfil que estoy utilizando, podría encontrarme con errores, por ejemplo, alguien podria proveerme con el perfil de un Doctor, pero accidentalmente no llenar la especialidad, o llenar la tecnologia, y eso se traduciría en que yo deba estar haciendo muchas validaciones, algo mas o menos así:

// ...
if (perfil.tipo === 'doctor') {
  if(perfil.especialidad) {
    // Mostrar informacion
  }
}

Pero dado que estas propiedades son opcionales (no puedo obligar al usuario a llenar toda la información cuando no la requiero toda), esto podría ocasionar que falte información o que esté recibiendo más información de la que necesito.

Y si agregamos más tipos? Esto se traduciría en agregar aún más propiedades al objeto, y terminaríamos con un objeto enorme lleno de propiedades opcionales, y, peor aún, con un listado de validaciones interminables.

Pero, como solucionamos esto? Bien sencillo, utilizamos lo que en TypeScript se llama Discriminated Unions, que se traduce en, tener una propiedad en común entre todas las interfaces o tipos, para que, de acuerdo al valor de esta propiedad, nosotros usemos solamente las keys que se necesitan, en ese caso, el ejemplo antes mencionado se traduciría en lo siguiente:

interface Doctor {
  tipo: 'doctor';
  especialidad: string;
  hospital: string;
}

interface Ingeniero {
  tipo: 'ingeniero';
  tecnologia: string;
  empresa: string;
}

Y luego, lo mas importante, es que crearemos un type para unir (de ahi el “Union” en el nombre de esta característica) ambas interfaces, así:

type Perfil = Doctor | Ingeniero;

Ahora, cuando queramos hacer ciertas validaciones, esto funcionaria sin ningún problema:

function revisarPerfil(perfil: Perfil) {

  switch (perfil.tipo) {
    case 'doctor': {
      // Puedo usar las propiedades especialidad y hospital, sin problemas;
      break;
    }
    case 'ingeniero': {
      // Puedo usar las propiedades tecnologia y empresa, sin problemas;
      break;
    }
    default: {
      break;
    }
  }
}

Lo que significa que solo debo hacer una validación (la de tipo) y con eso sería suficiente para saber que otras propiedades son accesibles, fácil, no? Bien, continuemos con Exhaustiveness Checking.

Exhaustiveness Checking

Cuando yo estoy recibiendo parámetros que tienen un número limitado de posibles valores, es muy importante saber que estoy cubriendo todos los posibles escenarios para poder evitar errores en producción.

Bien, tomaremos como base para el ejemplo los bloques de código anteriores, así que continuaremos utilizando el switch que creamos al final del primer ejercicio:

function revisarPerfil(perfil: Perfil) {
  switch (perfil.tipo) {
    case 'doctor': {
      // Puedo usar las propiedades especialidad y hospital, sin problemas;
      break;
    }
    case 'ingeniero': {
      // Puedo usar las propiedades tecnologia y empresa, sin problemas;
      break;
    }
    default: {
      break;
    }
  }
}

En ese bloque switch, nosotros estamos validando que todos los posibles escenarios estén cubiertos, ¿no?

Y que tal si más adelante, ya sea un par de días, unas semanas, unos meses o quien sabe, hasta un par de años, alguien más en el equipo agrega una interface más al tipo que nosotros habíamos declarado, llamemos a esta nueva interface Arquitecto

interface Arquitecto {
  tipo: 'arquitecto';
  // Resto de propiedades
}

Y ahora, el Union type se vería más o menos así:

type Perfil = Doctor | Ingeniero | Arquitecto;

Lo que significa que ahora, en nuestro switch case no estamos cubriendo todos los posibles escenarios que podríamos recibir, ¿qué hacemos? Aquí es donde el Exhaustiveness Checking entra en juego, y para implementarlo, hacemos lo siguiente:

function revisarPerfil(perfil: Perfil) {
  let exhaustiveChecking: never;

  switch (perfil.tipo) {
    case 'doctor': {
      // Puedo usar las propiedades especialidad y hospital, sin problemas;
      break;
    }
    case 'ingeniero': {
      // Puedo usar las propiedades tecnologia y empresa, sin problemas;
      break;
    }
    default: {
      exhaustiveChecking = perfil;
      break;
    }
  }
}

Los cambios que hemos realizado son dos:

Declaramos una variable de tipo never, a la cual llamamos exhaustiveChecking
Agregamos el default case, y en este asignamos el valor de perfil.

Pero, ¿qué significa que asigne un valor de un parámetro a una variable de tipo never? Aquí viene la explicación:

Dado que nosotros ya hemos cubierto todos los posibles escenarios de el parámetro perfil, cuando llegue al case default, no habría una coincidencia en cuanto al tipo, por lo tanto, TypeScript entiende que nunca va a llegar hasta ahí (de ahí que automáticamente se convierte en tipo never).

Esto significa que, cuando yo agregue una nueva opción a mi type Perfil, TypeScript va a detectar automáticamente que cuando llega al default case el tipo de el parámetro perfil no es de tipo never, sino que podría ser del tipo que recién agregamos, y no nos va a dejar compilar la aplicación, evitando errores en tiempo de compilación y mostrando el siguiente error al pasar el cursor sobre exhaustiveChecking:

Type 'Arquitecto' is not assignable to type 'never'.

Hasta aquí esta pequeña entrada, espero les haya gustado, y si tienen algún otro tema del que les gustaría que hablara, me pueden dejar saber, y con gusto preparamos una nueva entrada.

Un saludo!

Flujo de Trabajo con Git flow.

Gerson Umanzor — Fri, 01 May 2020 23:17:24 +0000

En el desarrollo de software es muy importante llevar el control y una línea de tiempo de lo que desarrollamos, por lo que un Sistema de Control de Versiones (VCS) es muy importante, pero en esta ocasión más que hablar del control de versiones como tal, me gustaria introducirlos a una metodología bastante popular para el desarrollo de software en equipo.

Gitflow es un conjunto de reglas o “estándares” para versionamiento que (a mi manera de verlo) la mayoría de los equipos deberían seguir al momento de desarrollar software colaborativo, es una de las más populares y por lo tanto la que mejores valoraciones tiene. Empecemos.

Instalacion

Para OSX podemos usar el siguiente comando:

brew install git-flow

Para instalar Git Flow en Windows, pueden seguir este enlace ya que el instalador ya trae git flow incluido.

Para Linux, existen varias maneras que puedes investigar en línea, para las distribuciones basadas en Debian/Ubuntu, puedes ejecutar el siguiente comando:

sudo apt-get install -y git-flow.

Después de haber instalado git-flow lo único que debemos hacer es dirigirnos al repositorio local de nuestro proyecto y ejecutar git flow init, este comando es una extensión del comando git init y no va a cambiar nada en el repositorio excepto la creación de las ramas.

Una vez ejecutemos este comando, nos pedirá los nombres por defecto de las ramas principales para nuestro proyecto, podemos dejar los valores predeterminados y continuar, el resultado seria similar al siguiente:

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 master

Las ramas que se crearan al inicio serán master y develop, profundicemos en ellas.

Ramas `master` y `develop`

En lugar de solamente usar la rama master, este flujo de trabajo utiliza dos ramas para guardar el historial del proyecto. La rama master almacena el historial de lanzamientos oficiales, y la rama develop funciona como una rama de integración para nuevas características en desarrollo, también es conveniente etiquetar todos los commits que se hagan en la rama master con un número de versión.

El primer paso es complementar la rama master con la rama develop, la manera más sencilla es crear la rama develop y hacer push al repositorio en el servidor ejecutando los siguientes comandos:

git branch develop
git push origin develop

Esa rama va a contener el historial completo del proyecto mientras que master va a contener una versión reducida. A partir de este punto los compañeros de proyecto deberían clonar el repositorio central y crear una rama de seguimiento para la rama develop.

Ramas por caracteristicas (feature branches)

Cada nueva característica debe residir en su propia rama, la cual puede ser guardada en el repositorio remoto para respaldo o colaboración. Pero, en vez de ramificar desde master, las ramas feature usen develop como su rama padre. Cuando una característica esté completa, debe ser combinada con develop. Las características nunca deberían ir directamente a la rama master.

Tomen en cuenta que las ramas por característica combinadas con la rama de desarrollo (develop) cumplen el propósito de ramificación por feature, pero el flujo de trabajo git flow no termina ahí.

Para crear una rama por característica, sin usar la herramienta git flow, podemos ejecutar los siguientes comandos:

git checkout develop
git checkout -b feature_branch

Pero cuando usamos la extensión git-flow, solamente debemos ejecutar:

git flow feature start feature_branch

Y continuamos usando git como siempre.

Terminar features:

Una vez la característica (regularmente tickets asignados en los proyectos), el siguiente paso sería combinar la rama feature con la rama de desarrollo (develop).

Sin las extensiones de git flow, deberíamos ejecutar los siguientes comandos:

git checkout develop
git merge feature_branch

Pero teniendo gitflow instalado, solamente necesitamos ejecutar:

git flow feature finish feature_branch

Este comando hará automáticamente el cambio hacia develop y luego el merge de la rama en la que estemos trabajando, y adicionalmente elimina la rama feature que ya no necesitamos.

Ramas para lanzamiento:

Una vez la rama de desarrollo haya adquirido suficientes características para un lanzamiento (o una fecha de lanzamiento está cerca), se hace una división (fork) de una rama de lanzamiento desde la rama develop. Al crear la rama se inicia un nuevo ciclo de lanzamiento, lo cual significa que en esta rama no deberían agregarse nuevas características sino a la rama develop, sin embargo, si se encuentran errores en este punto, estos deberían ser corregidos y actualizados en la rama de lanzamiento tanto como en la rama de desarrollo.

Usar una rama dedicada a los lanzamientos hace posible que el equipo pueda pulir y revisar adecuadamente el proyecto sin afectar o detener el desarrollo de nuevas características, esto también nos permite crear fases bien definidas del desarrollo.

Para poder crear ramas de lanzamiento también podemos hacerlo por nuestra cuenta, ejecutando los siguientes comandos:

git checkout develop
git checkout -b release/0.1.0

Pero si tenemos la extensión git-flow, también podemos hacer lo siguiente:

$ git flow release start 0.1.0

Lo cual nos dará como respuesta lo siguiente:

Switched to a new branch 'release/0.1.0'

Una vez esta rama esté lista, (sin bugs, documentada y revisada), debe combinarse con la rama principal (master) y etiquetada con un número de versión. Adicionalmente (no es obligacion) se sugiere que se haga merge a la rama develop por si hay alguna modificación que se haya realizado que necesite ser actualizada en la rama de desarrollo.

Para finalizar la rama de lanzamiento, podemos hacerlo, como siempre, de dos maneras, sin git-flow:

git checkout master
git merge release/0.1.0

Con git-flow:

git flow release finish '0.1.0'

Ramas de mantenimiento (hotfix branch):

Las ramas de mantenimiento o “hotfix” son ramas que nos ayudan a corregir lanzamientos ya en producción, son muy parecidas a las ramas de lanzamiento excepto que ellas salen directamente de la rama master y no de develop. Nos ayudan a la hora de corregir errores pequeños como faltas de ortografías o una imagen que no se vea del todo bien.
Una vez se haya finalizado el trabajo en esta rama, debe ser combinada de nuevo con master pero también con develop para mantener todos los cambios en las ramas principales del proyecto.

Inicializar una rama de revisión:

Sin git flow:

git checkout master
git checkout -b hotfix_branch