DEV Community: Paula Pereyra

ts-pattern- Explicado de manera sencilla

Paula Pereyra — Wed, 19 Mar 2025 02:52:42 +0000

ts-pattern es una librería de TypeScript para hacer pattern matching, que es una técnica para comparar estructuras de datos de manera elegante y segura. Facilita el manejo de datos complejos, eliminando muchos if y switch anidados.

Con ts-pattern puedes:
✅ Escribir código más limpio y seguro.
✅ Evitar errores al olvidarte de manejar un caso específico.
✅ Tener mejor inferencia de tipos en TypeScript.

Instalación

Para usar ts-pattern, primero instálalo en tu proyecto:

npm install ts-pattern

También puedes usar yarn o pnpm:

yarn add ts-pattern

pnpm add ts-pattern

🟨 Ejemplo Básico: Reemplazando un switch

Digamos que tenemos un estado en una aplicación:

type Estado = "cargando" | "exito" | "error";

const estado: Estado = "exito";

switch (estado) {
  case "cargando":
    console.log("Cargando datos...");
    break;
  case "exito":
    console.log("¡Datos cargados con éxito!");
    break;
  case "error":
    console.log("Hubo un error 😢");
    break;
}

Con ts-pattern, el código es más limpio y seguro:

import { match } from "ts-pattern";

const mensaje = match(estado)
  .with("cargando", () => "Cargando datos...")
  .with("exito", () => "¡Datos cargados con éxito!")
  .with("error", () => "Hubo un error 😢")
  .exhaustive(); // Asegura que cubrimos todos los casos

console.log(mensaje);

¿Qué hace este código?
match(estado) compara el valor de estado con diferentes patrones ("cargando", "exito", "error") y ejecuta la función correspondiente.

✅ Ventaja: Si olvidamos manejar un caso, ts-pattern nos avisa en tiempo de compilación.

🟨 Ejemplo con Objetos: Manejo de Errores

Imagina que estás manejando respuestas de una API con diferentes formatos:

type Respuesta =
  | { tipo: "ok"; data: string }
  | { tipo: "error"; mensaje: string };

const respuesta: Respuesta = { tipo: "error", mensaje: "No encontrado" };

Con if haríamos algo así:

if (respuesta.tipo === "ok") {
  console.log(`Datos: ${respuesta.data}`);
} else {
  console.log(`Error: ${respuesta.mensaje}`);
}

Con ts-pattern, el código es más elegante:

const resultado = match(respuesta)
  .with({ tipo: "ok" }, (r) => `Datos: ${r.data}`)
  .with({ tipo: "error" }, (r) => `Error: ${r.mensaje}`)
  .exhaustive();

console.log(resultado);

¿Qué hace este código?
Compara respuesta con los patrones { tipo: "ok" } y { tipo: "error" }.
Accede a r.data o r.mensaje automáticamente sin necesidad de hacer un if.

✅ Ventaja: TypeScript infiere el tipo correctamente sin necesidad de hacer as o comprobaciones manuales.

Uso con Expresiones Regulares o Rango de Valores

También puedes hacer matching con números, rangos o expresiones regulares. Por ejemplo, clasificamos edades:

const edad = 25;

const categoria = match(edad)
  .when((e) => e < 18, () => "Menor de edad")
  .when((e) => e >= 18 && e < 65, () => "Adulto")
  .when((e) => e >= 65, () => "Tercera edad")
  .otherwise(() => "Desconocido");

console.log(categoria); // "Adulto"

¿Qué hace este código?
Usa .when() para definir condiciones personalizadas.
Usa .otherwise() como caso por defecto.

✅ Ventaja: Es más declarativo que usar múltiples if.

🟨 Tipar `match`

Se puede tipar de forma segura gracias a TypeScript. Normalmente, TypeScript infiere los tipos automáticamente, pero si queremos asegurarnos de que solo acepte ciertos valores, podemos hacerlo manualmente.

Hay dos formas principales de tiparlo:

1) ** Tipado automático (sin definir el tipo)**
Cuando pasamos un valor a match, TypeScript ya infiere el tipo:

import { match } from "ts-pattern";

const estado = "cargando" as "cargando" | "exito" | "error";

const mensaje = match(estado)
  .with("cargando", () => "Cargando datos...")
  .with("exito", () => "¡Datos cargados con éxito!")
  .with("error", () => "Hubo un error 😢")
  .exhaustive();

console.log(mensaje);

¿Qué pasa aquí?
Como estado está tipado como "cargando" | "exito" | "error", TypeScript ya valida que match solo acepte esos valores.
Si olvidamos un caso, TypeScript dará error con .exhaustive().
✅ Ventaja: No necesitamos definir el tipo manualmente.

2) Tipado explícito (definiendo el tipo)
Si queremos ser más estrictos, podemos tipar manualmente match con match():

type Estado = "cargando" | "exito" | "error";

const estado: Estado = "exito";

const mensaje = match<Estado>(estado) // 👈 Aquí forzamos el tipo
  .with("cargando", () => "Cargando datos...")
  .with("exito", () => "¡Datos cargados con éxito!")
  .with("error", () => "Hubo un error 😢")
  .exhaustive();

console.log(mensaje);

✅ Ventaja: Si estado no tiene el tipo correcto, TypeScript mostrará error.

3) Extra: Tipado en Objetos
Cuando usamos objetos, también podemos tipar match para asegurar que todas las propiedades sean correctas.

Ejemplo con un objeto Respuesta:

type Respuesta =
  | { tipo: "ok"; data: string }
  | { tipo: "error"; mensaje: string };

const respuesta: Respuesta = { tipo: "ok", data: "Hola" };

const resultado = match<Respuesta>(respuesta) // 👈 Tipamos aquí
  .with({ tipo: "ok" }, (r) => `Datos: ${r.data}`)
  .with({ tipo: "error" }, (r) => `Error: ${r.mensaje}`)
  .exhaustive();

console.log(resultado);

✅ Ventaja:

TypeScript detecta automáticamente si olvidamos manejar un tipo de Respuesta.
r dentro de cada .with() ya tiene el tipo correcto (r.data o r.mensaje).

¿Necesito tipar match?

No siempre. TypeScript ya infiere los tipos en la mayoría de los casos.
Si queremos asegurarnos, podemos usar match<Tipo>(). Lo mejor: .exhaustive() siempre verifica que no falte ningún caso.

Gestionar múltiples configuraciones de servicios de control de versiones (Cualquier S.O) - Sin conflictos

Paula Pereyra — Tue, 07 Jan 2025 02:41:15 +0000

Este blog se creó a partir de mi necesidad de tener más ordenadas las diferentes configuraciones de los servicios de control de versiones. Yo utilizo Gitlab para mi trabajo, Github para proyectos propios que quiero compartir, y Gogs (que inició como prueba pero terminó siendo un lugar donde guardo configuraciones y backup de notas privadas junto con un familiar).

A lo que voy, necesito tenerlo separado, porque sino es un lío, y si hay que realizar una modificación, si no se sabe bien qué se está tocando, se puede ocasionar un desastre 😅.

Aquí tienes algunos pasos que puedes seguir, porque estuve investigando y es bastante sencillo.

Importante saber: Git utiliza un archivo de configuración global (~/.gitconfig) donde puedes establecer parámetros que afectarán a todos los repositorios. Sin embargo, para manejar diferentes servicios, puedes establecer configuraciones específicas para cada repositorio. Esto incluye las credenciales (usuario y correo electrónico) y el remoto.

Un servicio

Configuración global

Normalmente, si tienes un solo servicio, lo mejor es tener configuraciones globales, puedes establecer tu nombre y correo electrónico en tu archivo global .gitconfig. Por ejemplo:

git config --global user.name "Tu Nombre"
git config --global user.email "tu.email@ejemplo.com"

Y se usará esa configuración para todos los repositorios que crees. Es más fácil.

Más de un servicio

Opción 1: Configuración específica para cada repositorio

Puedes, aunque es más manual, para cada repositorio, establecer las configuraciones específicas que necesites.
Navega a la carpeta del repositorio y ejecuta:

cd /ruta/a/tu/repositorio
git config user.name "Tu Nombre para Gogs"
git config user.email "tu.email@gogs.com"

Haz lo mismo para los repositorios de GitHub y GitLab cuando trabajes en ellos.
Lo tienes que hacer una vez, cuando creas el repositorio y vas a subir un cambio a remoto, y luego para los demás tomará la configuración que hayas puesto.

Importante: Configura los remotos

Cuando añadas un nuevo remoto, asegúrate de que apunte al servidor correcto. Por ejemplo, para un repositorio de Gogs, puedes añadir el remoto así:

git remote add origin https://gogs.ejemplo.com/usuario/repositorio.git

Para GitHub o GitLab, haz lo mismo:

git remote add origin https://github.com/usuario/repositorio.git

Así cuando hagas git push origin rama se subirá al repositorio referenciado en el git remote y con las configuración hecha a nivel repositorio.

Opción 2: Uso de SSH (opcional pero recomendado)

Si usas SSH para autenticarte, puedes crear diferentes claves SSH para cada servicio y configurar el archivo ~/.ssh/config para gestionar las conexiones de forma más sencilla.

Generar claves SSH (si no tienes):

ssh-keygen -t rsa -b 4096 -C "tu.email@ejemplo.com"

Agregar las claves al agente SSH:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa_gogs
ssh-add ~/.ssh/id_rsa_github
ssh-add ~/.ssh/id_rsa_gitlab

Configurar el archivo ~/.ssh/config:

# Gogs
Host gogs
    HostName gogs.ejemplo.com
    User git
    IdentityFile ~/.ssh/id_rsa_gogs

# GitHub
Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_github

# GitLab
Host gitlab
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_rsa_gitlab

Usar los remotos con las configuraciones de SSH:

En lugar de usar las URL HTTPS, puedes usar las configuraciones de SSH:

git remote add origin gogs:usuario/repositorio.git
git remote add origin github:usuario/repositorio.git
git remote add origin gitlab:usuario/repositorio.git

Con estos pasos, deberías poder gestionar tus repositorios en Gogs, GitHub y GitLab desde la misma máquina sin que se interfieran entre sí. Asegúrate de siempre estar en el directorio correcto antes de ejecutar comandos de Git y de haber configurado adecuadamente las credenciales y remotos para cada proyecto.

Bonus:
Hablando de múltiple, pero en este caso de otras cuentas. Si quieres subir archivos (modificaciones) al repositorio de otra persona, puedes usar Git con credenciales temporales sin afectar tu configuración global.
Tienes que tener en cuenta que esto es para cosas puntuales.

Usando la URL con credenciales directamente:

git remote set-url origin https://username:password@github.com/usuario/repositorio.git

Donde:
username: el nombre de usuario de la otra persona
password: un token de acceso personal de GitHub de la otra persona (no la contraseña directa)

Para crear un token de acceso lo puedes seguir desde acá de manera muy simple, y con solo darle al check en "repo" (darle acceso a las acciones sobre los repositorios), ya se pueden subir los cambios.

Si hay algún comando que esté incorrecto, o quieres aportar en los comentarios, eres bienvenido :)

Vue 3 - Pico.css - Agregar el Minimal CSS Framework a Nuxt 3

Paula Pereyra — Mon, 26 Feb 2024 18:14:57 +0000

Introducción

En este artículo, mostraré cómo agregar Pico.css a un proyecto hecho con Nuxt 3. Tengo que aclarar que esta es una manera que encontré yo de que funcione, porque realicé una larga búsqueda y no encontré otro articulo que enseñe como añadirlo (quería compartirlo por si alguien quiere usarlo en algún proyecto que esté realizando). Este será un artículo breve ya que no requiere mucho trabajo.

PD: Asumo que el proyecto hecho con nuxt ya está creado, pero sino, es solo ir a la documentación oficial y corremos el comando en la consola (en el directorio que quieran) npx nuxi@latest init <project-name> para crear un nuevo proyecto inicial (Se necesita tener instalado Node.js - v18.0.0 o más reciente).

Instalar Pico.css

Vamos a la pagina oficial, y buscamos la sección "Getting Started"

https://picocss.com/

Vamos a la sección Install with NPM y elegimos el comando que queramos para instalar la dependencia en el proyecto, segun el gestor de paquetes que estemos usando (npm, yarn, pnpm)

Una vez instalado, lo podemos verificar en nuestro package.json:

{
   "@picocss/pico": "^2.0.3",
}

Añadirlo al proyecto con Nuxt

Como sabemos, cuando instalamos una dependencia, esta se agrega a los node_modules, es algo a tener en cuenta para después.

Antes que nada, hay que crear un archivo dentro de esta estructura:
assets/css/app.css (Esto dentro de la raíz del proyecto).
Dentro de este archivo, hay que escribir lo siguiente:

@import("");

Dentro de ese import tenemos que poner la ruta de un archivo "pico.css" que se encuentra dentro del node_modules. Quedaría algo así:

@import url('@picocss/pico/css/pico.css')

Ahora ya podemos arrancar nuestro proyecto, en mi caso con pnpm run dev, y tendremos ya el estilo de Pico:

Espero que les haya funcionado. Hasta el próximo blog. 👋