Programación · DacaCode

Patrones de Diseño: Factory

Dacadev — Tue, 07 Jul 2026 00:00:00 +0000

Tabla de Contenido

La instanciación directa de clases concretas es uno de los puntos más costosos de acoplamiento en un diseño orientado a objetos. Cada new o llamada explícita a un constructor ata al cliente a una implementación específica, dificultando la extensión y la sustitución de componentes. Los patrones factory encapsulan esa decisión en un lugar controlado, permitiendo evolucionar la creación de objetos sin propagar cambios a todo el código consumidor.

Note

🚀 Los patrones factory encapsulan la creación de objetos y desacoplan al cliente de las clases concretas que necesita instanciar.

Este artículo forma parte de la serie de patrones de diseño. Analizaremos tres variantes de fabricación (Simple Factory, Factory Method y Abstract Factory), su relación con el Principio de Inversión de Dependencias y los trade-offs que conviene considerar al elegir uno u otro.

Simple Factory

El Simple Factory no es un patrón de diseño formal del catálogo GoF, sino un idiom recurrente: encapsular la lógica de creación de objetos dentro de un método (usualmente estático) que decide qué instancia devolver en función de un parámetro. Es un buen punto de partida para entender los patrones que veremos a continuación.

Info

GoF significa “Gang of Four” (la “Banda de los Cuatro”): los cuatro autores del libro Design Patterns (1994) que catalogó los 23 patrones de diseño clásicos. Cuando decimos que un patrón “es GoF”, significa que aparece en ese catálogo original.

Supongamos una pizzería que produce distintos tipos de pizzas. Sin un factory, el cliente tendría que conocer todas las clases concretas y decidir cuál instanciar. Con un SimpleFactory esa decisión queda centralizada:

classDiagram
 class PizzaStore {
 -factory: SimplePizzaFactory
 +order_pizza(kind) Pizza
 }
 class SimplePizzaFactory {
 +create_pizza(kind) Pizza
 }
 class Pizza {
 <<abstract>>
 +prepare()
 +bake()
 +box()
 }
 class CheesePizza
 class VeggiePizza
 class PepperoniPizza

 PizzaStore --> SimplePizzaFactory : usa
 SimplePizzaFactory ..> Pizza : crea
 Pizza <|-- CheesePizza
 Pizza <|-- VeggiePizza
 Pizza <|-- PepperoniPizza

Implementación mínima en Python:

from abc import ABC, abstractmethod


class Pizza(ABC):
 @abstractmethod
 def prepare(self) -> None: ...

 def bake(self) -> None:
 print("Horneando la pizza")

 def box(self) -> None:
 print("Empacando la pizza")


class CheesePizza(Pizza):
 def prepare(self) -> None:
 print("Preparando pizza de queso")


class VeggiePizza(Pizza):
 def prepare(self) -> None:
 print("Preparando pizza vegetariana")


class SimplePizzaFactory:
 def create_pizza(self, kind: str) -> Pizza:
 if kind == "cheese":
 return CheesePizza()
 if kind == "veggie":
 return VeggiePizza()
 raise ValueError(f"Tipo de pizza no soportado: {kind}")


class PizzaStore:
 def __init__(self, factory: SimplePizzaFactory) -> None:
 self.factory = factory

 def order_pizza(self, kind: str) -> Pizza:
 pizza = self.factory.create_pizza(kind)
 pizza.prepare()
 pizza.bake()
 pizza.box()
 return pizza

El cliente (PizzaStore) ya no depende de las clases concretas; toda la lógica de selección vive en el factory. La limitación es evidente: si necesitamos que distintas sucursales produzcan variantes propias de cada pizza, el if/elif termina explotando. Ese es exactamente el problema que resuelve Factory Method.

Info

El Simple Factory es útil como técnica de refactor cuando queremos aislar una serie de condicionales de creación, pero no ofrece extensibilidad vía herencia.

Factory Method

Note

El Factory Method define una interfaz para crear un objeto, pero delega en las subclases la decisión de qué clase concreta instanciar.

En lugar de tener una única clase factory que decide con condicionales, el Factory Method define un método abstracto de creación en la superclase. Cada subclase implementa ese método y devuelve el producto concreto que corresponda. La instanciación se difiere a las subclases.

classDiagram
 class Creator {
 <<abstract>>
 +factory_method() Product
 +operation()
 }
 class ConcreteCreatorA {
 +factory_method() Product
 }
 class ConcreteCreatorB {
 +factory_method() Product
 }
 class Product {
 <<abstract>>
 }
 class ConcreteProductA
 class ConcreteProductB

 Creator <|-- ConcreteCreatorA
 Creator <|-- ConcreteCreatorB
 Product <|-- ConcreteProductA
 Product <|-- ConcreteProductB
 ConcreteCreatorA ..> ConcreteProductA : crea
 ConcreteCreatorB ..> ConcreteProductB : crea

Consideremos un ejemplo canónico: una jerarquía de animales donde cada subclase decide qué instancia producir. La superclase define el flujo (show_animal) que consume el producto creado por el factory_method:

from abc import ABC, abstractmethod


class Animal(ABC):
 @abstractmethod
 def make_sound(self) -> str: ...

 @abstractmethod
 def create_animal(self) -> "Animal": ...

 def show_animal(self) -> None:
 animal = self.create_animal()
 print(f"El animal dice: {animal.make_sound()}")


class Dog(Animal):
 def make_sound(self) -> str:
 return "Guau!"

 def create_animal(self) -> Animal:
 return Dog()


class Cat(Animal):
 def make_sound(self) -> str:
 return "Miau!"

 def create_animal(self) -> Animal:
 return Cat()


Dog().show_animal() # El animal dice: Guau!
Cat().show_animal() # El animal dice: Miau!

El punto clave es que Animal.show_animal es agnóstico a la clase concreta: opera sobre la abstracción Animal y delega la instanciación a create_animal. Añadir un nuevo animal implica una nueva subclase, no modificar código existente — cumpliendo el principio abierto/cerrado.

Tip

Factory Method depende de herencia: cada subclase implementa el método de creación. Es ideal cuando la variación entre productos está atada a la variación de la clase creadora.

Abstract Factory

Mientras Factory Method crea un producto, el Abstract Factory crea familias completas de productos relacionados sin acoplar al cliente a las clases concretas de cada familia.

Un caso clásico: una aplicación que renderiza componentes de UI para distintos sistemas operativos. Botones y checkboxes de Windows deben usarse juntos, igual que los de macOS; mezclarlos rompe la coherencia visual. El Abstract Factory garantiza que solo se combinen componentes de la misma familia.

classDiagram
 class GUIFactory {
 <<abstract>>
 +create_button() Button
 +create_checkbox() Checkbox
 }
 class WindowsFactory
 class MacFactory
 class Button {
 <<abstract>>
 +render()
 }
 class Checkbox {
 <<abstract>>
 +render()
 }
 class WindowsButton
 class WindowsCheckbox
 class MacButton
 class MacCheckbox

 GUIFactory <|-- WindowsFactory
 GUIFactory <|-- MacFactory
 Button <|-- WindowsButton
 Button <|-- MacButton
 Checkbox <|-- WindowsCheckbox
 Checkbox <|-- MacCheckbox
 WindowsFactory ..> WindowsButton : crea
 WindowsFactory ..> WindowsCheckbox : crea
 MacFactory ..> MacButton : crea
 MacFactory ..> MacCheckbox : crea

Implementación en Python:

from abc import ABC, abstractmethod


class Button(ABC):
 @abstractmethod
 def render(self) -> None: ...


class Checkbox(ABC):
 @abstractmethod
 def render(self) -> None: ...


class WindowsButton(Button):
 def render(self) -> None:
 print("Renderizando botón de Windows")


class WindowsCheckbox(Checkbox):
 def render(self) -> None:
 print("Renderizando checkbox de Windows")


class MacButton(Button):
 def render(self) -> None:
 print("Renderizando botón de macOS")


class MacCheckbox(Checkbox):
 def render(self) -> None:
 print("Renderizando checkbox de macOS")


class GUIFactory(ABC):
 @abstractmethod
 def create_button(self) -> Button: ...

 @abstractmethod
 def create_checkbox(self) -> Checkbox: ...


class WindowsFactory(GUIFactory):
 def create_button(self) -> Button:
 return WindowsButton()

 def create_checkbox(self) -> Checkbox:
 return WindowsCheckbox()


class MacFactory(GUIFactory):
 def create_button(self) -> Button:
 return MacButton()

 def create_checkbox(self) -> Checkbox:
 return MacCheckbox()


class Application:
 def __init__(self, factory: GUIFactory) -> None:
 self.factory = factory

 def create_ui(self) -> None:
 button = self.factory.create_button()
 checkbox = self.factory.create_checkbox()
 button.render()
 checkbox.render()


factory: GUIFactory = WindowsFactory() # o MacFactory()
Application(factory).create_ui()

Application depende exclusivamente de GUIFactory, Button y Checkbox — todas abstracciones. Cambiar de familia consiste en inyectar una factory distinta; el resto del código permanece intacto.

Factory Method vs Abstract Factory

Aunque comparten espíritu, no son intercambiables:

Factory Method usa herencia: la subclase decide qué producto crear implementando un método.
Abstract Factory usa composición: el cliente recibe una factory y llama a varios métodos de creación sobre ella, obteniendo una familia de productos coherentes.
Factory Method escala en la dimensión de “un producto que varía”; Abstract Factory escala en la dimensión de “múltiples productos que varían de forma correlacionada”.

Static Factory

El Static Factory es una variante ligera que expone métodos de clase estáticos para construir instancias, en lugar de exponer constructores públicos. Es común en librerías del ecosistema Java y en APIs de Python que ofrecen métodos como datetime.now() o Path.home().

class Connection:
 def __init__(self, dsn: str) -> None:
 self._dsn = dsn

 @classmethod
 def from_env(cls) -> "Connection":
 import os
 return cls(dsn=os.environ["DATABASE_URL"])

 @classmethod
 def in_memory(cls) -> "Connection":
 return cls(dsn="sqlite://:memory:")

Ventajas: los métodos estáticos pueden tener nombres semánticos (from_env, in_memory) que documentan la intención mucho mejor que un constructor sobrecargado. Limitación: no permite polimorfismo — no es reemplazable en tiempo de ejecución como sí lo son Factory Method o Abstract Factory.

Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias (DIP, la “D” de SOLID) enuncia dos reglas:

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
Las abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones.

Los patrones factory son una herramienta natural para aplicar DIP: al centralizar la creación en una abstracción, el módulo de alto nivel deja de instanciar clases concretas. Volviendo al ejemplo de la pizzería:

flowchart LR
 subgraph Antes["Sin DIP"]
 A1[PizzaStore] --> A2[CheesePizza]
 A1 --> A3[VeggiePizza]
 A1 --> A4[PepperoniPizza]
 end
 subgraph Despues["Con DIP + Factory"]
 B1[PizzaStore] --> B2[Pizza abstracta]
 B3[CheesePizza] --> B2
 B4[VeggiePizza] --> B2
 B5[PepperoniPizza] --> B2
 end

En “Antes”, el flujo de dependencia va de alto a bajo nivel: PizzaStore conoce todas las pizzas concretas. En “Después”, ambos dependen de la abstracción Pizza: la dependencia queda invertida.

Un ejemplo aislado en Python que muestra el patrón:

from abc import ABC, abstractmethod


class MessageSender(ABC):
 @abstractmethod
 def send(self, message: str) -> None: ...


class EmailSender(MessageSender):
 def send(self, message: str) -> None:
 print(f"Enviando email: {message}")


class SmsSender(MessageSender):
 def send(self, message: str) -> None:
 print(f"Enviando SMS: {message}")


class NotificationService:
 def __init__(self, sender: MessageSender) -> None:
 self._sender = sender

 def notify(self, message: str) -> None:
 self._sender.send(message)


NotificationService(EmailSender()).notify("Nuevo despliegue exitoso")

NotificationService no conoce EmailSender ni SmsSender; solo la abstracción MessageSender. Un factory puede alimentar esa dependencia según configuración, entorno o feature flags, sin tocar NotificationService.

Consideraciones

Todos los factories encapsulan la creación de objetos y reducen el acoplamiento a implementaciones concretas.
Simple Factory no es un patrón GoF; es un idiom útil para aislar condicionales de creación en un único lugar.
Factory Method depende de herencia: cada subclase implementa el método de creación y decide el producto concreto.
Abstract Factory depende de composición: el cliente recibe una factory y obtiene familias de productos coherentes.
Los tres refuerzan el Principio de Inversión de Dependencias al hacer que el código cliente dependa de abstracciones, no de tipos concretos.
El DIP es una guía transversal, no un patrón: aplica siempre que quieras evitar el acoplamiento con implementaciones específicas.
Factory es una técnica de diseño, no una clase específica. Su nombre puede variar (build, create, from_x), lo importante es la intención: encapsular la construcción de objetos.

Note

🚀 Elige Simple Factory para aislar condicionales, Factory Method cuando la variación está atada a la jerarquía del creador, y Abstract Factory cuando necesitas coherencia entre múltiples productos relacionados.

Continúa la serie

Si te interesa seguir explorando patrones de diseño, revisa los otros artículos de la serie:

SQL: Transacciones, Índices y Constraints

Dacadev — Fri, 26 Jun 2026 00:00:00 -0500

Tabla de Contenido

En sistemas con múltiples usuarios escribiendo datos al mismo tiempo, la diferencia entre una aplicación confiable y una que corrompe información suele estar en cómo manejas transacciones en SQL, índices y constraints. En el artículo anterior analizamos Vistas (Views); ahora cerramos la serie con mecanismos de integridad y rendimiento.

Note

En este artículo vas a aprender cómo iniciar y cerrar transacciones con COMMIT y ROLLBACK, cuándo usar savepoints, cómo funcionan los índices B-tree, bitmap y full-text, y cómo las constraints mantienen reglas de integridad dentro del esquema.

Qué es una transacción en SQL

Una transacción agrupa una o varias sentencias SQL que deben ejecutarse como una unidad lógica. El objetivo es que los cambios se apliquen completos o no se apliquen en absoluto.

Consideremos una transferencia bancaria. Restar dinero de una cuenta y sumarlo a otra no son acciones independientes desde el punto de vista del negocio. Si una actualización se ejecuta y la otra falla, el sistema queda en un estado inconsistente.

START TRANSACTION;

 /* retirar dinero de la primera cuenta, validando saldo suficiente */
UPDATE account SET avail_balance = avail_balance - 500
WHERE account_id = 9988
 AND avail_balance > 500;

IF <exactly one row was updated by the previous statement> THEN
 /* depositar dinero en la segunda cuenta */
 UPDATE account SET avail_balance = avail_balance + 500
 WHERE account_id = 9989;

 IF <exactly one row was updated by the previous statement> THEN
 /* todo funcionó, hacer los cambios permanentes */
 COMMIT;
 ELSE
 /* algo falló, deshacer todos los cambios de esta transacción */
 ROLLBACK;
 END IF;
ELSE
 /* saldo insuficiente o error durante la actualización */
 ROLLBACK;
END IF;

En este flujo, COMMIT confirma los cambios y ROLLBACK revierte todo lo ejecutado desde el inicio de la transacción. La base de datos actúa como una frontera de consistencia.

Candados y concurrencia

Cuando varias sesiones intentan leer o escribir los mismos datos, el motor puede usar candados (locks) sobre filas, páginas o tablas. Los locks evitan que una transacción lea datos en transición o sobrescriba cambios que todavía no han sido confirmados.

Iniciar una transacción

Los servidores de base de datos suelen manejar la creación de transacciones de una de estas dos formas:

Siempre existe una transacción activa asociada a la sesión. Cuando la transacción actual termina, el servidor inicia automáticamente una nueva.
Cada sentencia SQL se confirma automáticamente, a menos que inicies una transacción explícita.

En MySQL, una transacción explícita puede comenzar con:

start transaction

Tip

Puedes configurar el comportamiento de autocommit según el motor y el cliente que uses.

Terminar una transacción

Una vez iniciada una transacción, necesitas terminarla explícitamente para que los cambios sean permanentes. COMMIT marca los cambios como definitivos y libera recursos usados durante la transacción,.

Si decides deshacer lo ejecutado desde el inicio de la transacción, usas ROLLBACK. El servidor devuelve los datos al estado previo de la transacción.

Además de COMMIT y ROLLBACK, una transacción puede terminar por otros eventos:

El servidor se apaga; al reiniciar, la transacción pendiente se revierte automáticamente.
Ejecutas una sentencia de esquema como ALTER TABLE; en varios motores esto puede confirmar la transacción actual e iniciar otra.
Ejecutas otro START TRANSACTION; algunos motores confirman la transacción anterior antes de abrir la nueva.
El servidor detecta un deadlock, elige una transacción como víctima y la revierte para desbloquear el sistema.

Warning

Las sentencias DDL no siempre participan en transacciones igual que las sentencias DML. Antes de mezclar ALTER TABLE, CREATE INDEX o cambios de esquema con operaciones de datos, revisa el comportamiento específico de tu motor.

Savepoints dentro de una transacción

Los savepoints permiten definir puntos intermedios de rollback dentro de una misma transacción. En lugar de revertir todo, puedes regresar a un punto específico y continuar trabajando.

Índices y constraints

Una consulta sin apoyo puede obligar al servidor a escanear fila por fila. En tablas con millones de registros y decenas de columnas, esto se convierte en un cuello de botella.

Los índices son estructuras auxiliares que permiten encontrar filas con menos trabajo. Aceleran búsquedas, filtros, joins y ordenamientos.

Creación de índices

Para crear un índice en MySQL podemos usar ALTER TABLE. Supongamos que el sistema consulta clientes frecuentemente por correo electrónico:

mysql> ALTER TABLE customer
 -> ADD INDEX idx_email (email);
Query OK, 0 rows affected (1.87 sec)
Records: 0 Duplicates: 0 Warnings: 0

Después de crear el índice, el optimizador decide si conviene usarlo. El motor evalúa estadísticas, cardinalidad y costo estimado.

Podemos inspeccionar los índices existentes con SHOW INDEX:

mysql> SHOW INDEX FROM customer \G;
*************************** 1. row ***************************
 Table: customer
 Non_unique: 1
 Key_name: idx_email
 Seq_in_index: 1
 Column_name: email
 Collation: A
 Cardinality: 599
 Sub_part: NULL
 Packed: NULL
 Null: YES
 Index_type: BTREE
...
5 rows in set (0.06 sec)

Y también podemos eliminarlos cuando dejan de aportar valor:

mysql> ALTER TABLE customer
 -> DROP INDEX idx_email;
Query OK, 0 rows affected (0.50 sec)
Records: 0 Duplicates: 0 Warnings: 0

Info

Cada índice ocupa espacio y debe actualizarse cuando cambian las filas afectadas. Un índice acelera lecturas específicas, pero también puede encarecer escrituras como INSERT, UPDATE y DELETE.

Índices únicos

Un índice único cumple dos funciones: acelera búsquedas y evita valores duplicados en las columnas indexadas. Cada vez que insertas una fila o modificas la columna, el servidor valida si el valor ya existe.

mysql> ALTER TABLE customer
 -> ADD UNIQUE idx_email (email);
Query OK, 0 rows affected (0.64 sec)
Records: 0 Duplicates: 0 Warnings: 0

Si intentas insertar un cliente con un email ya registrado, el motor rechaza la operación:

mysql> INSERT INTO customer
 -> (store_id, first_name, last_name, email, address_id, active)
 -> VALUES
 -> (1,'ALAN','KAHN', 'ALAN.KAHN@sakilacustomer.org', 394, 1);
ERROR 1062 (23000): Duplicate entry 'ALAN.KAHN@sakilacustomer.org' 
 for key 'idx_email'

Índices multicolumna

También puedes crear índices que cubren varias columnas. Si buscas clientes por apellido y nombre, un índice compuesto puede ser más útil que dos índices separados.

mysql> ALTER TABLE customer
 -> ADD INDEX idx_full_name (last_name, first_name);
Query OK, 0 rows affected (0.35 sec)
Records: 0 Duplicates: 0 Warnings: 0

El orden importa. Un índice (last_name, first_name) ayuda a consultas que filtran por last_name o por last_name junto con first_name. No ayuda igual a una consulta que filtra solo por first_name.

Tipos de índices

Índices B-tree

Los índices B-tree organizan los valores como árboles balanceados. Los branch nodes sirven para navegar por rangos, mientras que los leaf nodes almacenan los valores reales del índice.

Branch nodes dirigen la búsqueda hacia el rango correcto; leaf nodes contienen las entradas finales asociadas a los valores indexados.

flowchart TD
 root["Nodo raíz<br/>A - M | N - Z"]
 b1["A-C | D-F | G-I | J-M"]
 b2["N-P | Q-S | T-V | W-Z"]
 root --> b1
 root --> b2
 b1 --> l1["Barker<br/>Blake"]
 b1 --> l2["Fleming<br/>Fowler"]
 b1 --> l3["Gooding<br/>Grossman<br/>Hawthorne"]
 b1 --> l4["Jameson<br/>Markham<br/>Mason"]
 b2 --> l5["Parker<br/>Portman"]
 b2 --> l6["Roberts<br/>Smith"]
 b2 --> l7["Tucker<br/>Tulman<br/>Tyler"]
 b2 --> l8["Ziegler"]

Este tipo de índice funciona muy bien para columnas con muchos valores distintos, como customer.last_name, fechas, identificadores externos o campos usados en rangos.

Índices bitmap

Los bitmap indexes están diseñados para columnas de baja cardinalidad, es decir, columnas con pocos valores posibles repetidos en muchas filas. Un ejemplo clásico es customer.active, donde puede haber solo 1 para activo y 0 para inactivo.

En lugar de mantener un árbol grande, el motor mantiene bitmaps por valor. Para consultar clientes inactivos, puede recorrer el bitmap del valor 0 y localizar las filas correspondientes.

Esta estrategia es compacta para baja cardinalidad, pero se degrada cuando la columna tiene demasiados valores distintos.

Índices de texto

Cuando almacenas documentos o contenido largo, buscar palabras con un escaneo completo es costoso.

MySQL y SQL Server ofrecen índices full-text; Oracle incluye herramientas bajo Oracle Text. Estos mecanismos están especializados para documentos y búsquedas textuales.

Cómo se usan los índices

Los índices permiten acceder rápidamente a datos, pero el motor decide si usarlos según el plan de ejecución. Un índice creado no garantiza automáticamente una consulta más rápida.

Observemos tres criterios prácticos:

Crea índices alrededor de consultas frecuentes, no alrededor de columnas al azar.
Evita indexar columnas con baja selectividad usando B-tree si el motor ofrece una estrategia mejor.
Mide el impacto en escrituras, porque cada índice debe mantenerse actualizado.

Constraints: restricciones de integridad

Una constraint es una restricción aplicada a una o más columnas de una tabla. Vive dentro del esquema y protege los datos desde la base.

Los tipos principales son:

Primary key constraints: identifican la columna o combinación de columnas que garantizan unicidad dentro de una tabla.
Foreign key constraints: restringen una o más columnas para que contengan valores existentes en la primary key de otra tabla.
Unique constraints: evitan duplicados en una o más columnas; una primary key es un caso especial de unicidad.
Check constraints: restringen los valores permitidos para una columna según una condición.

Normalmente las constraints se crean junto con la tabla usando CREATE TABLE. Este ejemplo del esquema Sakila combina primary key, índices y foreign keys:

CREATE TABLE customer (
 customer_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
 store_id TINYINT UNSIGNED NOT NULL,
 first_name VARCHAR(45) NOT NULL,
 last_name VARCHAR(45) NOT NULL,
 email VARCHAR(50) DEFAULT NULL,
 address_id SMALLINT UNSIGNED NOT NULL,
 active BOOLEAN NOT NULL DEFAULT TRUE,
 create_date DATETIME NOT NULL,
 last_update TIMESTAMP DEFAULT CURRENT_TIMESTAMP 
 ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (customer_id),
 KEY idx_fk_store_id (store_id),
 KEY idx_fk_address_id (address_id),
 KEY idx_last_name (last_name),
 CONSTRAINT fk_customer_address FOREIGN KEY (address_id) 
 REFERENCES address (address_id) ON DELETE RESTRICT ON UPDATE CASCADE,
 CONSTRAINT fk_customer_store FOREIGN KEY (store_id) 
 REFERENCES store (store_id) ON DELETE RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

También puedes agregar constraints después con ALTER TABLE:

ALTER TABLE customer
ADD CONSTRAINT fk_customer_address FOREIGN KEY (address_id)
REFERENCES address (address_id) ON DELETE RESTRICT ON UPDATE CASCADE;

ALTER TABLE customer
ADD CONSTRAINT fk_customer_store FOREIGN KEY (store_id)
REFERENCES store (store_id) ON DELETE RESTRICT ON UPDATE CASCADE;

La cláusula ON DELETE RESTRICT protege contra registros huérfanos cuando se intenta eliminar una fila padre.

Para foreign keys, las acciones comunes ante borrados y actualizaciones son:

ON DELETE RESTRICT: impide borrar la fila padre si existen filas hijas relacionadas.
ON DELETE CASCADE: borra automáticamente las filas hijas cuando se borra la fila padre.
ON DELETE SET NULL: asigna NULL en la foreign key de las filas hijas cuando se borra la fila padre.
ON UPDATE RESTRICT: impide actualizar la clave padre si hay filas hijas relacionadas.
ON UPDATE CASCADE: propaga el cambio de clave hacia las filas hijas.
ON UPDATE SET NULL: asigna NULL en la foreign key de las filas hijas cuando cambia la clave padre.

Warning

CASCADE es potente, pero debe modelarse con cuidado. Una eliminación pequeña puede disparar borrados en varias tablas.

Conclusión de la serie SQL

Las transacciones, índices y constraints completan la base práctica para trabajar con SQL de forma profesional. Protegen operaciones compuestas, reducen el costo de acceso a datos y llevan reglas críticas al esquema.

Con este artículo cerramos la serie de SQL. Para repasar desde el inicio, vuelve a: Fundamentos SQL: SELECT, FROM y WHERE. Desde ahí puedes recorrer consultas, filtros, joins, agrupaciones, subconsultas, vistas y estos mecanismos de integridad y rendimiento.

TypeScript: Depuración de errores y tsconfig.json

Dacadev — Wed, 24 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Artículo final de la serie sobre TypeScript. Consolidaremos la configuración del compilador mediante tsconfig.json y las opciones que facilitan la depuración y mejoran la calidad del código emitido.

El archivo tsconfig.json es el centro de control del compilador: define cómo TypeScript interpreta, verifica y transforma tu proyecto. Una configuración bien afinada no solo previene errores, sino que mejora la experiencia de depuración y la calidad del JavaScript resultante. Cerremos la serie dominando esta pieza. La referencia completa está en la documentación oficial de tsconfig.json.

Qué es tsconfig.json y para qué sirve

tsconfig.json declara el comportamiento del compilador para todo el proyecto. Cuando se genera por primera vez, muchas opciones aparecen comentadas, y el valor mostrado en el comentario suele ser el recomendado por defecto.

Info

La presencia de un tsconfig.json en un directorio marca la raíz de un proyecto TypeScript. Ejecutar tsc sin argumentos hace que el compilador busque este archivo y compile según sus reglas.

Opciones recomendadas

Estas opciones de compilerOptions aportan el mayor valor en un proyecto profesional:

strict: activa el conjunto completo de comprobaciones estrictas. Es la opción que más errores previene.
noImplicitAny: prohíbe que TypeScript asigne any de forma implícita cuando no puede inferir un tipo, obligándote a ser explícito.
removeComments: elimina los comentarios del JavaScript compilado, produciendo una salida más limpia.
sourceMap: genera source maps que enlazan el JavaScript emitido con tu código TypeScript original.

{
 "compilerOptions": {
 "strict": true,
 "noImplicitAny": true,
 "removeComments": true,
 "sourceMap": true,
 "target": "es2015",
 "module": "commonjs",
 "outDir": "dist"
 },
 "include": ["src"]
}

Tip

strict es en realidad un paraguas que activa varias comprobaciones, entre ellas noImplicitAny, strictNullChecks y strictFunctionTypes. Habilitarlo desde el primer commit evita una migración costosa cuando el proyecto ya acumuló tipos implícitos.

sourceMap: depurar el código original

Sin source maps, cuando depuras en el navegador o en Node solo ves el JavaScript transpilado, que puede diferir notablemente de tu TypeScript. Con sourceMap: true, el compilador genera archivos .js.map que permiten al depurador mostrar tu código fuente original, colocar breakpoints en él e inspeccionar variables con sus nombres reales.

Esta opción es la diferencia entre depurar el código que escribiste y depurar el código que la máquina generó.

Generar un único archivo de salida

Para ciertos escenarios —especialmente proyectos de frontend sin un bundler— resulta útil concatenar toda la salida en un solo archivo JavaScript. Esto se logra con la opción outFile:

{
 "compilerOptions": {
 "outFile": "./main.js",
 "sourceMap": true,
 "removeComments": true
 }
}

Warning

outFile solo funciona con los sistemas de módulos amd y system; no es compatible con commonjs ni esnext. En proyectos modernos, lo habitual es delegar el empaquetado a herramientas como webpack o esbuild en lugar de usar outFile.

Depurar errores con eficacia

El flujo de depuración en TypeScript combina las opciones anteriores con la lectura disciplinada de los mensajes del compilador:

Cada error incluye un código (por ejemplo TS2345) que puedes buscar para entender su causa raíz.
Con strict activo, los errores afloran en compilación, antes de ejecutar el código.
Con sourceMap, los errores en tiempo de ejecución apuntan a tu TypeScript original, no al JavaScript emitido.
El modo observador (tsc --watch) reporta los errores de forma incremental mientras escribes.

flowchart LR
 A[Código TS] --> B[tsc con strict]
 B -- error de tipo --> C[Mensaje TSxxxx<br/>en compilación]
 B -- ok --> D[JS + sourceMap]
 D --> E[Runtime]
 E -- error --> F[Stack trace sobre TS<br/>gracias al sourceMap]

Conclusión

tsconfig.json es la herramienta que transforma TypeScript de un transpilador genérico en un compilador afinado a tu proyecto. Activar strict y noImplicitAny maximiza la detección temprana de errores; sourceMap hace que la depuración opere sobre tu código real; y removeComments pule la salida. Dominar estas opciones cierra el ciclo: del tipado en el editor a la depuración en producción.

Con esto concluye la serie sobre TypeScript. Has recorrido desde la instalación y los tipos básicos hasta los genéricos, los decoradores y la configuración del compilador: el conjunto de herramientas necesario para construir aplicaciones robustas y mantenibles con tipado estático.

SQL: Vistas (Views) para Abstraer y Asegurar tus Datos

Dacadev — Tue, 23 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una base de datos crece, las consultas empiezan a acumular lógica de negocio, joins repetidos, filtros de seguridad y columnas calculadas. En ese punto, las vistas en SQL se vuelven una herramienta clave: con CREATE VIEW podemos encapsular una consulta y exponerla como si fuera una tabla lógica. En el artículo anterior vimos subqueries y subconsultas; ahora vamos a usar ese mismo nivel de composición para abstraer, asegurar y simplificar el acceso a datos.

Note

En este artículo analizaremos qué es una vista, cómo crearla con CREATE VIEW, por qué ayuda con seguridad, agregación, complejidad y datos distribuidos, y qué condiciones debe cumplir una vista para ser actualizable.

Qué es una vista

Una vista no es una tabla física. En términos prácticos, es una consulta guardada en la base de datos que puedes consultar con SELECT como si fuera una tabla. La vista no almacena los registros por sí misma; almacena la definición del query que se ejecutará cuando accedas a ella.

Esto reduce repetición y mejora la legibilidad. Si una consulta se usa todos los días, o si quieres exponer solo ciertas columnas a un equipo o aplicación, una vista ofrece una interfaz estable sobre las tablas base.

Consideremos una vista sobre la tabla customer:

CREATE VIEW customer_vw
 (customer_id,
 first_name,
 last_name,
 email 
 )
AS
SELECT 
 customer_id,
 first_name,
 last_name,
 concat(substr(email,1,2), '*****', substr(email, -4)) email
FROM customer;

En este ejemplo, la vista customer_vw expone customer_id, first_name, last_name y email. Observemos un detalle importante: el email no se entrega completo, sino enmascarado mediante concat() y substr().

Para usar la vista, la consultamos como cualquier otra relación:

mysql> SELECT first_name, last_name, email
 -> FROM customer_vw;
+-------------+--------------+-------------+
| first_name | last_name | email |
+-------------+--------------+-------------+
| MARY | SMITH | MA*****.org |
| PATRICIA | JOHNSON | PA*****.org |
| LINDA | WILLIAMS | LI*****.org |
| BARBARA | JONES | BA*****.org |
| ELIZABETH | BROWN | EL*****.org |
...
| ENRIQUE | FORSYTHE | EN*****.org |
| FREDDIE | DUGGAN | FR*****.org |
| WADE | DELVALLE | WA*****.org |
| AUSTIN | CINTRON | AU*****.org |
+-------------+--------------+-------------+
599 rows in set (0.00 sec)

La consulta queda más expresiva: en lugar de repetir el cálculo del email en cada reporte, centralizamos esa lógica en una vista.

Si necesitas inspeccionar la estructura de una vista, puedes usar DESCRIBE o su forma corta DESC:

mysql> describe customer_vw;
+-------------+----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+----------------------+------+-----+---------+-------+
| customer_id | smallint(5) unsigned | NO | | 0 | |
| first_name | varchar(45) | NO | | NULL | |
| last_name | varchar(45) | NO | | NULL | |
| email | varchar(11) | YES | | NULL | |
+-------------+----------------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

Tip

Puedes usar en vistas gran parte de lo que ya conoces de SQL: WHERE, ORDER BY, GROUP BY, funciones, expresiones calculadas e incluso JOIN. La vista encapsula la consulta; no elimina la necesidad de diseñarla correctamente.

Por qué usar vistas

Las vistas son útiles cuando necesitas definir una capa de acceso estable entre las tablas reales y los consumidores de datos. Esa capa puede servir para seguridad, reporting, simplificación de consultas o unificación de datos.

Seguridad de los datos

Cuando los usuarios consultan directamente las tablas base, pueden quedar expuestas columnas sensibles que no deberían estar disponibles para todos los perfiles. Una vista permite publicar solo las columnas necesarias y, si hace falta, transformar datos antes de mostrarlos.

El ejemplo de customer_vw aplica este patrón: el email se expone enmascarado. En una aplicación interna, podrías conceder permisos sobre la vista y evitar permisos directos sobre customer. Así reduces superficie de exposición sin duplicar datos.

Este enfoque también estabiliza contratos. Si la tabla base contiene más columnas en el futuro, los consumidores de la vista no las reciben automáticamente.

Agregar datos

Las vistas también funcionan bien para reportes o consultas agregadas. Si un equipo necesita revisar ventas por categoría de película, no tiene que escribir todos los JOIN cada vez.

CREATE VIEW sales_by_film_category
AS
SELECT
 c.name AS category,
 SUM(p.amount) AS total_sales
FROM payment AS p
 INNER JOIN rental AS r ON p.rental_id = r.rental_id
 INNER JOIN inventory AS i ON r.inventory_id = i.inventory_id
 INNER JOIN film AS f ON i.film_id = f.film_id
 INNER JOIN film_category AS fc ON f.film_id = fc.film_id
 INNER JOIN category AS c ON fc.category_id = c.category_id
GROUP BY c.name
ORDER BY total_sales DESC;

Esta vista encapsula una agregación de pagos por categoría. El consumidor puede ejecutar SELECT * FROM sales_by_film_category; y enfocarse en el resultado, no en la mecánica de las relaciones.

Info

Una vista con agregaciones no materializa necesariamente el resultado. En muchos motores, la consulta se evalúa al leer la vista. Si el reporte es costoso y se consulta con alta frecuencia, analiza índices, planes de ejecución o alternativas como vistas materializadas cuando tu motor las soporte.

Esconder complejidad

Otra ventaja importante es ocultar consultas complejas detrás de un nombre claro. Analicemos una vista que resume estadísticas de películas usando subconsultas:

CREATE VIEW film_stats
AS
SELECT f.film_id, f.title, f.description, f.rating,
 (SELECT c.name
 FROM category c
 INNER JOIN film_category fc
 ON c.category_id = fc.category_id
 WHERE fc.film_id = f.film_id) category_name,
 (SELECT count(*)
 FROM film_actor fa
 WHERE fa.film_id = f.film_id
 ) num_actors,
 (SELECT count(*)
 FROM inventory i
 WHERE i.film_id = f.film_id
 ) inventory_cnt,
 (SELECT count(*)
 FROM inventory i
 INNER JOIN rental r
 ON i.inventory_id = r.inventory_id
 WHERE i.film_id = f.film_id
 ) num_rentals
FROM film f;

Esta consulta mezcla columnas directas, subqueries correlacionadas y conteos derivados. Usar film_stats como interfaz simplifica el consumo y reduce errores de copia al reutilizar la lógica.

También mejora la comunicación técnica. Un nombre como film_stats expresa intención de negocio mejor que una consulta extensa pegada en múltiples servicios, dashboards o scripts.

Datos distribuidos o particionados

Las vistas pueden ayudar a unificar datos que viven en diferentes tablas. Si una tabla está particionada por año, por región o por tipo de entidad, una vista puede presentar una estructura más simple para quien consulta.

El objetivo no es ocultar decisiones arquitectónicas críticas, sino evitar que cada consumidor tenga que conocer todos los detalles físicos del modelo. Una vista puede funcionar como una API interna de lectura dentro de la base de datos.

Vistas actualizables

Hasta ahora hemos usado vistas para leer datos. Sin embargo, algunos motores permiten ejecutar UPDATE, INSERT o DELETE a través de una vista, siempre que la base de datos pueda mapear la operación de forma inequívoca hacia las tablas base.

No todas las vistas son actualizables. Mientras más transformación tenga una vista, más difícil será determinar qué fila y qué columna real debe modificarse.

Para que una vista sea actualizable, considera estas restricciones típicas:

No se usan funciones de agregación como max(), min(), avg(), sum() o similares.
La vista no utiliza cláusulas GROUP BY ni HAVING.
No existen subconsultas en el SELECT ni en el FROM; y las subconsultas en el WHERE, si existen, no hacen referencia a tablas del FROM.
La vista no utiliza UNION, UNION ALL ni DISTINCT.
La cláusula FROM incluye al menos una tabla o una vista actualizable.
Si hay más de una tabla o vista en el FROM, se usan únicamente INNER JOIN.

Warning

Las reglas exactas dependen del motor de base de datos. MySQL, PostgreSQL, SQL Server y Oracle tienen diferencias en sintaxis, permisos y casos soportados. Antes de depender de escrituras sobre vistas en producción, valida el comportamiento en tu motor específico.

Actualizando vistas simples

Supongamos nuevamente la vista customer_vw:

CREATE VIEW customer_vw
 (customer_id,
 first_name,
 last_name,
 email
 )
AS
SELECT
 customer_id,
 first_name,
 last_name,
 concat(substr(email,1,2), '*****', substr(email, -4)) email
FROM customer;

Podemos actualizar una columna directa de la tabla base, como last_name, usando la vista:

mysql> UPDATE customer_vw
 -> SET last_name = 'SMITH-ALLEN'
 -> WHERE customer_id = 1;
Query OK, 1 row affected (0.11 sec)
Rows matched: 1 Changed: 1 Warnings: 0

La operación funciona porque last_name corresponde directamente a una columna actualizable de customer. La vista actúa como una capa de acceso, pero el motor sabe qué valor modificar.

En cambio, si intentamos actualizar email, la operación falla:

mysql> UPDATE customer_vw
 -> SET email = 'MARY.SMITH-ALLEN@sakilacustomer.org'
 -> WHERE customer_id = 1;
ERROR 1348 (HY000): Column 'email' is not updatable

La razón es que email en la vista no es la columna original; es una expresión calculada con concat() y substr(). El motor no puede inferir cómo convertir el valor nuevo en una actualización válida de la columna base.

También debes tener cuidado con INSERT. Insertar a través de una vista falla cuando la vista no expone todas las columnas NOT NULL de la tabla base, por lo que el INSERT no puede proporcionar valores para ellas. Si esas columnas no tienen DEFAULT, el motor no tiene forma segura de completar la fila.

Conclusión

Las vistas en SQL son una herramienta de diseño para crear interfaces de datos más limpias. Con CREATE VIEW puedes encapsular consultas repetidas, proteger columnas sensibles, construir reportes agregados y esconder complejidad sin duplicar información.

También es importante reconocer sus límites. Una vista no reemplaza un buen diseño de índices, no siempre mejora rendimiento y no siempre permite escritura. Cuando una vista incluye agregaciones, expresiones calculadas, DISTINCT, UNION o subconsultas complejas, normalmente debes tratarla como una interfaz de lectura.

Como siguiente paso de la serie, analizaremos cómo proteger la consistencia y el rendimiento de operaciones más críticas con transacciones, índices y constraints.

TypeScript: Namespaces, módulos e importaciones

Dacadev — Tue, 23 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Décimo artículo de la serie sobre TypeScript. Organizaremos el código con namespaces y módulos ES: exportaciones nombradas, import, alias, export default y archivos barrel.

A medida que un proyecto crece, la organización del código deja de ser un detalle estético para convertirse en un factor de mantenibilidad. TypeScript ofrece dos mecanismos para estructurar el código: los namespaces —agrupadores internos— y los módulos ES —el estándar moderno basado en export e import. Analicemos cuándo usar cada uno.

Namespaces

Un namespace agrupa funciones, clases y variables relacionadas bajo un identificador común, exponiendo solo lo que marques con export:

namespace Validations {
 export const validateText = (text: string): boolean => {
 return text.length > 3
 }

 export const validateDate = (myDate: Date): boolean => {
 return !isNaN(myDate.valueOf())
 }
}

Validations.validateText('hola mundo')

Solo los miembros exportados (validateText, validateDate) son accesibles desde fuera mediante la notación Namespace.miembro.

Info

Los namespaces se usan cada vez menos en el desarrollo de aplicaciones, donde los módulos ES son el estándar. Sin embargo, siguen presentes como base interna de muchos frameworks y de archivos de definición de tipos (.d.ts).

Módulos: export e import

Los módulos son el mecanismo recomendado. Cada archivo es un módulo y expone su API con export; otros archivos la consumen con import. Para exportar, antepón export a la declaración:

// classes/Heros.ts
export class Hero {
 constructor(
 public name: string,
 public powerID: number,
 public age: number
 ) {}
}

Y para consumirla, usa import con desestructuración de los miembros nombrados:

// index.ts
import { Hero } from './classes/Heros'

const spiderman: Hero = new Hero('Spiderman', 100, 23)

Archivos barrel: centralizar exportaciones

Cuando una carpeta agrupa varios módulos relacionados, importarlos uno a uno desde rutas distintas se vuelve tedioso. Un archivo barrel —convencionalmente un index.ts dentro de la carpeta— reexporta todo desde un único punto de entrada:

// interfaces/index.ts
export { Hero } from './hero'
export { Villain } from './villain'

Esto permite importar múltiples miembros refiriéndote solo a la carpeta, lo que simplifica las rutas y desacopla a los consumidores de la estructura interna:

import { Hero, Villain } from './interfaces'

flowchart LR
 H[hero.ts] --> I[index.ts barrel]
 V[villain.ts] --> I
 I --> C[consumidor: import desde './interfaces']

Export alias

Un alias renombra un miembro al importarlo, lo que resuelve colisiones de nombres entre módulos distintos. Se usa la palabra clave as:

import { powers as poderes } from './data/powers'

console.log(poderes)

Export default

Una exportación por defecto designa el valor principal de un módulo. Se importa sin llaves y puede combinarse con importaciones nombradas en la misma línea:

// data/powers.ts
export default class Powers {
 /* ... */
}
export const powers = ['fuerza', 'velocidad']

import Powers, { powers as poderes } from './data/powers'

Powers corresponde a la exportación por defecto y poderes a una exportación nombrada renombrada con alias.

Tip

Prefiere las exportaciones nombradas frente a export default en bases de código grandes: facilitan el autocompletado, el refactoring automático y mantienen nombres consistentes entre el módulo y sus consumidores.

Del código a un bundle

Los módulos resuelven la organización en tiempo de desarrollo, pero el navegador necesita servir el resultado de forma eficiente. Empaquetadores como webpack combinan todos los módulos en uno o pocos archivos optimizados, resolviendo el grafo de dependencias que tejen tus import. TypeScript se integra en este flujo transpilando primero a JavaScript y dejando que el bundler se encargue del empaquetado final.

Conclusión

Estructurar el código es una decisión de arquitectura. Los namespaces agrupan elementos internos y persisten en definiciones de tipos, pero el estándar moderno son los módulos ES con export/import. Los archivos barrel centralizan las exportaciones, los alias resuelven colisiones de nombres y export default designa el valor principal de un módulo.

En el artículo final de la serie consolidaremos la configuración del compilador y la depuración de errores mediante tsconfig.json.

TypeScript: Decoradores y metaprogramación

Dacadev — Mon, 22 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Noveno artículo de la serie sobre TypeScript. Estudiaremos los decoradores: funciones que se ejecutan en la definición de clases, métodos y propiedades para extender su comportamiento sin modificar su código original.

Un decorador en TypeScript es una función que se ejecuta en tiempo de transpilación y permite expandir la funcionalidad de un objeto —clase, método o propiedad— de forma declarativa. Frameworks como Angular o NestJS apoyan gran parte de su ergonomía en este mecanismo. Analicemos cada variante con ejemplos prácticos. Puedes consultar la referencia completa en la documentación oficial de decoradores.

Info

Los decoradores se colocan con la sintaxis @nombre justo antes del elemento a decorar. Por convención se declaran con function —en lugar de arrow functions— para distinguirlos visualmente de las funciones ordinarias.

Decoradores de clase

Un decorador de clase recibe el constructor y se ejecuta una sola vez, en el momento en que se define la clase —no al crear cada instancia:

function printToConsole(constructor: Function) {
 console.log(constructor)
}

@printToConsole
export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'

 constructor(public name: string) {}
}

Al crear varias instancias, el decorador no vuelve a ejecutarse: su efecto ocurre en la definición, no en la instanciación.

Decoradores de fábrica

Un decorador de fábrica es una función que retorna el decorador real. Esto permite parametrizar el comportamiento, aceptando argumentos que controlan cómo se aplica:

function printToConsole(constructor: Function) {
 console.log(constructor)
}

const printToConsoleConditional = (print: boolean = true): Function => {
 return print ? printToConsole : () => {}
}

@printToConsoleConditional(false)
export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'
 constructor(public name: string) {}
}

Un patrón habitual es sellar el prototipo para impedir que se alteren sus propiedades en tiempo de ejecución:

const blockPrototype = function (constructor: Function) {
 Object.seal(constructor)
 Object.seal(constructor.prototype)
}

@blockPrototype
@printToConsoleConditional(false)
export class Pokemon {
 // ...
}

Tip

Cuando aplicas múltiples decoradores, se ejecutan de forma secuencial de abajo hacia arriba. En el ejemplo anterior, primero corre printToConsoleConditional y luego blockPrototype.

Decoradores de método

Un decorador de método recibe tres argumentos —el objeto al que pertenece, el nombre del método y su PropertyDescriptor— y puede inspeccionar o reemplazar por completo el comportamiento del método. Aquí lo usamos para validar argumentos:

function CheckValidPokemonId() {
 return function (
 target: any,
 propertyKey: string,
 descriptor: PropertyDescriptor
 ) {
 const originalMethod = descriptor.value

 descriptor.value = (id: number) => {
 if (id < 1 || id > 100) {
 return console.error('El id del pokemon debe estar entre 1 y 100')
 }
 return originalMethod(id)
 }
 }
}

export class Pokemon {
 public publicApi: string = 'https://pokeapi.co'
 constructor(public name: string) {}

 @CheckValidPokemonId()
 savePokemonToDB(id: number) {
 console.log(`Pokemon guardado en la base de datos ${id}`)
 }
}

Al envolver originalMethod, el decorador intercepta la llamada, valida el id y solo delega al método original cuando el valor es válido. Este es el fundamento de las validaciones declarativas de muchos frameworks.

Decoradores de propiedad

Un decorador de propiedad recibe el objeto y el nombre de la propiedad, y puede alterar cómo se lee y escribe. Es útil para controlar el acceso a datos —recordando que JavaScript no tiene propiedades verdaderamente privadas en runtime:

function readOnly(isWriteable: boolean = true): Function {
 return function (target: any, propertyKey: string) {
 const descriptor: PropertyDescriptor = {
 get() {
 return 'Daca code'
 },
 set(this, val) {
 Object.defineProperty(this, propertyKey, {
 value: val,
 writable: !isWriteable,
 enumerable: false
 })
 }
 }
 return descriptor
 }
}

export class Pokemon {
 @readOnly(false)
 private publicApi: string = 'https://pokeapi.co'

 constructor(public name: string) {}
}

El decorador define un get/set personalizado que gobierna por completo el acceso a publicApi.

Conclusión

Los decoradores aportan metaprogramación declarativa a TypeScript: el decorador de clase actúa sobre el constructor una única vez, el de fábrica parametriza el comportamiento, el de método intercepta y reemplaza llamadas, y el de propiedad controla la lectura y escritura. Componerlos en cadena —respetando su orden de ejecución— es lo que habilita las APIs elegantes de frameworks modernos.

En el próximo artículo organizaremos el código con namespaces y módulos: export, import, alias y exportaciones por defecto.

TypeScript: Tipos avanzados, subtipos y varianza

Dacadev — Sun, 21 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Octavo artículo de la serie sobre TypeScript. Abordaremos la teoría que sustenta el sistema de tipos: subtipos, supertipos, la jerarquía completa, los tipos unknown y never, y la varianza.

Comprender la relación entre tipos es lo que separa a quien usa TypeScript de quien lo domina. El compilador decide qué asignaciones son válidas aplicando reglas de subtipado y varianza. Una vez interiorizadas estas reglas, los errores del typechecker dejan de ser obstáculos crípticos y se convierten en información precisa sobre el diseño de tus tipos.

Subtipos

La regla fundamental del subtipado se enuncia así:

Info

Si tienes un tipo A y un tipo B donde B es subtipo de A, entonces puedes usar B en cualquier lugar donde se espere un A.

Algunas relaciones de subtipo en TypeScript:

Array es subtipo de Object.
Tuple es subtipo de Array.
Todo es subtipo de any.
never es subtipo de todo.
Si una clase Bird extiende Animal, entonces Bird es subtipo de Animal.

Aplicado a la práctica, esto significa que donde se necesite un Object puedes usar un Array; donde se necesite un Array puedes usar una Tuple; y donde se necesite un Animal puedes usar un Bird.

Supertipos

Un supertipo es la relación inversa:

Info

Si tienes un tipo A y un tipo B donde B es supertipo de A, entonces puedes usar A en cualquier lugar donde se espere un B.

Las relaciones de supertipo reflejan en espejo a las anteriores:

Array es supertipo de Tuple.
Object es supertipo de Array.
any es supertipo de todo.
Animal es supertipo de Bird.

La jerarquía de tipos

Todas estas relaciones forman una jerarquía con un tipo en la cúspide (top type) y otro en el fondo (bottom type):

flowchart TD
 Unknown[unknown - top type] --> Any[any]
 Any --> Number
 Any --> BigInt
 Any --> Boolean
 Any --> String
 Any --> Symbol
 Any --> Object
 Any --> Void
 Any --> Null
 Any --> Undefined
 Object --> Array
 Array --> Tuple
 Object --> Function
 Number --> Never[never - bottom type]
 String --> Never
 Boolean --> Never
 Object --> Never
 Tuple --> Never

unknown es el top type: todo es asignable a él, pero no permite operar sin acotar primero.
never es el bottom type: es subtipo de cualquier otro tipo y representa lo que nunca ocurre.

Los tipos especiales: null, undefined, void y never

Estos cuatro tipos modelan la ausencia de valor con matices distintos:

Tipo	Significado
`null`	Ausencia explícita de valor
`undefined`	Variable que aún no recibió un valor
`void`	Función que no tiene sentencia `return`
`never`	Función que nunca retorna

La distinción entre void y never es sutil pero importante. Una función void termina sin devolver nada útil; una función never no termina en absoluto, ya sea porque lanza una excepción o porque entra en un bucle infinito:

// void: termina, no retorna valor
function log(msg: string): void {
 console.log(msg)
}

// never: nunca completa su ejecución
function fail(message: string): never {
 throw new Error(message)
}

function loopForever(): never {
 while (true) {}
}

Tip

never es especialmente útil en la verificación de exhaustividad: si un switch cubre todos los casos de una unión, la rama default puede asignar el valor a un never, y el compilador detectará en tiempo de compilación cualquier caso olvidado al ampliar la unión.

Varianza

Determinar si un tipo es sub o supertipo de otro no siempre es evidente, sobre todo al combinar estructuras y funciones. TypeScript dispone de una notación formal para razonar sobre estas relaciones:

A <: B significa “A es subtipo de, o el mismo tipo que, B”.
A >: B significa “A es supertipo de, o el mismo tipo que, B”.

La varianza describe cómo se propagan estas relaciones cuando los tipos se anidan en estructuras (arreglos, objetos) o en firmas de función. Es el motivo por el que, por ejemplo, un arreglo de un subtipo no siempre es intercambiable con un arreglo de su supertipo: la mutabilidad introduce restricciones que el compilador debe respetar para mantener la solidez del sistema.

Conclusión

El sistema de tipos de TypeScript es una jerarquía gobernada por reglas de subtipado y varianza, con unknown como tipo superior y never como tipo inferior. Distinguir null, undefined, void y never, y comprender cómo B <: A permite sustituir un tipo por otro, te da una intuición precisa de por qué el compilador acepta o rechaza una asignación.

En el siguiente artículo aplicaremos metaprogramación con decoradores, funciones que extienden el comportamiento de clases, métodos y propiedades.

SQL: Subqueries y Tipos de JOIN Avanzados

Dacadev — Sat, 20 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando tus consultas SQL empiezan a mezclar filtros, agregaciones y relaciones entre tablas, los JOIN básicos dejan de ser suficientes para expresar ciertas reglas de negocio con claridad. Las subqueries o subconsultas en SQL permiten encapsular una consulta dentro de otra, reutilizar resultados intermedios y construir filtros más precisos sin mover lógica innecesaria a la aplicación. En el artículo anterior vimos consultas a múltiples tablas con JOINs; ahora vamos a extender esa base con subconsultas, EXISTS y tipos de JOIN más avanzados.

Note

En este artículo aprenderás a usar subqueries escalares, subconsultas de múltiples filas, subqueries correlacionadas, el operador EXISTS, LEFT OUTER JOIN, CROSS JOIN y NATURAL JOIN.

Qué es una subquery en SQL

Una subquery es una consulta contenida dentro de otra sentencia SQL. A la sentencia externa la llamaremos consulta contenedora o consulta principal. La subquery siempre va entre paréntesis y, en muchos motores, se evalúa antes de que la consulta principal termine de resolver su filtro o su conjunto de datos.

Como cualquier consulta, una subquery puede retornar diferentes formas de resultado:

Una sola fila con una sola columna.
Múltiples filas con una sola columna.
Múltiples filas con múltiples columnas.

Analicemos un primer ejemplo. Queremos obtener el cliente con el customer_id más alto:

mysql> SELECT customer_id, first_name, last_name
 -> FROM customer
 -> WHERE customer_id = (SELECT MAX(customer_id) FROM customer);
+-------------+------------+-----------+
| customer_id | first_name | last_name |
+-------------+------------+-----------+
| 599 | AUSTIN | CINTRON |
+-------------+------------+-----------+
1 row in set (0.27 sec)

La subquery (SELECT MAX(customer_id) FROM customer) retorna un único valor. Por eso podemos compararla con = en el WHERE de la consulta principal.

Info

Cuando una subquery retorna una fila y una sola columna, se comporta como una subquery escalar. Puedes usarla con operadores como =, <>, !=, >, >=, < y <=.

Tipos de subqueries

No todas las subconsultas tienen el mismo comportamiento. La diferencia más importante está en si la subquery depende o no de la consulta principal.

Subqueries no correlacionadas

Las subqueries no correlacionadas no dependen directamente de la consulta contenedora. Puedes ejecutarlas por separado, inspeccionar su resultado y luego entender cómo ese resultado alimenta el WHERE, HAVING o incluso el FROM de la consulta principal.

El ejemplo anterior es una subquery no correlacionada. Observemos otro caso: obtener todas las ciudades cuyo país no sea India.

mysql> SELECT city_id, city
 -> FROM city
 -> WHERE country_id <> 
 -> (SELECT country_id FROM country WHERE country = 'India');
+---------+----------------------------+
| city_id | city |
+---------+----------------------------+
| 1 | A Corua (La Corua) |
| 2 | Abha |
| 3 | Abu Dhabi |
| 4 | Acua |
...
| 599 | Zhoushan |
| 600 | Ziguinchor |
+---------+----------------------------+
540 rows in set (0.02 sec)

Aquí la subquery retorna el country_id asociado a India. La consulta principal usa ese valor para excluir todas las ciudades que pertenezcan a ese país.

Warning

Si usas = con una subquery que retorna más de un valor, el motor no puede comparar un valor escalar contra un conjunto de filas. En ese caso necesitas operadores como IN, ANY, ALL o reestructurar la consulta.

Subqueries de múltiples filas y una columna

Cuando una subquery retorna varias filas pero una sola columna, IN suele ser el operador adecuado. Este operador compara el valor del lado izquierdo contra el conjunto de valores retornado por la subquery.

Consideremos una consulta para obtener ciudades de Canadá o México:

mysql> SELECT city_id, city
 -> FROM city
 -> WHERE country_id IN
 -> (SELECT country_id
 -> FROM country
 -> WHERE country IN ('Canada','Mexico'));
+---------+----------------------------+
| city_id | city |
+---------+----------------------------+
| 179 | Gatineau |
| 196 | Halifax |
| 300 | Lethbridge |
| 313 | London |
...
| 556 | Uruapan |
| 595 | Zapopan |
+---------+----------------------------+
37 rows in set (0.00 sec)

La subquery retorna los country_id de ambos países. Luego IN filtra las ciudades cuyo country_id esté dentro de ese conjunto.

Subqueries multicolumna

Las subqueries multicolumna retornan más de una columna y son útiles cuando necesitas comparar combinaciones de valores o enriquecer la lógica de selección. En SQL también es común resolver este tipo de necesidad con varias subqueries coordinadas, especialmente cuando cada filtro opera sobre una dimensión diferente.

Observemos este caso: queremos encontrar pares actor_id y film_id donde el actor tenga apellido MONROE y la película tenga clasificación PG.

mysql> SELECT fa.actor_id, fa.film_id
 -> FROM film_actor fa
 -> WHERE fa.actor_id IN
 -> (SELECT actor_id FROM actor WHERE last_name = 'MONROE')
 -> AND fa.film_id IN
 -> (SELECT film_id FROM film WHERE rating = 'PG');
+----------+---------+
| actor_id | film_id |
+----------+---------+
| 120 | 63 |
| 120 | 144 |
| 120 | 414 |
...
| 178 | 983 |
+----------+---------+
11 rows in set (0.00 sec)

Esta consulta combina dos filtros independientes: uno sobre actores y otro sobre películas. El resultado final sale de la tabla intermedia film_actor, que representa la relación muchos-a-muchos.

Subqueries correlacionadas

Hasta ahora, las subqueries han sido independientes. Una subquery correlacionada, en cambio, depende de la consulta principal porque referencia una o más columnas de la fila que se está evaluando afuera.

Esto cambia el modelo mental: la subquery no se ejecuta una sola vez para producir un conjunto estático, sino que puede evaluarse por cada fila candidata de la consulta externa. Por eso conviene revisar su costo, especialmente en tablas grandes.

Analicemos una consulta que obtiene clientes con exactamente 20 rentas:

mysql> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE 20 =
 -> (SELECT count(*) FROM rental r
 -> WHERE r.customer_id = c.customer_id);
+------------+-------------+
| first_name | last_name |
+------------+-------------+
| LAUREN | HUDSON |
| JEANETTE | GREENE |
| TARA | RYAN |
| WILMA | RICHARDS |
...
| ALFREDO | MCADAMS |
+------------+-------------+
15 rows in set (0.01 sec)

La parte clave es r.customer_id = c.customer_id. La subquery necesita el customer_id de la fila actual de customer, por eso está correlacionada.

El operador EXISTS

El operador EXISTS valida si la subquery retorna al menos una fila. No importa qué columnas seleccione la subquery; lo relevante es la existencia de registros que cumplan la condición.

Por convención, muchas consultas usan SELECT 1 dentro de EXISTS para indicar que el valor retornado no es importante:

mysql> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE EXISTS
 -> (SELECT 1 FROM rental r
 -> WHERE r.customer_id = c.customer_id
 -> AND date(r.rental_date) < '2005-05-25');
+------------+-------------+
| first_name | last_name |
+------------+-------------+
| CHARLOTTE | HUNTER |
| DELORES | HANSEN |
| MINNIE | ROMERO |
...
| NELSON | CHRISTENSON |
+------------+-------------+
8 rows in set (0.03 sec)

EXISTS es especialmente expresivo cuando la pregunta de negocio es binaria: “incluye esta fila si existe al menos una relación que cumple la condición”.

Tip

Usa EXISTS cuando quieras comprobar existencia y IN cuando quieras comparar contra un conjunto concreto de valores. Ambos pueden ser optimizados por el motor, pero expresan intenciones distintas.

JOINs avanzados: revisitando las uniones

Hasta este punto de la serie hemos trabajado principalmente con INNER JOIN. Ese tipo de unión retorna únicamente las filas que cumplen la condición en ambas tablas. Sin embargo, SQL ofrece variantes útiles para preservar filas sin coincidencias, generar combinaciones cartesianas o delegar la condición de unión al motor.

Outer joins

Los outer joins retornan las filas que cumplen la condición de unión y, además, conservan filas de una tabla aunque no tengan coincidencias del otro lado. En un LEFT OUTER JOIN, se preservan todas las filas de la tabla de la izquierda.

Observemos un conteo de copias por película:

mysql> SELECT f.film_id, f.title, count(i.inventory_id) num_copies
 -> FROM film f
 -> LEFT OUTER JOIN inventory i
 -> ON f.film_id = i.film_id
 -> GROUP BY f.film_id, f.title;
+---------+-----------------------------+------------+
| film_id | title | num_copies |
+---------+-----------------------------+------------+
| 1 | ACADEMY DINOSAUR | 8 |
| 2 | ACE GOLDFINGER | 3 |
| 3 | ADAPTATION HOLES | 4 |
| 4 | AFFAIR PREJUDICE | 7 |
...
| 14 | ALICE FANTASIA | 0 |
...
| 999 | ZOOLANDER FICTION | 5 |
| 1000 | ZORRO ARK | 8 |
+---------+-----------------------------+------------+
1000 rows in set (0.01 sec)

ALICE FANTASIA aparece con 0 copias porque no tiene registros asociados en inventory. Aun así, el LEFT OUTER JOIN conserva la película porque film está a la izquierda.

Veamos la misma situación sin agregación:

mysql> SELECT f.film_id, f.title, i.inventory_id
 -> FROM film f
 -> LEFT OUTER JOIN inventory i
 -> ON f.film_id = i.film_id
 -> WHERE f.film_id BETWEEN 13 AND 15;
+---------+----------------+--------------+
| film_id | title | inventory_id |
+---------+----------------+--------------+
| 13 | ALI FOREVER | 67 |
| 13 | ALI FOREVER | 68 |
| 13 | ALI FOREVER | 69 |
| 13 | ALI FOREVER | 70 |
| 14 | ALICE FANTASIA | NULL |
| 15 | ALIEN CENTER | 71 |
| 15 | ALIEN CENTER | 72 |
| 15 | ALIEN CENTER | 73 |
| 15 | ALIEN CENTER | 74 |
| 15 | ALIEN CENTER | 75 |
| 15 | ALIEN CENTER | 76 |
+---------+----------------+--------------+
11 rows in set (0.00 sec)

El NULL en inventory_id indica que no existe fila relacionada en la tabla derecha.

Outer joins de tres tablas

Puedes encadenar OUTER JOIN para preservar filas a través de varias relaciones. En este tipo de consulta, el orden importa porque define qué conjunto de filas se conserva en cada paso.

mysql> SELECT f.film_id, f.title, i.inventory_id, r.rental_date
 -> FROM film f
 -> LEFT OUTER JOIN inventory i
 -> ON f.film_id = i.film_id
 -> LEFT OUTER JOIN rental r
 -> ON i.inventory_id = r.inventory_id
 -> WHERE f.film_id BETWEEN 13 AND 15;
+---------+----------------+--------------+---------------------+
| film_id | title | inventory_id | rental_date |
+---------+----------------+--------------+---------------------+
| 13 | ALI FOREVER | 67 | 2005-07-31 18:11:17 |
| 13 | ALI FOREVER | 67 | 2005-08-22 21:59:29 |
| 13 | ALI FOREVER | 68 | 2005-07-28 15:26:20 |
...
| 14 | ALICE FANTASIA | NULL | NULL |
| 15 | ALIEN CENTER | 71 | 2005-05-28 02:06:37 |
...
| 15 | ALIEN CENTER | 76 | 2005-08-17 07:26:47 |
+---------+----------------+--------------+---------------------+
32 rows in set (0.01 sec)

Tip

Aunque existe RIGHT OUTER JOIN, en muchos equipos se prefiere estandarizar en LEFT OUTER JOIN. Mantiene la lectura de izquierda a derecha y reduce cambios mentales al revisar consultas complejas.

Cross joins

Un CROSS JOIN produce un producto cartesiano: combina cada fila de la primera tabla con cada fila de la segunda. Es útil para generar matrices de combinaciones, calendarios, catálogos base o escenarios de prueba, pero puede crecer muy rápido.

mysql> SELECT c.name category_name, l.name language_name
 -> FROM category c
 -> CROSS JOIN language l;
+---------------+---------------+
| category_name | language_name |
+---------------+---------------+
| Action | English |
| Action | Italian |
| Action | Japanese |
...
| Travel | English |
| Travel | German |
+---------------+---------------+
96 rows in set (0.00 sec)

Si category tiene 16 filas y language tiene 6, el resultado tendrá 96 filas. Esa multiplicación es exactamente el comportamiento esperado.

Natural joins

NATURAL JOIN deja que el motor determine las columnas de unión usando columnas con el mismo nombre en ambas tablas. Es importante conocerlo, pero no suele ser buena práctica en consultas de producción porque oculta la condición real del JOIN.

El siguiente ejemplo no retorna filas:

mysql> SELECT c.first_name, c.last_name, date(r.rental_date)
 -> FROM customer c
 -> NATURAL JOIN rental r;
Empty set (0.04 sec)

El problema es que customer y rental pueden compartir más columnas de las que realmente queremos usar como condición natural. Al proyectar únicamente las columnas necesarias desde customer, el NATURAL JOIN puede comportarse como esperamos:

mysql> SELECT cust.first_name, cust.last_name, date(r.rental_date)
 -> FROM
 -> (SELECT customer_id, first_name, last_name
 -> FROM customer
 -> ) cust
 -> NATURAL JOIN rental r;
+------------+-----------+---------------------+
| first_name | last_name | date(r.rental_date) |
+------------+-----------+---------------------+
| MARY | SMITH | 2005-05-25 |
| MARY | SMITH | 2005-05-28 |
| MARY | SMITH | 2005-06-15 |
...
| AUSTIN | CINTRON | 2005-08-23 |
+------------+-----------+---------------------+
16044 rows in set (0.03 sec)

Warning

Prefiere JOIN ... ON ... cuando la consulta debe ser mantenible. La condición explícita documenta la intención y evita cambios inesperados si el esquema gana nuevas columnas con nombres compartidos.

Conclusión

Las subqueries en SQL te permiten expresar reglas de negocio que dependen de resultados intermedios sin salir del motor de base de datos. Las subconsultas no correlacionadas son ideales para filtros basados en conjuntos estáticos; las correlacionadas son útiles cuando cada fila externa necesita una evaluación específica; y EXISTS comunica con claridad validaciones de existencia.

En el lado de los JOIN, LEFT OUTER JOIN conserva filas sin coincidencias, CROSS JOIN genera combinaciones cartesianas y NATURAL JOIN delega la condición al motor, aunque conviene usarlo con cuidado. La clave es elegir la herramienta que haga más explícita la intención de la consulta.

En el siguiente artículo de la serie vamos a trabajar con Vistas (Views), una forma práctica de encapsular consultas y exponer modelos de lectura reutilizables dentro de la base de datos.

TypeScript: Genéricos y código reutilizable

Dacadev — Sat, 20 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Séptimo artículo de la serie sobre TypeScript. Exploraremos los genéricos: funciones y clases que operan sobre tipos dinámicos sin renunciar a la verificación estática.

Los genéricos en TypeScript resuelven una tensión recurrente: escribir código reutilizable que funcione con cualquier tipo, pero sin caer en any y perder toda la seguridad. Un genérico introduce un parámetro de tipo —una variable que representa un tipo aún por determinar— que se resuelve en el momento de uso. Analicemos cómo aplicarlos.

Funciones genéricas

Una función genérica declara su parámetro de tipo con la sintaxis <T> antes de la lista de parámetros. T representa el tipo que recibirá, y la función puede usarlo para tipar argumentos y retorno:

// Función tradicional
export function genericFunction<T>(argumento: T): T {
 return argumento
}

// Arrow function
export const genericArrowFunction = <T>(argumento: T): T => argumento

La función anterior retorna exactamente el mismo tipo que recibe. Si la invocas con un string, TypeScript sabe que el retorno es string; si la invocas con un number, el retorno es number. Esto es lo que distingue a un genérico de any: la relación entre entrada y salida se preserva.

Info

T es el nombre convencional, pero es arbitrario. Para múltiples parámetros suelen usarse T, U, K, V, o nombres descriptivos como TItem cuando aportan claridad.

Por qué no basta con any

Comparemos las dos aproximaciones para entender el valor de los genéricos:

// Con any: se pierde la información de tipo
function identityAny(arg: any): any {
 return arg
}
const a = identityAny('hola') // a es any → sin autocompletado ni verificación

// Con genéricos: el tipo se conserva
function identity<T>(arg: T): T {
 return arg
}
const b = identity('hola') // b es string → seguridad completa

Con any, el resultado pierde todo su tipo y el typechecker deja de ayudar. Con un genérico, la firma encadena el tipo de entrada con el de salida.

Clases genéricas

Las clases también admiten parámetros de tipo, lo que permite construir estructuras de datos reutilizables y type-safe. El parámetro se declara junto al nombre de la clase y queda disponible en todos sus miembros:

class MyMap<K, V> {
 constructor(initialKey: K, initialValue: V) {
 // ...
 }
 get(key: K): V {
 // ...
 }
 set(key: K, value: V): void {
 // ...
 }
 static of<K, V>(k: K, v: V): MyMap<K, V> {
 // ...
 }
}

Al instanciarla, los tipos pueden indicarse explícitamente o inferirse de los argumentos:

let a = new MyMap<string, number>('k', 1) // MyMap<string, number>
let b = new MyMap('k', true) // MyMap<string, boolean> (inferido)

a.get('k')
b.set('k', false)

flowchart LR
 G["MyMap&lt;K, V&gt;"] --> A["MyMap&lt;string, number&gt;"]
 G --> B["MyMap&lt;string, boolean&gt;"]
 G --> C["MyMap&lt;number, Hero&gt;"]

Una sola definición genérica genera tantas variantes type-safe como combinaciones de tipos uses.

Restringir genéricos con extends

A veces un genérico no debe aceptar cualquier tipo, sino solo aquellos que cumplan cierta forma. La cláusula extends impone esa restricción y, a la vez, habilita el acceso seguro a los miembros garantizados:

function getLength<T extends { length: number }>(item: T): number {
 return item.length
}

getLength('hola') // OK: string tiene length
getLength([1, 2, 3]) // OK: array tiene length
getLength(42) // Error: number no tiene 'length'

T extends { length: number } restringe T a tipos que posean una propiedad length, permitiendo usarla con seguridad dentro de la función.

Conclusión

Los genéricos son la herramienta que permite escribir código verdaderamente reutilizable sin sacrificar la verificación de tipos. Las funciones genéricas encadenan el tipo de entrada con el de salida, las clases genéricas habilitan estructuras de datos type-safe, y las restricciones con extends acotan los tipos aceptados mientras exponen sus miembros de forma segura.

En el próximo artículo abordaremos los tipos avanzados: subtipos, supertipos, varianza y la jerarquía completa del sistema de tipos.

TypeScript: Clases, herencia y patrones de diseño

Dacadev — Fri, 19 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Sexto artículo de la serie sobre TypeScript. Recorreremos las clases: herencia, modificadores de acceso, clases abstractas, super, getters/setters, miembros estáticos, tipado estructural y los patrones de diseño que habilitan.

Las clases en TypeScript parten de la sintaxis de JavaScript y la enriquecen con modificadores de acceso, clases abstractas y tipado estructural. El resultado es un modelo de orientación a objetos cercano al de lenguajes como C++ o Java, pero que compila a JavaScript estándar. Analicemos sus capacidades.

Clases y herencia

La declaración usa class y la herencia se establece con extends:

class Piece {}

class King extends Piece {}
class Queen extends Piece {}
class Bishop extends Piece {}

Podemos restringir los atributos a valores concretos combinando clases con tipos literales:

type Color = 'Black' | 'White'
type File = 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H'
type Rank = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

class Position {
 constructor(
 private file: File,
 private rank: Rank
 ) {}
}

Declarar los parámetros del constructor con un modificador (private file: File) es un atajo: TypeScript crea y asigna la propiedad automáticamente, evitando el habitual this.file = file.

Modificadores de acceso

TypeScript define tres niveles de visibilidad para atributos y métodos:

public: accesible desde cualquier lugar. Es el nivel por defecto.
protected: accesible desde la propia clase y sus subclases.
private: accesible únicamente desde la propia clase.

class Avenger {
 constructor(
 private name: string,
 public team: string,
 public realName?: string
 ) {}

 public bio() {
 return `${this.name} ${this.team}`
 }

 private bioInterno() {
 return `${this.realName} ${this.team}`
 }
}

Warning

private y protected solo aplican en tiempo de compilación. El JavaScript emitido no impide el acceso en runtime; para privacidad real en ejecución usa los campos privados nativos de JavaScript (#campo).

Clases abstractas

Una clase abstract define una plantilla que no puede instanciarse, pero sirve de esqueleto para sus subclases. Puede declarar miembros concretos y miembros abstract que las subclases están obligadas a implementar:

abstract class Mutante {
 constructor(
 public name: string,
 public realName: string
 ) {}
}

class Xmen extends Mutante {
 public saveWorld() {
 return 'Mundo salvado'
 }
}

class Villano extends Mutante {
 public conquistWorld() {
 return 'Mundo conquistado'
 }
}

const wolverine = new Xmen('Wolverine', 'Logan')
const magneto = new Villano('Magneto', 'Magnus')

Una ventaja adicional: una función puede aceptar cualquier objeto que herede de la clase abstracta, lo que habilita el polimorfismo:

const printName = (character: Mutante) => {
 console.log(character.name)
}

printName(wolverine)
printName(magneto)

super: invocar a la clase padre

Cuando una subclase sobrescribe un método del padre, puede invocar la versión original con super.metodo(). Si la subclase define un constructor, debe llamar a super() para inicializar correctamente la cadena de herencia:

class Xmen extends Avenger {
 constructor(name: string, realName: string, public isMutant: boolean) {
 super(name, realName)
 }

 public getFullNameDesdeXmen() {
 return super.getFullName()
 }
}

Getters y setters

Los accessors exponen métodos que se comportan sintácticamente como atributos, facilitando la lectura y asignación controladas:

class Xmen extends Avenger {
 get fullName() {
 return `${this.name} - ${this.realName}`
 }

 set fullName(name: string) {
 this.realName = name
 }
}

const wolverine = new Xmen('Wolverine', 'Logan', true)
console.log(wolverine.fullName) // se lee como atributo
wolverine.fullName = 'David' // se asigna como atributo

Miembros estáticos

Los miembros static pertenecen a la clase, no a sus instancias:

class Avenger {
 static avgAge: number = 35
 static getAvgAge() {
 return Avenger.avgAge
 }
}

console.log(Avenger.avgAge) // se accede vía la clase

this como tipo de retorno

Cuando un método retorna la propia instancia, su tipo de retorno es this. Esto es la base del encadenamiento de métodos (method chaining):

class Set {
 add(value: number): this {
 // ...
 return this
 }
}

Tipado estructural

TypeScript verifica las clases por estructura, no por nombre. Dos tipos compatibles en forma son intercambiables, con una salvedad: los miembros private rompen la compatibilidad estructural:

class A {
 private x = 1
}
class B extends A {}

function f(a: A) {}

f(new A()) // OK
f(new B()) // OK
f({ x: 1 }) // Error TS2345: 'x' es private en 'A' pero no en '{x: number}'.

Constructor privado

Un constructor private impide instanciar la clase desde fuera, lo que permite controlar su creación. Es la base del patrón singleton:

class Apocalipsis {
 private static instance: Apocalipsis

 private constructor(public name: string) {}

 static getInstance(): Apocalipsis {
 if (!Apocalipsis.instance) {
 Apocalipsis.instance = new Apocalipsis('Soy Apocalipsis... el único')
 }
 return Apocalipsis.instance
 }
}

const apocalipsis = Apocalipsis.getInstance()

Patrones de diseño habilitados

Factory Pattern

Centraliza la creación de objetos detrás de una función que decide la clase concreta:

type Shoe = { purpose: string }

class BalletFlat implements Shoe { purpose = 'dancing' }
class Boot implements Shoe { purpose = 'woodcutting' }
class Sneaker implements Shoe { purpose = 'walking' }

let Shoe = {
 create(type: 'balletFlat' | 'boot' | 'sneaker'): Shoe {
 switch (type) {
 case 'balletFlat': return new BalletFlat()
 case 'boot': return new Boot()
 case 'sneaker': return new Sneaker()
 }
 }
}

Builder Pattern

Construye un objeto paso a paso mediante métodos que retornan this, habilitando una API fluida:

class RequestBuilder {
 private data: object | null = null
 private method: 'get' | 'post' | null = null
 private url: string | null = null

 setMethod(method: 'get' | 'post'): this {
 this.method = method
 return this
 }
 setData(data: object): this {
 this.data = data
 return this
 }
 setURL(url: string): this {
 this.url = url
 return this
 }

 send() {
 // ...
 }
}

new RequestBuilder().setURL('/api').setMethod('post').setData({}).send()

Conclusión

Las clases de TypeScript ofrecen un modelo de orientación a objetos completo: herencia, modificadores de acceso, clases abstractas para polimorfismo, accessors, miembros estáticos y un tipado estructural con la salvedad de los miembros privados. Estas piezas son el fundamento de patrones de diseño como Factory, Builder y Singleton.

En el siguiente artículo abordaremos los genéricos, la herramienta para escribir código reutilizable sin sacrificar la seguridad de tipos.

Estilos CSS: Animaciones con @keyframes

Dacadev — Thu, 18 Jun 2026 00:00:00 -0500

Tabla de Contenido

Una transición anima el salto entre dos estados; pero cuando necesitas movimiento continuo, varios pasos intermedios o una secuencia que se repite —un spinner de carga, un latido, un texto que aparece— necesitas algo más expresivo. Ahí entran las animaciones con @keyframes, el sistema de CSS para describir secuencias de movimiento complejas de forma declarativa, sin una sola línea de JavaScript.

Esta entrega extiende la serie Estilos CSS, retomando justo donde lo dejaron las transiciones y transformaciones. Cubriremos la regla @keyframes, todas las subpropiedades de animation, y las consideraciones de accesibilidad y rendimiento que separan una animación profesional de una que marea al usuario.

Note

Aprenderás a definir secuencias con @keyframes, a controlarlas con la propiedad animation y sus ocho subpropiedades, y a respetar las preferencias de movimiento del usuario con prefers-reduced-motion.

Transición vs. animación

Aunque ambas producen movimiento, resuelven problemas distintos:

Una transición (transition) interpola entre el estado actual y uno nuevo. Necesita un disparador —un :hover, un cambio de clase— y va de un punto A a un punto B.
Una animación (animation) ejecuta una secuencia definida en @keyframes. No necesita disparador: puede arrancar sola, repetirse indefinidamente y pasar por múltiples estados intermedios.

Info

Regla práctica: usa transition para cambios de estado provocados por interacción; usa animation para movimiento autónomo, cíclico o multipaso.

La regla @keyframes

Una animación se define en dos partes: la secuencia (con @keyframes) y su aplicación (con la propiedad animation). La regla @keyframes recibe un nombre y describe los estados de la animación en distintos momentos, expresados como porcentajes del 0% al 100% (o con las palabras clave from y to).

@keyframes aparecer {
 from { opacity: 0; transform: translateY(1rem); }
 to { opacity: 1; transform: translateY(0); }
}

.elemento {
 animation: aparecer 0.6s ease-out;
}

Aparezco con fade + desplazamiento

La secuencia se repite para que puedas observarla.

Múltiples pasos con porcentajes

El verdadero poder de @keyframes aparece con pasos intermedios. Cada porcentaje es una “foto” del estado en ese momento de la animación:

@keyframes latido {
 0% { transform: scale(1); }
 15% { transform: scale(1.25); }
 30% { transform: scale(1); }
 45% { transform: scale(1.15); }
 60% { transform: scale(1); }
}

♥

La propiedad animation y sus subpropiedades

animation es una propiedad abreviada que agrupa ocho subpropiedades. Conviene conocerlas por separado para tener control fino:

Subpropiedad	Función	Ejemplo
`animation-name`	Nombre del `@keyframes` a ejecutar	`aparecer`
`animation-duration`	Duración de un ciclo	`0.6s`
`animation-timing-function`	Curva de progreso	`ease-in-out`
`animation-delay`	Espera antes de iniciar	`200ms`
`animation-iteration-count`	Número de repeticiones	`infinite`
`animation-direction`	Sentido de reproducción	`alternate`
`animation-fill-mode`	Estilos antes/después de animar	`forwards`
`animation-play-state`	Reproducir o pausar	`paused`

La forma abreviada las combina en una sola declaración:

.spinner {
 animation: girar 1s linear infinite;
 /* name | duration | timing-function | iteration-count */
}

iteration-count y direction

animation-iteration-count define cuántas veces se ejecuta (infinite para un bucle perpetuo). animation-direction controla el sentido:

normal — siempre de 0% a 100%.
reverse — siempre de 100% a 0%.
alternate — alterna ida y vuelta en cada ciclo.
alternate-reverse — igual, pero empezando al revés.

El caso clásico es un spinner de carga, que combina rotación infinita con velocidad constante:

@keyframes girar { to { transform: rotate(360deg); } }

.spinner { animation: girar 0.8s linear infinite; }

fill-mode: el estado antes y después

Por defecto, un elemento vuelve a su estilo original en cuanto la animación termina. animation-fill-mode cambia ese comportamiento:

none (por defecto) — no conserva estilos fuera de la ejecución.
forwards — mantiene el estado del último keyframe al terminar.
backwards — aplica el primer keyframe durante el delay, antes de arrancar.
both — combina forwards y backwards.

forwards es esencial cuando quieres que el elemento permanezca en su estado final (por ejemplo, un mensaje que aparece y se queda visible):

.toast {
 animation: aparecer 0.5s ease-out forwards;
}

play-state y delay

animation-play-state permite pausar (paused) y reanudar (running) una animación, típicamente al combinarla con :hover. Aquí, la barra de progreso se anima sola pero se congela al pasar el cursor:

@keyframes cargar { from { width: 0; } to { width: 100%; } }

.barra__relleno { animation: cargar 3s ease-in-out infinite; }
.barra:hover .barra__relleno { animation-play-state: paused; }

Pasa el cursor sobre la barra para pausar la animación.

Encadenar varias animaciones

Puedes aplicar varias animaciones a un mismo elemento separándolas con comas. Cada una mantiene su propia duración, retraso y curva, lo que permite componer comportamientos independientes:

.elemento {
 animation:
 aparecer 0.5s ease-out,
 flotar 3s ease-in-out 0.5s infinite alternate;
}

Floto suavemente

Accesibilidad: respeta prefers-reduced-motion

El movimiento excesivo puede causar mareos o malestar a personas con sensibilidad vestibular. Los sistemas operativos exponen una preferencia de “reducir movimiento”, y CSS la consulta con la media query prefers-reduced-motion. Es una responsabilidad profesional desactivar o atenuar las animaciones no esenciales cuando el usuario lo solicita:

@media (prefers-reduced-motion: reduce) {
 *,
 *::before,
 *::after {
 animation-duration: 0.01ms !important;
 animation-iteration-count: 1 !important;
 transition-duration: 0.01ms !important;
 }
}

Warning

Ignorar prefers-reduced-motion es un fallo de accesibilidad real. Reserva las animaciones llamativas para lo decorativo y asegúrate de que la interfaz siga siendo plenamente funcional cuando el movimiento se reduce.

Rendimiento: anima en la capa de composición

La misma regla de oro de las transiciones aplica aquí: anima propiedades que solo afecten la etapa de composición del navegador —transform y opacity— en lugar de propiedades que disparen layout o paint (width, height, top, left, margin).

/* ❌ Costoso: recalcula layout en cada frame */
@keyframes mover-malo { to { left: 200px; } }

/* ✅ Eficiente: solo composición, fluido a 60 fps */
@keyframes mover-bien { to { transform: translateX(200px); } }

Tip

Si una animación se ve entrecortada, lo primero que debes revisar es qué propiedades estás animando. Reescribir un left/top como transform: translate() suele eliminar el jank de inmediato.

Conclusión

Las animaciones con @keyframes te dan un lenguaje declarativo para describir movimiento complejo: secuencias multipaso, bucles infinitos y comportamientos compuestos, todo en CSS puro. Dominar la propiedad animation y sus subpropiedades —especialmente fill-mode, iteration-count y play-state— te permite construir spinners, indicadores de carga y microinteracciones pulidas. Y recuerda: anima transform y opacity, y respeta siempre prefers-reduced-motion.

Note

🚀 Con esta entrega completas el recorrido de la serie Estilos CSS: desde la cascada y los selectores hasta el layout, el posicionamiento, los fondos, las transformaciones y, ahora, las animaciones. Tienes el repertorio completo para escribir CSS expresivo, accesible y de alto rendimiento.

TypeScript: Interfaces y contratos de tipos

Dacadev — Thu, 18 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Quinto artículo de la serie sobre TypeScript. Estudiaremos las interfaces como contratos extensibles, su herencia con extends, su implementación en clases con implements, y sus diferencias frente a los alias de tipo.

Una interface en TypeScript define la forma que deben cumplir los objetos. A primera vista se parece a un alias de tipo, pero su rasgo distintivo es la extensibilidad: las interfaces están diseñadas para componerse, heredarse y servir como base de contratos más complejos. Analicemos cuándo y cómo usarlas.

Bases: definir y extender interfaces

Una interface declara la estructura de un objeto. Con extends, una interface puede heredar de otra y ampliar su contrato:

interface Hero {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

interface Avenger extends Hero {
 marvel: string;
}

let flash: Hero = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

Avenger hereda todos los miembros de Hero y añade marvel. Esta composición es la base del diseño orientado a contratos.

Estructuras complejas: interfaces anidadas

Las interfaces pueden referenciarse entre sí para modelar estructuras de datos compuestas:

interface Client {
 name: string;
 age?: number;
 address?: Address;
}

interface Address {
 id: number;
 zip: string;
 city: string;
}

const client: Client = {
 name: 'David',
 address: {
 id: 125,
 zip: 'KYD 234',
 city: 'Chía'
 }
}

const client2: Client = {
 name: 'Melissa',
 age: 30
}

Client referencia a Address como un campo opcional, lo que permite componer entidades de dominio sin acoplarlas en una sola definición monolítica.

Métodos en la interfaz

Al igual que los alias de tipo, las interfaces pueden declarar métodos como parte del contrato:

interface Client {
 name: string;
 age?: number;
 address?: Address;
 getFullAddress(id: string): void;
}

Info

Declarar métodos en una interface es válido, pero implica que el objeto que la cumpla debe implementarlos. En la práctica, cuando un contrato requiere comportamiento, lo más limpio es implementarlo mediante una clase.

Implementar interfaces en clases

Una clase adopta uno o varios contratos con la palabra clave implements. Esto garantiza, en compilación, que la clase provee todo lo que el contrato exige:

interface Xmen {
 name: string;
 realName: string;
 mutantPower(id: number): string;
}

interface Human {
 age: number;
}

class Mutant implements Xmen, Human {
 public age: number;
 public name: string;
 public realName: string;

 mutantPower(id: number): string {
 return 'Hola mundo';
 }
}

Mutant implementa simultáneamente Xmen y Human. Si omitiera cualquier miembro requerido, el compilador lo rechazaría.

Interfaces para tipar funciones

Aunque es poco frecuente, una interface puede describir la firma de una función antes de asignarle una implementación:

interface AddTwoNumbers {
 (a: number, b: number): number;
}

let addNumbers: AddTwoNumbers;

addNumbers = (a: number, b: number): number => a + b

Interfaces frente a alias de tipo

Esta es la decisión de diseño más común. Las tres diferencias clave:

1. Composición

Los alias de tipo componen mediante operaciones de conjuntos (|, &); las interfaces componen mediante extends:

type Food = { calories: number; tasty: boolean }
type Sushi = Food & { salty: boolean }

interface FoodI { calories: number; tasty: boolean }
interface SushiI extends FoodI { salty: boolean }

2. Restricción al extender

Al extender una interface, no puedes cambiar el tipo de un miembro heredado, solo añadir o restringir de forma compatible. Una incompatibilidad genera error:

interface A {
 good(x: number): string
 bad(x: number): string
}

interface B extends A {
 good(x: string | number): string
 bad(x: string): string // Error TS2430: 'B' extiende incorrectamente 'A'.
}

3. Declaration merging

Varias interfaces con el mismo nombre en el mismo ámbito se fusionan automáticamente; varios alias de tipo con el mismo nombre producen un error de compilación:

interface User { name: string }
interface User { age: number } // se fusiona

let a: User = { name: 'Ashley', age: 30 }

type User = { name: string } // Error TS2300: identificador duplicado
type User = { age: number } // Error TS2300

El declaration merging respeta los tipos existentes: no puedes redefinir un miembro ya declarado con otro tipo.

flowchart TD
 Q{¿Necesitas extensibilidad,<br/>implements o merging?}
 Q -- Sí --> I[Usa interface]
 Q -- "No (uniones, tuplas, mapeos)" --> T[Usa type]

Implementación con readonly y múltiples contratos

Las interfaces admiten propiedades readonly y permiten que una clase cumpla varios contratos a la vez:

interface Animal {
 readonly name: string
 eat(food: string): void
 sleep(hours: number): void
}

interface Feline {
 meow(): void
}

class Cat implements Animal, Feline {
 name = 'Whiskers'
 eat(food: string) { console.info('Ate some', food) }
 sleep(hours: number) { console.info('Slept for', hours, 'hours') }
 meow() { console.info('Meow') }
}

Conclusión

Las interfaces son el mecanismo de TypeScript para definir contratos extensibles y verificables. Elige una interface cuando necesites herencia con extends, implementación en clases con implements o declaration merging; reserva los alias de tipo para uniones, intersecciones, tuplas y tipos mapeados.

En el próximo artículo profundizaremos en las clases, la herencia, los modificadores de acceso y los patrones de diseño que habilitan.

SQL: Consultas a Múltiples Tablas con JOINs

Dacadev — Wed, 17 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una aplicación modela procesos reales, una sola tabla rara vez contiene todo el contexto. Clientes requieren direcciones, películas requieren actores y reportes operativos combinan varias entidades. Por eso, dominar consultas a múltiples tablas y entender cada JOIN en SQL es clave para escribir consultas correctas, expresivas y mantenibles.

En el artículo anterior trabajamos agrupamiento y funciones agregadas. Ahora conectaremos ese análisis con relaciones entre tablas.

Note

Aprenderás a usar INNER JOIN, unir tres o más tablas, reutilizar tablas con alias, aplicar SELF JOIN y combinar resultados con UNION, INTERSECT y EXCEPT.

Producto cartesiano

El producto cartesiano aparece cuando haces un JOIN entre dos tablas sin definir la condición que relaciona sus filas. SQL combina cada fila de la primera tabla con cada fila de la segunda.

mysql> SELECT c.first_name, c.last_name, a.address
 -> FROM customer c JOIN address a;
+------------+-----------+----------------------+
| first_name | last_name | address |
+------------+-----------+----------------------+
| MARY | SMITH | 47 MySakila Drive |
| PATRICIA | JOHNSON | 47 MySakila Drive |
| LINDA | WILLIAMS | 47 MySakila Drive |
...
| FREDDIE | DUGGAN | 1325 Fukuyama Street |
| WADE | DELVALLE | 1325 Fukuyama Street |
| AUSTIN | CINTRON | 1325 Fukuyama Street |
+------------+-----------+----------------------+
361197 rows in set (0.03 sec)

El resultado tiene 361,197 filas porque customer tiene 599 registros y address tiene 603: 599 * 603 = 361197. Normalmente esto indica que falta una condición ON.

Warning

Un JOIN sin condición explícita puede multiplicar el volumen de datos y degradar el rendimiento. Revisa siempre que exista una relación clara entre las tablas.

Inner Join

El INNER JOIN retorna solo las filas que tienen coincidencia en ambas tablas según la condición definida en ON.

mysql> SELECT c.first_name, c.last_name, a.address
 -> FROM customer c JOIN address a
 -> ON c.address_id = a.address_id;
+-------------+--------------+----------------------------------------+
| first_name | last_name | address |
+-------------+--------------+----------------------------------------+
| MARY | SMITH | 1913 Hanoi Way |
| PATRICIA | JOHNSON | 1121 Loja Avenue |
| LINDA | WILLIAMS | 692 Joliet Street |
...
| FREDDIE | DUGGAN | 1103 Quilmes Boulevard |
| WADE | DELVALLE | 1331 Usak Boulevard |
| AUSTIN | CINTRON | 1325 Fukuyama Street |
+-------------+--------------+----------------------------------------+
599 rows in set (0.00 sec)

Aunque muchos motores interpretan JOIN como INNER JOIN, escribirlo explícitamente mejora la legibilidad cuando aparecen otros tipos de unión.

SELECT c.first_name, c.last_name, a.address
FROM customer c INNER JOIN address a
 ON c.address_id = a.address_id;

Unir 3 o más tablas

Para unir más de dos tablas, repetimos el patrón: otro INNER JOIN y otra condición ON.

mysql> SELECT c.first_name, c.last_name, ct.city
 -> FROM customer c
 -> INNER JOIN address a
 -> ON c.address_id = a.address_id
 -> INNER JOIN city ct
 -> ON a.city_id = ct.city_id;
+-------------+--------------+----------------------------+
| first_name | last_name | city |
+-------------+--------------+----------------------------+
| JULIE | SANCHEZ | A Corua (La Corua) |
| PEGGY | MYERS | Abha |
| TOM | MILNER | Abu Dhabi |
...
| BYRON | BOX | Zhezqazghan |
| GUY | BROWNLEE | Zhoushan |
| RONNIE | RICKETTS | Ziguinchor |
+-------------+--------------+----------------------------+
599 rows in set (0.03 sec)

Info

SQL es declarativo: describes qué resultado necesitas y el optimizador decide cómo ejecutarlo. El orden textual de las tablas no necesariamente define el orden físico del plan.

Subqueries como tablas

Una subquery puede actuar como tabla derivada dentro de un JOIN.

SELECT c.first_name, c.last_name, addr.address, addr.city
 -> FROM customer c
 -> INNER JOIN
 -> (SELECT a.address_id, a.address, ct.city
 -> FROM address a
 -> INNER JOIN city ct
 -> ON a.city_id = ct.city_id
 -> WHERE a.district = 'California'
 -> ) addr
 -> ON c.address_id = addr.address_id;
+------------+-----------+------------------------+----------------+
| first_name | last_name | address | city |
+------------+-----------+------------------------+----------------+
| PATRICIA | JOHNSON | 1121 Loja Avenue | San Bernardino |
| BETTY | WHITE | 770 Bydgoszcz Avenue | Citrus Heights |
| ALICE | STEWART | 1135 Izumisano Parkway | Fontana |
...
| JACOB | LANCE | 1866 al-Qatif Avenue | El Monte |
| RENE | MCALISTER | 1895 Zhezqazghan Drive | Garden Grove |
+------------+-----------+------------------------+----------------+
9 rows in set (0.00 sec)

Aquí addr contiene direcciones de California junto con su ciudad, y luego se une con customer mediante address_id.

Misma tabla dos veces

Algunas consultas necesitan aplicar condiciones distintas sobre la misma entidad. Para eso usamos alias diferentes, incluso si la tabla física es la misma.

mysql> SELECT f.title
 -> FROM film f
 -> INNER JOIN film_actor fa1
 -> ON f.film_id = fa1.film_id
 -> INNER JOIN actor a1
 -> ON fa1.actor_id = a1.actor_id
 -> INNER JOIN film_actor fa2
 -> ON f.film_id = fa2.film_id
 -> INNER JOIN actor a2
 -> ON fa2.actor_id = a2.actor_id
 -> WHERE (a1.first_name = 'CATE' AND a1.last_name = 'MCQUEEN')
 -> AND (a2.first_name = 'CUBA' AND a2.last_name = 'BIRCH');
+------------------+
| title |
+------------------+
| BLOOD ARGONAUTS |
| TOWERS HURRICANE |
+------------------+
2 rows in set (0.00 sec)

Esta consulta busca películas donde participaron ambos actores. Si declaramos la tabla una sola vez y usamos OR, el significado cambia: buscamos películas donde participó cualquiera de los dos.

mysql> SELECT f.title
 -> FROM film f
 -> INNER JOIN film_actor fa
 -> ON f.film_id = fa.film_id
 -> INNER JOIN actor a
 -> ON fa.actor_id = a.actor_id
 -> WHERE ((a.first_name = 'CATE' AND a.last_name = 'MCQUEEN')
 -> OR (a.first_name = 'CUBA' AND a.last_name = 'BIRCH'));
+----------------------+
| title |
+----------------------+
| ATLANTIS CAUSE |
| BLOOD ARGONAUTS |
| COMMANDMENTS EXPRESS |
...
| VOLCANO TEXAS |
| WATERSHIP FRONTIER |
+----------------------+
54 rows in set (0.00 sec)

Self join

Un self join ocurre cuando una tabla se une consigo misma. Es común en relaciones autorreferenciales: empleados y managers, categorías padre e hijas, o películas y precuelas.

mysql> SELECT f.title, f_prnt.title prequel
 -> FROM film f
 -> INNER JOIN film f_prnt
 -> ON f_prnt.film_id = f.prequel_film_id
 -> WHERE f.prequel_film_id IS NOT NULL;
+-----------------+--------------+
| title | prequel |
+-----------------+--------------+
| FIDDLER LOST II | FIDDLER LOST |
+-----------------+--------------+
1 row in set (0.00 sec)

f representa la película actual y f_prnt representa la película relacionada como precuela. Los alias son obligatorios para evitar ambigüedad.

Teoría de conjuntos

SQL también trabaja con conjuntos completos de filas. Estas operaciones combinan resultados de múltiples consultas, siempre que las columnas sean compatibles.

La unión combina los elementos de A y B.

La intersección conserva únicamente los elementos presentes en ambos conjuntos.

La diferencia retorna los elementos de A que no están en B.

Note

Para aplicar operaciones de conjuntos, ambas consultas deben retornar el mismo número de columnas y columnas compatibles por posición.

UNION

UNION combina resultados y elimina duplicados. UNION ALL conserva todos los registros, por lo que suele ser más eficiente cuando no necesitas deduplicar.

mysql> SELECT 'CUST' typ, c.first_name, c.last_name
 -> FROM customer c
 -> UNION ALL
 -> SELECT 'ACTR' typ, a.first_name, a.last_name
 -> FROM actor a;
+------+------------+-------------+
| typ | first_name | last_name |
+------+------------+-------------+
| CUST | MARY | SMITH |
| CUST | PATRICIA | JOHNSON |
| CUST | LINDA | WILLIAMS |
...
| ACTR | MARY | KEITEL |
| ACTR | JULIA | FAWCETT |
| ACTR | THORA | TEMPLE |
+------+------------+-------------+
799 rows in set (0.00 sec)

Si duplicamos la misma consulta contra actor, UNION ALL devuelve dos copias de cada fila.

mysql> SELECT 'ACTR' typ, a.first_name, a.last_name
 -> FROM actor a
 -> UNION ALL
 -> SELECT 'ACTR' typ, a.first_name, a.last_name
 -> FROM actor a;
+------+-------------+--------------+
| typ | first_name | last_name |
+------+-------------+--------------+
| ACTR | PENELOPE | GUINESS |
| ACTR | NICK | WAHLBERG |
| ACTR | ED | CHASE |
...
| ACTR | MARY | KEITEL |
| ACTR | JULIA | FAWCETT |
| ACTR | THORA | TEMPLE |
+------+-------------+--------------+
400 rows in set (0.00 sec)

Un ejemplo más claro muestra duplicados al combinar clientes y actores con patrones similares:

mysql> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE c.first_name LIKE 'J%' AND c.last_name LIKE 'D%'
 -> UNION ALL
 -> SELECT a.first_name, a.last_name
 -> FROM actor a
 -> WHERE a.first_name LIKE 'J%' AND a.last_name LIKE 'D%';
+------------+-----------+
| first_name | last_name |
+------------+-----------+
| JENNIFER | DAVIS |
| JENNIFER | DAVIS |
| JUDY | DEAN |
| JODIE | DEGENERES |
| JULIANNE | DENCH |
+------------+-----------+
5 rows in set (0.00 sec)

INTERSECT

INTERSECT retorna únicamente las filas presentes en ambos conjuntos. Dependiendo del motor, puede existir INTERSECT ALL, que conserva duplicados según sus reglas.

Es útil para encontrar coincidencias entre fuentes: identificadores compartidos, productos presentes en dos catálogos o usuarios existentes en dos procesos.

EXCEPT

EXCEPT retorna las filas del primer conjunto que no aparecen en el segundo. También puede existir EXCEPT ALL, según el motor.

Esta operación es práctica para auditoría y reconciliación de datos.

Warning

Algunos motores no implementan INTERSECT, EXCEPT o sus variantes ALL. En esos casos puedes modelar equivalentes con JOIN, NOT EXISTS o LEFT JOIN.

Reglas de operaciones de conjuntos

Las operaciones de conjuntos son estrictas: mismo número de columnas, tipos compatibles y mismo orden.

Ordenar resultados con alias válidos

Si ordenas el resultado final, usa los nombres expuestos por el primer SELECT. En este ejemplo, last_name y first_name ya no son etiquetas válidas porque fueron renombradas como lname y fname.

-- ERROR
mysql> SELECT a.first_name fname, a.last_name lname
 -> FROM actor a
 -> WHERE a.first_name LIKE 'J%' AND a.last_name LIKE 'D%'
 -> UNION ALL
 -> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE c.first_name LIKE 'J%' AND c.last_name LIKE 'D%'
 -> ORDER BY last_name, first_name;
ERROR 1054 (42S22): Unknown column 'last_name' in 'order clause'

-- WORKS
mysql> SELECT a.first_name fname, a.last_name lname
 -> FROM actor a
 -> WHERE a.first_name LIKE 'J%' AND a.last_name LIKE 'D%'
 -> UNION ALL
 -> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE c.first_name LIKE 'J%' AND c.last_name LIKE 'D%'
 -> ORDER BY lname, fname;
+----------+-----------+
| fname | lname |
+----------+-----------+
| JENNIFER | DAVIS |
| JENNIFER | DAVIS |
| JUDY | DEAN |
| JODIE | DEGENERES |
| JULIANNE | DENCH |
+----------+-----------+
5 rows in set (0.00 sec)

El orden de las operaciones importa

Las uniones se evalúan según el orden y la precedencia del motor. Cuando mezcles UNION, INTERSECT y EXCEPT, usa paréntesis para expresar intención y evitar resultados ambiguos.

Reglas prácticas:

Los alias visibles provienen del primer SELECT.
UNION elimina duplicados; UNION ALL los conserva.
ORDER BY se aplica al conjunto final, salvo que uses subqueries.
El orden de operaciones puede cambiar el resultado.

Cierre

Los JOINs y las operaciones de conjuntos resuelven problemas complementarios. INNER JOIN conecta filas relacionadas; UNION, INTERSECT y EXCEPT combinan resultados compatibles.

Dominar ambos enfoques mejora la semántica de reportes, filtros e integraciones. En el siguiente artículo avanzaremos hacia Subqueries, donde veremos subconsultas para construir lógica SQL modular.

TypeScript: Funciones, parámetros y generadores

Dacadev — Wed, 17 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Cuarto artículo de la serie sobre TypeScript. Cubriremos el tipado de funciones: parámetros, tipos de retorno, parámetros opcionales y por defecto, el operador resto, call signatures, generadores e iteradores.

Las funciones son el núcleo de cualquier base de código, y es justo donde el tipado aporta más valor: una firma bien tipada documenta el contrato de entrada y salida, y convierte cualquier llamada inválida en un error de compilación. Analicemos cómo TypeScript modela las funciones en toda su variedad.

Declaración y tipado de funciones

Una función tipada declara el tipo de cada parámetro y, opcionalmente, el tipo de retorno:

function add(a: number, b: number): number {
 return a + b
}

TypeScript admite todas las formas de definir funciones de JavaScript, y a todas les aplica el mismo sistema de tipos:

// Named function
function greet(name: string) {
 return 'hello ' + name
}

// Function expression
let greet2 = function (name: string) {
 return 'hello ' + name
}

// Arrow function
let greet3 = (name: string) => {
 return 'hello ' + name
}

// Shorthand arrow function
let greet4 = (name: string) => 'hello ' + name

El tipado de los parámetros intercepta llamadas inválidas en el sitio exacto del error:

add(1) // Error TS2554: se esperaban 2 argumentos, se recibió 1.
add(1, 'a') // Error TS2345: 'string' no es asignable a 'number'.

Parámetros opcionales y por defecto

Un parámetro opcional se marca con ? y debe gestionarse dentro del cuerpo, ya que puede llegar como undefined:

function log(message: string, userId?: string) {
 let time = new Date().toLocaleTimeString()
 console.log(time, message, userId || 'Not signed in')
}

log('Page loaded')
log('User signed in', 'da763be')

Un parámetro con valor por defecto se vuelve opcional automáticamente, y TypeScript infiere su tipo a partir del valor asignado:

function log(message: string, userId = 'Not signed in') {
 let time = new Date().toISOString()
 console.log(time, message, userId)
}

Warning

Los parámetros opcionales deben ubicarse después de todos los obligatorios, y no pueden combinarse con el operador resto.

También puedes apoyarte en un type para estructurar parámetros de configuración:

type Context = {
 appId?: string
 userId?: string
}

function log(message: string, context: Context = {}) {
 let time = new Date().toISOString()
 console.log(time, message, context.userId)
}

Operador resto: funciones variádicas

El operador resto captura un número dinámico de argumentos en un arreglo tipado, lo que produce firmas más legibles que recibir un arreglo explícito:

// Recibe un arreglo
function sum(numbers: number[]): number {
 return numbers.reduce((total, n) => total + n, 0)
}
sum([1, 2, 3]) // 6

// Variádica con operador resto
function sumVariadicSafe(...numbers: number[]): number {
 return numbers.reduce((total, n) => total + n, 0)
}
sumVariadicSafe(1, 2, 3) // 6

call, apply y bind

TypeScript respeta los mecanismos clásicos de invocación de JavaScript, aplicando la verificación de tipos a sus argumentos:

function add(a: number, b: number): number {
 return a + b
}

add(10, 20) // 30
add.apply(null, [10, 20]) // 30
add.call(null, 10, 20) // 30
add.bind(null, 10, 20)() // 30

Generadores

Los generadores producen valores bajo demanda. Se declaran con un asterisco tras function y emiten valores con yield:

function* createFibonacciGenerator() {
 let a = 0
 let b = 1
 while (true) {
 yield a
 ;[a, b] = [b, a + b]
 }
}

let fib = createFibonacciGenerator() // IterableIterator<number>
fib.next() // { value: 0, done: false }
fib.next() // { value: 1, done: false }
fib.next() // { value: 1, done: false }
fib.next() // { value: 2, done: false }

El método next() extrae el siguiente valor de la secuencia. TypeScript infiere el tipo IterableIterator<number> a partir de lo que produce yield.

Iteradores

Un iterador se define implementando el método [Symbol.iterator]. TypeScript es capaz de reconocer la estructura y tiparla correctamente:

let numbers = {
 *[Symbol.iterator]() {
 for (let n = 1; n <= 10; n++) {
 yield n
 }
 }
}

Call signatures

Una call signature describe el tipo de una función de forma independiente a su implementación. Para la siguiente función:

function sum(a: number, b: number): number {
 return a + b
}

su firma de llamada se expresa así:

(a: number, b: number) => number

El tipo genérico Function es un comodín que no aporta información sobre la firma concreta; las call signatures permiten tipar funciones con precisión. Además, cuando una función puede retornar varios tipos, cada uno debe tratarse para satisfacer al typechecker:

function area(radius: number): number | null {
 if (radius < 0) {
 return null
 }
 return Math.PI * radius ** 2
}

let a = area(3)
if (a !== null) {
 console.info('result:', a) // dentro del guard, a es number
}

Conclusión

El tipado de funciones convierte cada firma en un contrato verificable: parámetros opcionales y por defecto modelan flexibilidad controlada, el operador resto expresa funciones variádicas con claridad, las call signatures tipan funciones como ciudadanos de primera clase, y los generadores e iteradores se integran sin fricción en el sistema de tipos.

En el siguiente artículo abordaremos las interfaces, el mecanismo de TypeScript para definir contratos extensibles.

Estilos CSS: Modularización y patrones de diseño

Dacadev — Tue, 16 Jun 2026 00:00:00 -0500

Tabla de Contenido

En un proyecto pequeño cualquier organización de CSS funciona. El problema aparece al escalar: hojas de estilo de miles de líneas donde tocar una regla rompe tres componentes que parecían no tener relación. La causa casi siempre es la misma: estilos acoplados que se pisan entre sí. La solución es arquitectónica —modularizar— y existen metodologías probadas para lograrlo.

Esta es la octava y última entrega de la serie Estilos CSS. Veremos cómo estructurar estilos en módulos independientes, la metodología BEM, las clases de utilidad y cómo documentar tus componentes con una librería de patrones.

Note

Aprenderás a dividir tus estilos en componentes desacoplados, a nombrar clases con BEM, a usar utility classes con criterio y a mantener una librería de patrones como fuente única de verdad del diseño.

Qué es la modularización

Modularizar CSS consiste en dividir los estilos en archivos donde cada uno representa un módulo: un único componente con todo su estilo encapsulado. Un módulo button.css contiene todo lo necesario para renderizar un botón y sus variantes, y nada más.

Tip

La regla de oro: un módulo no debe interferir con los estilos de otros. Solo se ocupa de su propio componente. Así, modificar un módulo nunca produce efectos colaterales inesperados en el resto de la página.

Estilos base

Antes de los módulos conviene tener un archivo de estilos base: no es un componente, sino la configuración inicial del documento (reset, tipografía global, box-sizing).

:root { box-sizing: border-box; }

*, *::before, *::after { box-sizing: inherit; }

body { font-family: Helvetica, Arial, sans-serif; }

Para no reinventar la rueda, paquetes como Normalize.css homogeneizan las diferencias entre navegadores de forma sensata.

Componentes y BEM

La idea central de un módulo es que los estilos y modificadores de un componente vivan en un solo lugar. La metodología BEM (Block, Element, Modifier) propone una convención de nombres que hace explícita la estructura y evita colisiones:

Block — el componente raíz: .button.
Element — una parte del componente, con __: .button__icon.
Modifier — una variante, con --: .button--success.

.button {
 padding: 0.5em 0.8em;
 border: 1px solid #265559;
 border-radius: 0.2em;
 background-color: transparent;
 font-size: 1rem;
}

.button--success { color: #fff; background-color: #2f5926; border-color: #cfe8c9; }
.button--danger { color: #fff; background-color: #a92323; border-color: #e8c9c9; }
.button--small { font-size: 0.8rem; }
.button--large { font-size: 1.2rem; }

<button class="button">Normal</button>
<button class="button button--success">Éxito</button>
<button class="button button--danger">Peligro</button>
<button class="button button--large">Grande</button>

Posicionamiento del componente

Por buena práctica, el bloque raíz de un componente debería declarar position: relative. Así estableces un contexto de posicionamiento controlado para cualquier elemento absoluto interno (un menú desplegable, un badge, un tooltip), sin depender de ancestros externos.

Estado de los componentes

Es común reflejar el estado de un componente con clases, ya sea para estilizarlo o para manipularlo desde JavaScript. La convención recomendada usa verbos o estados con prefijo: is-loading, has-error, is-active.

Warning

No mezcles las clases de estado con los modificadores BEM. Evita nombres como block__element--modifier-is-loading. El estado es una capa transversal y dinámica; mantenlo separado de la variante estática del componente.

Utility classes

Las clases de utilidad aplican un estilo único y específico. Suelen usar !important para garantizar que se apliquen por encima de los estilos del componente:

.text-center { text-align: center !important; }
.float-left { float: left; }
.hidden { display: none !important; }

.clearfix::before,
.clearfix::after { content: " "; display: table; }
.clearfix::after { clear: both; }

Son útiles para ajustes puntuales, pero abusar de ellas reintroduce el acoplamiento que la modularización busca evitar. Úsalas con criterio.

Metodologías de arquitectura CSS

BEM no es la única opción. Las metodologías más establecidas para organizar CSS a escala son:

OOCSS — Object-Oriented CSS, de Nicole Sullivan: separa estructura de apariencia.
SMACSS — Scalable and Modular Architecture for CSS, de Jonathan Snook: categoriza las reglas en capas.
BEM — Block, Element, Modifier, de Yandex: convención de nombres explícita.
ITCSS — Inverted Triangle CSS, de Harry Roberts: organiza por especificidad creciente.

No son excluyentes; muchos equipos combinan ITCSS para la estructura de archivos con BEM para la nomenclatura.

Librerías de patrones

En proyectos grandes, los componentes se documentan en una librería de patrones (o style guide): una web accesible para todo el equipo que muestra cómo se ve y se comporta cada componente. Es la fuente única de verdad del diseño y reduce las inconsistencias.

Existen generadores de style guides; uno open source muy conocido es KSS. Documenta los componentes a partir de comentarios estructurados en el propio CSS:

/*
Buttons

Botones disponibles en varios tamaños y colores.

Markup:
<button class="button {{modifier_class}}">click here</button>

.button--success - Botón verde de éxito
.button--danger - Botón rojo de peligro
.button--large - Botón grande

Styleguide Buttons
*/
.button { /* ... */ }

KSS lee esos comentarios y genera automáticamente una página de documentación con el componente renderizado y todas sus variantes. El bloque incluye un título, una descripción, el Markup de ejemplo (con el marcador {{modifier_class}}), la lista de modificadores y una referencia Styleguide para ubicarlo en la jerarquía.

Info

Mantener la documentación junto al código —en comentarios del propio CSS— reduce el riesgo de que la librería de patrones quede desactualizada respecto a la implementación real.

Conclusión

Escribir CSS que escale es, ante todo, un problema de arquitectura. Modularizar en componentes desacoplados, nombrar con una convención consistente como BEM, reservar las utility classes para ajustes puntuales y documentar todo en una librería de patrones es lo que mantiene una hoja de estilos sana a medida que el proyecto crece.

Con esta entrega cerramos la serie Estilos CSS. Recorrimos desde los fundamentos de la cascada hasta la arquitectura de estilos a gran escala, pasando por selectores, el modelo de caja, layouts, posicionamiento, fondos y animaciones. Tienes ahora un modelo mental completo para escribir CSS profesional, predecible y mantenible.

Note

🚀 Repasa las entregas anteriores para consolidar cada concepto: los fundamentos sostienen los selectores, el modelo de caja sostiene los layouts, y la modularización une todo en un sistema coherente.

TypeScript: Objetos y tipos personalizados

Dacadev — Tue, 16 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Tercer artículo de la serie sobre TypeScript. Diseñaremos la forma de nuestros objetos con tipos personalizados, definiremos campos opcionales y métodos, y permitiremos que una variable acepte múltiples tipos.

Modelar correctamente la estructura de los objetos es donde TypeScript empieza a pagar dividendos en proyectos reales. Un tipo personalizado bien diseñado centraliza la definición de una entidad, propaga su forma por todo el código y convierte cualquier desviación en un error de compilación. Analicemos cómo pasar de objetos literales sueltos a un modelo de tipos mantenible.

Objetos literales y la inferencia estructural

Los objetos literales funcionan igual que en JavaScript, pero TypeScript infiere automáticamente su estructura. Esa inferencia es justamente lo que impide reasignar un objeto con una forma distinta:

let flash = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

flash = { name2: 'Otro nombre' }
// Error: el literal solo puede especificar propiedades conocidas;
// 'name2' no existe en el tipo inferido y faltan 'name', 'age', 'powers'.

TypeScript bloquea la reasignación porque el nuevo literal no respeta la forma deducida de flash. Este comportamiento evita introducir campos accidentales o incompletos.

Tipar objetos de forma inline

Podemos declarar explícitamente la forma del objeto usando la misma sintaxis de anotación que venimos aplicando, incluyendo campos opcionales con ?:

let flash: { name: string, age?: number, powers: string[] } = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

flash = {
 name: 'Clark Kent',
 powers: ['volar', 'rayo láser'] // 'age' es opcional, puede omitirse
}

Info

La posición de un campo opcional dentro de la anotación es irrelevante. age? puede ir en medio de la definición sin afectar la validez de los objetos que lo omitan.

El problema de este enfoque inline es la duplicación: si dos variables deben compartir la misma forma, hay que repetir la anotación completa en cada una y mantenerlas sincronizadas manualmente. Esto no escala.

Tipos personalizados con type

La solución es definir la estructura una sola vez con la palabra clave type y reutilizarla en todo el código. Esto centraliza el modelo en un único punto de verdad:

type Hero = {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

let flash: Hero = {
 name: 'Barry Allen',
 age: 24,
 powers: ['super velocidad', 'viajar en el tiempo']
}

let superman: Hero = {
 name: 'Clark Kent',
 age: 30,
 powers: ['volar', 'rayo láser'],
 getName() {
 return this.name;
 }
}

El tipo Hero declara name y powers como obligatorios, age como opcional y getName como un método opcional cuya firma es () => string. Cualquier objeto anotado con Hero debe respetar este contrato, y un solo cambio en la definición se propaga a todas las variables que lo usan.

flowchart TD
 T[type Hero] --> A[flash: Hero]
 T --> B[superman: Hero]
 T --> C[...otros héroes]
 note["Un cambio en Hero<br/>se propaga a todos"] -.-> T

Tip

Define un type para toda entidad que aparezca más de una vez. La regla práctica: si copiarías la anotación inline por segunda vez, conviértela en un tipo personalizado.

Permitir múltiples tipos con uniones

Una variable puede aceptar más de un tipo mediante el operador de unión |. Esto resulta útil para valores que legítimamente cambian de forma según el contexto:

type Hero = {
 name: string;
 age?: number;
 powers: string[];
 getName?: () => string;
}

let myCustomVariable: Hero | string | number = '¡Hola mundo!'

myCustomVariable = 42 // válido: number
myCustomVariable = { // válido: Hero
 name: 'Diana',
 powers: ['fuerza sobrehumana']
}

myCustomVariable puede contener un Hero, un string o un number. El typechecker permitirá únicamente operaciones válidas para todos los miembros de la unión hasta que acotes el tipo con un type guard (por ejemplo, typeof o una comprobación de propiedad).

Conclusión

Pasar de objetos literales inline a tipos personalizados con type es el salto que transforma TypeScript de una simple validación a una herramienta de diseño. Un tipo centraliza la forma de una entidad, los campos opcionales modelan la realidad de los datos incompletos, los métodos definen comportamiento esperado y las uniones aportan flexibilidad controlada.

En el próximo artículo de la serie abordaremos las funciones: anotación de parámetros, tipos de retorno, parámetros opcionales y sobrecargas.

TypeScript: Tipos básicos y el sistema de tipos

Dacadev — Mon, 15 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Segundo artículo de la serie sobre TypeScript. Recorreremos el alfabeto de tipos del lenguaje: desde any y unknown hasta uniones, intersecciones, tuplas y alias de tipo.

Cuando el typechecker sabe que un valor es de tipo T, no solo conoce su naturaleza: también sabe exactamente qué operaciones son válidas sobre ese valor y cuáles no. Ese es el propósito del sistema de tipos. Comprender el catálogo de tipos básicos en TypeScript es la base sobre la que se construye todo lo demás, así que dediquémosle la atención que merece.

Por qué importan los tipos: un ejemplo concreto

Los tipos transmiten intención de forma explícita y verificable. Comparemos la misma función en JavaScript y en TypeScript:

// JavaScript
function squareOf(n) {
 return n * n
}
squareOf(2) // 4
squareOf('z') // NaN — falla en silencio

// TypeScript
function squareOf(n: number) {
 return n * n
}
squareOf(2) // 4
squareOf('z') // Error TS2345: el argumento de tipo 'string' no es
 // asignable al parámetro de tipo 'number'.

En JavaScript, squareOf('z') devuelve NaN sin protestar y el error se propaga aguas abajo. En TypeScript el compilador lo intercepta en el sitio exacto donde se cometió.

any: la puerta de escape del sistema de tipos

any indica que una variable puede contener cualquier tipo de dato. Desactiva por completo la verificación:

let avenger: any = 123;
avenger = 'Dr. Strange';
console.log((avenger as string).charAt(0));

avenger = 15.23425;
console.log((<number>avenger).toFixed(2));

Cuando usas any, el typechecker deja de ayudarte. Puedes reorientarlo mediante un cast —indicar manualmente qué tipo debe asumir en un punto dado— con la sintaxis (variable as Tipo) o <Tipo>variable.

Warning

Evita any salvo en migraciones puntuales o fronteras con código sin tipado. Cada any es un agujero por el que se filtran errores que el compilador debería haber detenido.

unknown: la alternativa segura a any

unknown es el primo responsable de any. Acepta cualquier valor, pero TypeScript prohíbe operar sobre él hasta que acotes su tipo mediante una comprobación. Esto añade una capa de seguridad: sí admite operaciones de comparación e identidad (==, ===, ||, &&, el operador ternario ?) y negación con !, pero no el acceso a propiedades arbitrarias.

let dato: unknown = obtenerValor();

// dato.toFixed(2) // Error: 'dato' es de tipo 'unknown'
if (typeof dato === 'number') {
 dato.toFixed(2) // OK: dentro del guard, dato es number
}

Usa unknown siempre que recibas datos externos (respuestas de API, entrada del usuario) en lugar de any.

boolean

Acepta las operaciones ==, ===, ||, &&, el ternario ? y la negación !:

let a = true // boolean
const c = true // true (tipo literal)
let d: boolean = true // boolean
let e: true = true // true
let f: true = false // Error TS2322: 'false' no es asignable a 'true'.

Info

El tipo true (literal) es más restrictivo que boolean: además de exigir un booleano, exige que su valor sea exactamente true. Los tipos literales son una herramienta poderosa para modelar estados precisos.

number y bigint

number cubre enteros, flotantes, Infinity, NaN y valores positivos y negativos:

let a = 1234 // number
const c = 5678 // 5678 (literal)
let e: number = 100 // number
let f: 26.218 = 26.218 // 26.218 (literal)
let g: 26.218 = 10 // Error TS2322

Un number representa con precisión hasta 2^53. Para enteros mayores existe bigint:

let a = 1234n // bigint
const b = 5678n // 5678n
let e = 88.5n // Error TS1353: un literal bigint debe ser entero.
let h: bigint = 100 // Error TS2322: '100' no es asignable a 'bigint'.

string

let a = 'hello' // string
const c = '!' // '!' (literal)
let e: string = 'zoom' // string
let f: 'john' = 'john' // 'john' (literal)
let g: 'john' = 'zoe' // Error TS2322

symbol

Un symbol representa un identificador único. Se crea con Symbol() y admite una descripción opcional útil para depurar:

let id = Symbol("id"); // symbol con descripción "id"

La garantía clave: dos símbolos nunca son iguales, aunque compartan descripción. La descripción es solo una etiqueta sin efecto sobre la identidad.

let id1 = Symbol("id");
let id2 = Symbol("id");
console.log(id1 === id2); // false

let d = id1 + 'x' // Error TS2469: el operador '+' no aplica a 'symbol'.

Objetos

Hay dos formas de tipar objetos. La primera usa la palabra clave object, que solo garantiza que el valor no es null pero no expone sus propiedades, porque TypeScript no sabe qué objeto es:

let a: object = { b: 'x' }
// a.b // Error: la propiedad 'b' no existe en el tipo 'object'

La segunda —y recomendada— describe la forma exacta del objeto:

let c: {
 firstName: string
 lastName: string
} = {
 firstName: 'john',
 lastName: 'barrowman'
}

Las definiciones de objeto admiten campos opcionales (?), índices dinámicos y propiedades de solo lectura:

let a: {
 b: number // obligatorio, number
 c?: string // opcional, string
 [key: number]: boolean // cualquier clave numérica → boolean
}

let user: {
 readonly firstName: string
} = { firstName: 'abby' }

user.firstName = 'abbey' // Error TS2540: propiedad de solo lectura.

Tip

Evita tipar con el objeto vacío {}. Acepta cualquier valor distinto de null o undefined (incluso números o arreglos), lo que vacía de sentido la anotación.

Alias de tipo

Los alias asignan un nombre semántico a un tipo, mejorando la legibilidad sin alterar la verificación:

type Age = number

type Person = {
 name: string
 age: Age
}

let driver: Person = {
 name: 'James May',
 age: 55
}

Como Age es solo un alias de number, sigue siendo compatible con cualquier number. Ten presente que un alias solo puede declararse una vez por ámbito; aplica las mismas reglas de shadowing que let, const y var.

Tipos unión e intersección

Recurriendo a la teoría de conjuntos: la unión (|) admite uno u otro tipo —o ambos—, mientras que la intersección (&) exige cumplir simultáneamente todas las formas combinadas.

flowchart LR
 subgraph Union["A | B"]
 U[Cualquier valor que sea A, B o ambos]
 end
 subgraph Inter["A & B"]
 I[Solo valores que cumplen A y B a la vez]
 end

type Cat = { name: string, purrs: boolean }
type Dog = { name: string, barks: boolean, wags: boolean }

type CatOrDogOrBoth = Cat | Dog // unión
type CatAndDog = Cat & Dog // intersección

Un valor Cat | Dog puede ser un gato, un perro o un objeto que cumpla ambas formas. Un valor Cat & Dog, en cambio, está obligado a tener name, purrs, barks y wags al mismo tiempo.

Arreglos

let a = [1, 2, 3] // number[]
let d = [1, 'a'] // (string | number)[]
let h: number[] = []
h.push(1) // OK
h.push('red') // Error TS2345

Un arreglo declarado vacío sin anotación arranca como any[] y va ampliando su tipo según lo que insertes —otra razón para anotar explícitamente las colecciones en las fronteras del sistema.

Tuplas

Las tuplas son un subconjunto de los arreglos con longitud fija y tipos posicionales:

let a: [number] = [1]

// [nombre, apellido, año de nacimiento]
let b: [string, string, number] = ['malcolm', 'gladwell', 1963]

b = ['queen', 'elizabeth', 'ii', 1926] // Error TS2322: posición/longitud inválida

También admiten posiciones opcionales:

// Tarifas de tren que a veces varían según la dirección
let trainFares: [number, number?][] = [
 [3.75],
 [8.25, 7.70],
 [10.50]
]

Conclusión

El sistema de tipos de TypeScript va mucho más allá de etiquetar variables: distingue entre any (inseguro) y unknown (seguro), modela estados exactos con tipos literales, compone formas mediante uniones e intersecciones y garantiza estructuras rígidas con tuplas. Dominar este catálogo es el prerrequisito para los temas avanzados de la serie.

En el siguiente artículo aplicaremos estos fundamentos a los objetos y tipos personalizados, donde los alias de tipo se vuelven el centro del diseño.

Estilos CSS: Transiciones, transformaciones y rendimiento

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Las transiciones y transformaciones son la puerta de entrada a las interfaces animadas. Una transición suaviza el cambio entre dos estados; una transformación altera la geometría visual de un elemento sin afectar el layout. Bien aplicadas, mejoran la percepción de calidad y guían la atención del usuario. Mal aplicadas, generan jank y consumen batería. La diferencia está en entender qué propiedades son baratas de animar y por qué.

Esta es la séptima entrega de la serie Estilos CSS. Cubriremos la propiedad transition y sus timing functions, las funciones de transform en 2D y 3D, y el pipeline de renderizado que explica por qué transform y opacity son las propiedades óptimas para animar.

Note

Aprenderás a construir transiciones fluidas con curvas de Bézier, a aplicar y combinar transformaciones, y a entender el pipeline layout → paint → composición para escribir animaciones eficientes.

Transiciones

Una transición interpola el cambio de una propiedad entre su valor inicial y final a lo largo del tiempo. Suele combinarse con pseudo-clases como :hover o :active. Se controla con cuatro propiedades:

transition-property: background-color, transform;
transition-duration: 0.3s, 0.6s;
transition-timing-function: ease, linear;
transition-delay: 0s, 100ms;

transition-property — qué propiedades se animan (usa all para todas).
transition-duration — cuánto dura la interpolación.
transition-timing-function — cómo se distribuye el movimiento en el tiempo.
transition-delay — cuánto espera antes de empezar (opcional).

.boton { transition: background-color 0.3s ease, transform 0.3s ease; }
.boton:hover { background-color: #16828d; transform: translateY(-3px); }

Timing functions

La timing function define cómo se reparte el movimiento en el tiempo. Existen valores predefinidos —linear, ease, ease-in, ease-out, ease-in-out— donde el eje X representa el tiempo y el eje Y el progreso del cambio.

Todas son curvas de Bézier, y puedes definir la tuya con la función cubic-bezier():

.box { transition: transform 0.6s cubic-bezier(0.45, 0.05, 0.55, 0.95); }

También puedes hacer el cambio en pasos discretos con steps(), útil para animaciones tipo sprite o efectos de “tecleo”:

.box { transition: all 1s steps(3); }

Tip

Existen editores visuales de curvas de Bézier que te permiten ajustar la animación y copiar el valor exacto. Experimentar con ellos es la forma más rápida de afinar la sensación de una transición.

Transformaciones

La propiedad transform altera la geometría visual de un elemento mediante cuatro operaciones:

scale() — escala el tamaño.
rotate() — rota el elemento.
translate() — lo desplaza.
skew() — lo inclina/estira.

Warning

Las transformaciones solo alteran la representación visual del elemento, no su comportamiento en el layout. El hueco original que ocupaba se conserva, y los elementos vecinos no se reorganizan.

Rotación

rotate() gira el elemento. Los valores positivos giran en sentido horario; los negativos, antihorario.

.giro { transform: rotate(15deg); }

Traslación

translate(x, y) mueve el elemento en ambos ejes sin afectar el flujo. Los valores positivos lo desplazan a la derecha y hacia abajo.

.mover { transform: translate(40px, 10px); }

Escala

scale() redimensiona: valores entre 0 y 1 encogen, mayores que 1 agrandan.

.crecer { transform: scale(1.3); }

Inclinación

skew(x, y) deforma el elemento inclinándolo respecto a los ejes.

.inclinar { transform: skew(-12deg); }

rotate translate scale skew

Punto de referencia: transform-origin

Toda transformación se aplica desde un punto de referencia, que por defecto es el centro del elemento. transform-origin lo reubica:

.giro { transform-origin: left center; } /* equivale a 0% 50% */

Combinar transformaciones

Puedes encadenar varias funciones separándolas por espacios. Se aplican de derecha a izquierda, lo que afecta el resultado final:

.tarjeta { transform: rotate(15deg) translate(20px, 0); }

El pipeline de renderizado

Para escribir animaciones eficientes hay que entender cómo el navegador dibuja una página. El proceso tiene tres etapas clave:

Layout — el navegador calcula las dimensiones y posiciones de todos los elementos. Cualquier cambio de tamaño o posición dispara un recálculo completo (reflow).
Paint — pinta en memoria los píxeles de cada elemento (colores, bordes, sombras), posiblemente en capas separadas.
Composición — combina las capas pintadas para mostrarlas en pantalla.

flowchart LR
 A[JS / CSS] --> B[Layout]
 B --> C[Paint]
 C --> D[Composición]

La clave del rendimiento: algunas propiedades, como transform y opacity, solo afectan la etapa de composición. No requieren recalcular el layout ni repintar, por lo que son las propiedades óptimas para animar de forma fluida a 60 fps.

Tip

Prefiere animar transform y opacity en lugar de width, height, top o left. Estas últimas disparan layout y paint en cada frame, lo que produce animaciones entrecortadas.

Transformaciones en 3D

transform también opera en tres dimensiones. Puedes rotar sobre cualquier eje con rotateX(), rotateY() y rotateZ(). El efecto depende de la perspectiva: la distancia simulada entre el observador y el elemento. A menor perspectiva, más pronunciado el efecto 3D.

Hay dos formas de aplicarla:

/* 1. Función dentro de transform (afecta solo a ese elemento) */
.box { transform: perspective(200px) rotateX(30deg); }

/* 2. Propiedad en el contenedor (perspectiva compartida) */
.row { perspective: 200px; }
.box { transform: rotateX(30deg); }

rotateX(35deg)

rotateY(35deg)

Una rotación de 180° voltea el elemento como un espejo. La propiedad backface-visibility controla si la cara trasera es visible, lo que habilita efectos como las tarjetas que se voltean. Un recurso clásico para profundizar es Intro to CSS 3D transforms.

Conclusión

Las transiciones suavizan los cambios de estado y las transformaciones manipulan la geometría sin tocar el layout. La regla de oro del rendimiento es animar transform y opacity, que solo afectan la etapa de composición. Con curvas de Bézier afinadas y un uso consciente del pipeline, tus animaciones serán fluidas y eficientes.

Note

🚀 La entrega final de la serie aborda la modularización y los patrones de diseño en CSS: cómo organizar tus estilos en componentes mantenibles con metodologías como BEM.

SQL: Agrupamiento y Funciones Agregadas con GROUP BY

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una tabla empieza a acumular miles o millones de filas, consultar registros individuales deja de ser suficiente. En análisis, reportes y validaciones operativas necesitamos resumir datos: cuántas rentas hizo cada cliente, cuánto pagó en total, cuál fue el monto máximo o qué categorías concentran más actividad. Para eso usamos agrupamiento en SQL con GROUP BY y funciones agregadas como COUNT, SUM, AVG, MIN y MAX.

Este es el artículo 4 de la serie SQL. Venimos de trabajar con lógica condicional con CASE, y ahora vamos a convertir filas transaccionales en resultados agregados listos para análisis.

Note

En este artículo aprenderás a usar GROUP BY, ordenar grupos con ORDER BY, filtrar agregaciones con HAVING, contar valores distintos con DISTINCT y crear agrupaciones por una columna, múltiples columnas o expresiones.

Conceptos de agrupamiento en SQL

GROUP BY toma filas que comparten el mismo valor en una o más expresiones y las compacta en un grupo lógico. Si seleccionamos únicamente customer_id desde rental, SQL puede devolver cada cliente una sola vez:

mysql> SELECT customer_id
 -> FROM rental
 -> GROUP BY customer_id;
+-------------+
| customer_id |
+-------------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
...
| 594 |
| 595 |
| 596 |
| 597 |
| 598 |
| 599 |
+-------------+
599 rows in set (0.00 sec)

El resultado ya no representa rentas individuales, sino el conjunto de clientes que aparecen en la tabla. El siguiente paso natural es medir cuántas filas contiene cada grupo. Para eso usamos COUNT(*):

mysql> SELECT customer_id, count(*)
 -> FROM rental
 -> GROUP BY customer_id;
+-------------+----------+
| customer_id | count(*) |
+-------------+----------+
| 1 | 32 |
| 2 | 27 |
| 3 | 26 |
| 4 | 22 |
| 5 | 38 |
| 6 | 28 |
...
| 594 | 27 |
| 595 | 30 |
| 596 | 28 |
| 597 | 25 |
| 598 | 22 |
| 599 | 19 |
+-------------+----------+
599 rows in set (0.01 sec)

Info

COUNT(*) le indica a SQL que cuente todas las filas contenidas dentro de cada grupo definido por GROUP BY. No cuenta clientes únicos; cuenta filas dentro del grupo actual.

Ordenar resultados agregados con `ORDER BY`

Una agregación suele ser más útil cuando puedes priorizarla. Por ejemplo, para identificar los clientes con más rentas, ordenamos por la segunda columna del SELECT, que en este caso es count(*):

mysql> SELECT customer_id, count(*)
 -> FROM rental
 -> GROUP BY customer_id
 -> ORDER BY 2 DESC;
+-------------+----------+
| customer_id | count(*) |
+-------------+----------+
| 148 | 46 |
| 526 | 45 |
| 236 | 42 |
| 144 | 42 |
| 75 | 41 |
...
| 248 | 15 |
| 110 | 14 |
| 281 | 14 |
| 61 | 14 |
| 318 | 12 |
+-------------+----------+
599 rows in set (0.01 sec)

Tip

ORDER BY puede usar el nombre de una columna, un alias o la posición de la columna dentro del SELECT. Aun así, en consultas mantenibles suele ser más claro usar alias explícitos.

Filtrar grupos con `HAVING`

WHERE filtra filas antes de que ocurra el agrupamiento. HAVING, en cambio, filtra grupos después de calcular las agregaciones. Esta diferencia es crítica: no puedes usar WHERE count(*) >= 40 porque count(*) todavía no existe en esa fase lógica de la consulta.

Consideremos clientes con al menos 40 rentas:

mysql> SELECT customer_id, count(*)
 -> FROM rental
 -> GROUP BY customer_id
 -> HAVING count(*) >= 40;
+-------------+----------+
| customer_id | count(*) |
+-------------+----------+
| 75 | 41 |
| 144 | 42 |
| 148 | 46 |
| 197 | 40 |
| 236 | 42 |
| 469 | 40 |
| 526 | 45 |
+-------------+----------+
7 rows in set (0.01 sec)

Analicemos el flujo conceptual: FROM obtiene las filas, WHERE descarta filas individuales, GROUP BY crea grupos, las funciones agregadas calculan métricas y HAVING descarta grupos completos. Por último, ORDER BY organiza el resultado final.

Funciones agregadas comunes

Las bases de datos implementan distintas funciones agregadas, pero estas aparecen prácticamente en cualquier motor SQL:

Función	Qué devuelve
`MAX()`	El valor máximo dentro de un conjunto
`MIN()`	El valor mínimo dentro de un conjunto
`AVG()`	El promedio de los valores del conjunto
`SUM()`	La suma total de los valores del conjunto
`COUNT()`	La cantidad de valores o filas del conjunto

Sin GROUP BY, estas funciones operan sobre toda la tabla o sobre el conjunto filtrado por WHERE. Observemos un resumen global de pagos:

mysql> SELECT MAX(amount) max_amt,
 -> MIN(amount) min_amt,
 -> AVG(amount) avg_amt,
 -> SUM(amount) tot_amt,
 -> COUNT(*) num_payments
 -> FROM payment;
+---------+---------+----------+----------+--------------+
| max_amt | min_amt | avg_amt | tot_amt | num_payments |
+---------+---------+----------+----------+--------------+
| 11.99 | 0.00 | 4.200667 | 67416.51 | 16049 |
+---------+---------+----------+----------+--------------+
1 row in set (0.09 sec)

Aquí SQL devuelve una sola fila porque existe un grupo implícito: todo el resultado de payment.

Grupos implícitos vs grupos explícitos

Cuando usamos una función agregada sin GROUP BY, SQL resume todo el conjunto como un único grupo. Eso es útil para métricas globales, pero no sirve si necesitamos una métrica por cliente, actor, categoría o periodo.

Para obtener métricas por cliente, definimos el grupo explícitamente:

mysql> SELECT customer_id,
 -> MAX(amount) max_amt,
 -> MIN(amount) min_amt,
 -> AVG(amount) avg_amt,
 -> SUM(amount) tot_amt,
 -> COUNT(*) num_payments
 -> FROM payment
 -> GROUP BY customer_id;
+-------------+---------+---------+----------+---------+--------------+
| customer_id | max_amt | min_amt | avg_amt | tot_amt | num_payments |
+-------------+---------+---------+----------+---------+--------------+
| 1 | 9.99 | 0.99 | 3.708750 | 118.68 | 32 |
| 2 | 10.99 | 0.99 | 4.767778 | 128.73 | 27 |
| 3 | 10.99 | 0.99 | 5.220769 | 135.74 | 26 |
| 4 | 8.99 | 0.99 | 3.717273 | 81.78 | 22 |
| 5 | 9.99 | 0.99 | 3.805789 | 144.62 | 38 |
| 6 | 7.99 | 0.99 | 3.347143 | 93.72 | 28 |
...
| 594 | 8.99 | 0.99 | 4.841852 | 130.73 | 27 |
| 595 | 10.99 | 0.99 | 3.923333 | 117.70 | 30 |
| 596 | 6.99 | 0.99 | 3.454286 | 96.72 | 28 |
| 597 | 8.99 | 0.99 | 3.990000 | 99.75 | 25 |
| 598 | 7.99 | 0.99 | 3.808182 | 83.78 | 22 |
| 599 | 9.99 | 0.99 | 4.411053 | 83.81 | 19 |
+-------------+---------+---------+----------+---------+--------------+
599 rows in set (0.04 sec)

La regla práctica es directa: cualquier columna no agregada en el SELECT debe representar la granularidad del resultado y, por lo tanto, debe estar en el GROUP BY.

Warning

Algunos motores permiten seleccionar columnas que no están agrupadas ni agregadas, pero el resultado puede ser ambiguo o depender de configuraciones del motor. Para consultas portables y correctas, declara explícitamente la granularidad.

Contar valores distintos con `COUNT(DISTINCT ...)`

COUNT(*) cuenta filas. COUNT(columna) cuenta valores no nulos de esa columna. COUNT(DISTINCT columna) cuenta valores únicos, ignorando duplicados.

Esto permite diferenciar entre el número de pagos registrados y el número de clientes distintos que hicieron pagos:

mysql> SELECT COUNT(customer_id) num_rows,
 -> COUNT(DISTINCT customer_id) num_customers
 -> FROM payment;
+----------+---------------+
| num_rows | num_customers |
+----------+---------------+
| 16049 | 599 |
+----------+---------------+
1 row in set (0.01 sec)

Observemos que num_rows refleja eventos de pago, mientras num_customers refleja entidades únicas. Esa distinción evita errores frecuentes en reportes, especialmente cuando mezclamos métricas transaccionales con métricas de negocio.

Generar grupos según la granularidad requerida

La calidad de una consulta agregada depende de elegir la granularidad correcta. No es lo mismo agrupar por cliente, por cliente y mes, por actor y clasificación, o por una expresión derivada de una fecha.

Agrupamiento por una columna

Agrupar por una sola columna es el caso base. En este ejemplo obtenemos cuántas películas tiene asociadas cada actor:

mysql> SELECT actor_id, count(*)
 -> FROM film_actor
 -> GROUP BY actor_id;
+----------+----------+
| actor_id | count(*) |
+----------+----------+
| 1 | 19 |
| 2 | 25 |
| 3 | 22 |
| 4 | 22 |
...
| 197 | 33 |
| 198 | 40 |
| 199 | 15 |
| 200 | 20 |
+----------+----------+
200 rows in set (0.11 sec)

Info

En este resultado cada fila representa un actor y el conteo de películas en las que participa. La consulta ya no describe relaciones individuales actor-película, sino un resumen por actor.

Agrupamiento por múltiples columnas

En algunos casos necesitamos generar grupos que combinen más de una columna. Por ejemplo, contar cuántas películas tiene cada actor por clasificación (G, PG, PG-13, R, NC-17):

mysql> SELECT fa.actor_id, f.rating, count(*)
 -> FROM film_actor fa
 -> INNER JOIN film f
 -> ON fa.film_id = f.film_id
 -> GROUP BY fa.actor_id, f.rating
 -> ORDER BY 1,2;
+----------+--------+----------+
| actor_id | rating | count(*) |
+----------+--------+----------+
| 1 | G | 4 |
| 1 | PG | 6 |
| 1 | PG-13 | 1 |
| 1 | R | 3 |
| 1 | NC-17 | 5 |
| 2 | G | 7 |
| 2 | PG | 6 |
| 2 | PG-13 | 2 |
| 2 | R | 2 |
| 2 | NC-17 | 8 |
...
| 199 | G | 3 |
| 199 | PG | 4 |
| 199 | PG-13 | 4 |
| 199 | R | 2 |
| 199 | NC-17 | 2 |
| 200 | G | 5 |
| 200 | PG | 3 |
| 200 | PG-13 | 2 |
| 200 | R | 6 |
| 200 | NC-17 | 4 |
+----------+--------+----------+
996 rows in set (0.01 sec)

Aquí la granularidad ya no es “actor”, sino “actor + clasificación”. Cada combinación única genera su propio grupo. Esta técnica es la base para reportes multidimensionales y pivotes posteriores en herramientas de BI.

Agrupamiento mediante expresiones

GROUP BY no está limitado a columnas físicas. También puede agrupar por expresiones, funciones o transformaciones calculadas. Esto es especialmente útil con fechas.

El siguiente ejemplo agrupa rentas por año:

mysql> SELECT extract(YEAR FROM rental_date) year,
 -> COUNT(*) how_many
 -> FROM rental
 -> GROUP BY extract(YEAR FROM rental_date);
+------+----------+
| year | how_many |
+------+----------+
| 2005 | 15862 |
| 2006 | 182 |
+------+----------+
2 rows in set (0.01 sec)

En lugar de agrupar por cada rental_date exacto, reducimos la fecha al año con EXTRACT(YEAR FROM rental_date). El resultado responde una pregunta distinta: volumen anual, no eventos individuales.

Buenas prácticas al trabajar con `GROUP BY`

Para mantener consultas claras y confiables, considera estas reglas:

Define primero la granularidad: una fila por cliente, por cliente y mes, por actor y rating, etc.
Usa alias descriptivos para agregaciones: num_payments, total_amount, avg_amount.
Aplica WHERE para filtrar filas antes de agrupar y HAVING para filtrar grupos.
Evita depender de posiciones como ORDER BY 2 en consultas de producción si un alias mejora la legibilidad.
Verifica si necesitas contar filas (COUNT(*)), valores no nulos (COUNT(columna)) o valores únicos (COUNT(DISTINCT columna)).

Conclusión

GROUP BY cambia la forma en que lees una tabla: pasas de inspeccionar filas individuales a construir resúmenes por la granularidad que necesita tu análisis. Combinado con funciones agregadas, HAVING, DISTINCT y expresiones, se convierte en una herramienta central para reportes, dashboards y validaciones de datos.

En el siguiente artículo de la serie vamos a conectar datos distribuidos entre tablas con consultas a múltiples tablas usando JOINs.

TypeScript: Introducción y configuración del entorno

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Este artículo abre la serie sobre TypeScript. Aquí analizaremos qué problema resuelve el tipado estático, cómo opera el compilador tsc y cómo dejar listo un proyecto profesional con tsconfig.json.

JavaScript resuelve los tipos en tiempo de ejecución. Esto significa que un error tan trivial como pasar un string donde se esperaba un number solo se manifiesta cuando el código ya está corriendo, frecuentemente en producción y bajo la forma de un NaN silencioso o una excepción difícil de rastrear. TypeScript ataca este problema en la raíz: agrega un sistema de tipos estático sobre JavaScript que traslada la detección de errores desde el runtime hacia el tiempo de compilación.

¿Cómo se ejecuta el código? AST, bytecode y runtime

Para entender qué aporta TypeScript conviene recordar el ciclo de vida de un programa en un motor de JavaScript:

El programa se parsea hacia un AST (Abstract Syntax Tree).
El AST se compila a bytecode.
El bytecode es evaluado por el runtime.

TypeScript se inserta antes de este flujo. El compilador tsc toma tu código .ts, construye su propio AST, lo somete al typechecker y, si todo es válido, emite JavaScript estándar que cualquier motor puede ejecutar.

flowchart LR
 A[Código TypeScript] --> B[AST de TypeScript]
 B --> C{Typechecker}
 C -- válido --> D[JavaScript emitido]
 C -- error --> E[Error en compilación]
 D --> F[AST de JavaScript]
 F --> G[Bytecode]
 G --> H[Runtime]

La conclusión clave: el typechecker es una capa de verificación que se ejecuta antes de generar el JavaScript final. Los errores de tipo nunca llegan al runtime porque la compilación se detiene antes.

El sistema de tipos

TypeScript admite tanto anotaciones de tipo explícitas como inferencia automática. Ambas estrategias coexisten en el mismo archivo:

let a: number = 1 // a es number
let b: string = 'hello' // b es string
let c: boolean[] = [true, false] // c es un arreglo de booleanos

let a = 1 // a es number (inferido)
let b = 'hello' // b es string (inferido)
let c = [true, false] // c es boolean[] (inferido)

Tip

Apóyate en la inferencia siempre que el tipo sea evidente y reserva las anotaciones explícitas para las fronteras del sistema: firmas de funciones, APIs públicas y estructuras de datos compartidas. Esto reduce el ruido sin sacrificar seguridad.

La diferencia esencial frente a JavaScript se resume así:

Característica del sistema de tipos	JavaScript	TypeScript
¿Cómo se enlazan los tipos?	Dinámicamente	Estáticamente
¿Se convierten automáticamente?	Sí	No (en general)
¿Cuándo se verifican?	En tiempo de ejecución	En tiempo de compilación
¿Cuándo afloran los errores?	En ejecución	En compilación

Instalación de TypeScript

TypeScript se distribuye como un paquete de Node, por lo que necesitas tener Node.js instalado. Inicializa el proyecto y agrega las dependencias de desarrollo:

npm init -y
npm install --save-dev typescript @types/node

@types/node aporta las definiciones de tipos del entorno de ejecución de Node, indispensables si vas a trabajar en el backend.

tsconfig.json: el corazón de la configuración

El archivo tsconfig.json, ubicado en la raíz del proyecto, define cómo el compilador interpreta y transforma tu código. Una configuración base sólida luce así:

{
 "compilerOptions": {
 "lib": ["es2015"],
 "module": "commonjs",
 "outDir": "dist",
 "sourceMap": true,
 "strict": true,
 "target": "es2015"
 },
 "include": ["src"]
}

Cada opción cumple un rol concreto:

include: indica las rutas donde tsc debe buscar los archivos a compilar.
lib: declara qué librerías de tipos (APIs del entorno) asume disponibles el proyecto.
module: define el sistema de módulos del código emitido (commonjs, esnext, etc.).
outDir: ubicación de los archivos JavaScript compilados.
sourceMap: genera source maps para depurar el TypeScript original desde el navegador o Node.
strict: habilita el conjunto completo de comprobaciones estrictas. Es la opción que más valor aporta.
target: versión de JavaScript a la que se transpila el código.

Puedes consultar el catálogo completo de opciones en la documentación oficial de tsc, o explorarlas desde la terminal:

npx tsc --help

Warning

La opción strict no es opcional en un proyecto serio. Activarla desde el primer commit evita una migración dolorosa más adelante, cuando el código ya arrastra cientos de tipos implícitos any.

El archivo de entrada: index.ts

El punto de entrada convencional es src/index.ts. Comencemos con el clásico mensaje de prueba:

console.log('hello world from TS!')

Compila el proyecto y ejecútalo:

npx tsc
node ./dist/index.js

tsc lee la configuración de tsconfig.json, transpila todo lo que esté bajo src y deposita el resultado en dist.

Hola mundo y la verificación de tipos en acción

Observemos cómo el typechecker protege contra asignaciones inválidas:

let msg: string = 'Hola mundo';
console.log(msg);
msg = 'David Casas';
console.log(msg);
// msg = 123 // Error: number no es asignable a string

Al compilar, TypeScript transpila a JavaScript plano eliminando las anotaciones:

var msg = 'Hola mundo';
console.log(msg);
msg = 'David Casas';
console.log(msg);

El tipo string desaparece del código emitido porque su único propósito era validar en compilación. Esta propiedad —los tipos se borran tras la verificación— se conoce como type erasure.

Watch mode: compilación continua

Compilar manualmente tras cada cambio rompe el flujo de trabajo. El compilador incluye un modo observador que recompila de forma incremental cada vez que detecta una modificación:

npx tsc --watch
# o su forma corta
npx tsc -w

Mantén este proceso abierto en una terminal mientras desarrollas: cada vez que guardes un archivo .ts, verás de inmediato los errores de tipo o la salida actualizada en dist.

Conclusión

TypeScript no reemplaza a JavaScript; lo eleva añadiendo una capa de verificación estática que captura errores antes de ejecutar una sola línea. Con Node instalado, un tsconfig.json en modo strict y el compilador en watch mode, ya tienes un entorno profesional listo para los siguientes temas de la serie.

En el próximo artículo profundizaremos en los tipos básicos del lenguaje: any, unknown, number, string, symbol, objetos, uniones e intersecciones.

Estilos CSS: Fondos, gradientes y sombras

Dacadev — Fri, 12 Jun 2026 00:00:00 -0500

Tabla de Contenido

Los fondos y las sombras son las herramientas con las que CSS aporta profundidad, textura y jerarquía visual sin necesidad de imágenes externas. Un gradiente bien construido reemplaza un archivo PNG; una sombra sutil comunica que un botón es interactivo. Dominar estas propiedades te permite crear interfaces ricas con código puro, ligero y escalable.

Esta es la sexta entrega de la serie Estilos CSS. Recorreremos la familia de propiedades background, los gradientes lineales y radiales, los modos de mezcla y las sombras de caja y de texto.

Note

Aprenderás a generar gradientes y patrones sin imágenes, a combinar varias capas de fondo y a usar box-shadow y text-shadow para dar realismo y feedback a tus componentes.

La familia background

background es una propiedad abreviada que agrupa ocho propiedades individuales:

background-image — una imagen o un gradiente generado.
background-position — la posición inicial del fondo.
background-size — el tamaño de renderizado (cover, contain, valores explícitos).
background-repeat — si la imagen se repite en mosaico.
background-origin — respecto a qué caja se posiciona (border, padding o content).
background-clip — hasta qué caja se extiende el fondo.
background-attachment — si el fondo se desplaza con el contenido o queda fijo.
background-color — un color sólido que se renderiza detrás de la imagen.

Gradientes lineales

Un gradiente es una transición de colores generada por una función de CSS, sin archivos. linear-gradient() crea una transición a lo largo de una dirección.

.fade { background-image: linear-gradient(to right, #fff, #2a9da9); }

La función acepta una dirección (to right, 90deg, etc.) y una lista de colores. Puedes incluir más de dos colores y fijar su posición con porcentajes:

.fade { background-image: linear-gradient(90deg, #c0392b 0%, #fff 50%, #2a9da9 100%); }

Gradientes lineales repetitivos

repeating-linear-gradient() crea patrones que se repiten, útil para texturas como rayas:

.rayas {
 background-image: repeating-linear-gradient(-45deg,
 #2a9da9, #2a9da9 10px, #16828d 10px, #16828d 20px);
}

Gradientes radiales

radial-gradient() genera una transición circular o elíptica que irradia desde un punto, en lugar de seguir una dirección lineal.

.brillo { background-image: radial-gradient(#fff, #2a9da9); }

Combinar múltiples fondos

Puedes apilar varias capas de fondo separándolas con comas. La primera capa queda al frente. Esto permite, por ejemplo, superponer un gradiente sobre una imagen:

.heroe {
 background-image:
 linear-gradient(to bottom, rgba(42,157,169,0.6), rgba(22,130,141,0.9)),
 url(foto.jpg);
 background-size: cover;
}

Gradiente sobre una textura de fondo

Texturas con blend modes

La propiedad background-blend-mode mezcla las capas de fondo entre sí (con modos como multiply, soft-light, overlay), añadiendo textura a una imagen sin editarla en un programa externo:

.textura {
 background-image: url(rayones.png), url(foto.jpg);
 background-blend-mode: soft-light;
}

Sombras: box-shadow y text-shadow

CSS permite añadir sombras tanto a las cajas (box-shadow) como al texto (text-shadow). Ambas reciben los mismos parámetros básicos:

Desplazamiento horizontal y vertical (offset-x, offset-y).
El radio de difuminado (blur).
(opcional) El radio de expansión (spread).
El color de la sombra.

.tarjeta { box-shadow: 0 0.2em 0.5em rgba(0, 0, 0, 0.25); }
.titulo { text-shadow: 2px 2px 4px rgba(0, 0, 0, 0.4); }

Tarjeta con box-shadow

Texto con text-shadow

Sombras interiores para feedback

La palabra clave inset convierte la sombra en interior, perfecta para simular que un botón está presionado. Combinada con pseudo-clases como :active, crea componentes con feedback táctil:

.boton {
 background-image: linear-gradient(to bottom, #2a9da9, #16828d);
 box-shadow: 0.1em 0.1em 0.5em rgba(0,0,0,0.4);
 color: #fff;
}

.boton:active {
 box-shadow: inset 0 0 0.5em #0d4f56,
 inset 0 0.5em 1em rgba(0,0,0,0.4);
}

Al pulsarlo, la sombra interior simula el hundido físico.

Tip

Las sombras se renderizan en la capa de composición y son baratas de animar. Una transición sutil de box-shadow en :hover comunica interactividad con un costo de rendimiento mínimo.

Conclusión

Los gradientes y las sombras te permiten construir interfaces con profundidad y textura usando solo CSS, evitando peticiones de red y archivos de imagen. Apilar capas de fondo, mezclarlas con blend modes y aplicar sombras interiores son técnicas que elevan la calidad visual de cualquier componente.

Note

🚀 La próxima entrega cubre transiciones y transformaciones: cómo animar cambios de estado de forma fluida y manipular la geometría de los elementos con transform.

RxJs: Peticiones HTTP/AJAX con rxjs/ajax y catchError

Dacadev — Thu, 11 Jun 2026 00:00:00 -0500

Tabla de Contenido

En aplicaciones frontend, las peticiones ajax rxjs resultan útiles cuando el tráfico HTTP no es un evento aislado, sino parte de un flujo: búsquedas con cancelación, reintentos, composición con eventos de UI o coordinación entre varias fuentes asíncronas. fetch cubre bien el caso imperativo basado en promesas, pero rxjs/ajax integra las peticiones HTTP directamente con observables, operadores y suscripciones.

Note

Este artículo forma parte de la serie RxJs. Venimos de analizar los operadores de combinación y cerraremos la serie abordando rxjs/ajax, ajax.getJSON, métodos HTTP y catchError rxjs para manejar fallos sin romper el flujo.

fetch frente a rxjs/ajax

fetch es el estándar moderno del navegador para ejecutar peticiones HTTP. Su API está basada en Promise, por lo que encaja bien cuando necesitas una única respuesta y un flujo de control lineal.

const url = 'https://api.github.com/users?per_page=5';

const manejaErrores = (response: Response) => {
 if (!response.ok) {
 throw new Error(response.statusText);
 }

 return response;
};

fetch(url)
 .then(manejaErrores)
 .then((response) => response.json())
 .then((data) => console.log('data', data))
 .catch((error) => console.warn('Error en usuarios', error));

La limitación aparece cuando la petición debe integrarse con otros streams. Una Promise no tiene el concepto de suscripción, no emite múltiples valores y no se cancela por sí misma al dejar de interesarte el resultado. fetch puede abortarse con AbortController, pero esa cancelación queda como una responsabilidad externa que debes coordinar manualmente.

Con RxJS, en cambio, la suscripción representa el ciclo de vida del trabajo asíncrono. En rxjs/ajax, cancelar la suscripción aborta la petición subyacente basada en XMLHttpRequest, lo cual encaja naturalmente con operadores como switchMap, takeUntil o debounceTime.

Info

Usa fetch para flujos simples basados en una sola respuesta. Usa rxjs/ajax cuando la petición forma parte de una arquitectura reactiva y necesitas composición, cancelación por suscripción o manejo declarativo de errores.

rxjs ajax para peticiones HTTP

El módulo rxjs/ajax expone la función ajax, que devuelve un observable. Al suscribirte, se ejecuta la petición; al desuscribirte, se cancela si todavía está pendiente.

import { ajax } from 'rxjs/ajax';
import { map } from 'rxjs';

interface GitHubUser {
 id: number;
 login: string;
 html_url: string;
}

const url = 'https://api.github.com/users?per_page=5';

ajax<GitHubUser[]>(url)
 .pipe(map((ajaxResponse) => ajaxResponse.response))
 .subscribe({
 next: (users) => console.log('usuarios', users),
 error: (error) => console.warn('Error en usuarios', error),
 });

El observable emitido por ajax no entrega únicamente el cuerpo. Entrega un AjaxResponse<T> con metadatos como status, response, request y xhr. Esto es útil cuando la lógica depende del código HTTP, encabezados o detalles del transporte.

Para obtener solo el cuerpo, el patrón habitual consiste en aplicar map sobre response. En versiones modernas de RxJS, importar operadores desde rxjs mantiene el código conciso y compatible con el estilo recomendado.

catchError rxjs: recuperar el stream ante fallos

El operador catchError intercepta errores dentro de un observable y debe retornar un nuevo observable o un valor compatible con ObservableInput. Esto permite reemplazar el flujo fallido por un valor seguro, reintentar con otra fuente o propagar un error enriquecido.

El diagrama muestra el punto clave: cuando ocurre un error, catchError reemplaza el stream original por otro observable. Si no retornas un observable, la cadena queda en un estado inválido.

import { of } from 'rxjs';
import { ajax, AjaxError } from 'rxjs/ajax';
import { catchError, map } from 'rxjs';

interface GitHubUser {
 id: number;
 login: string;
}

const url = 'https://api.github.com/users?per_page=5';

const atrapaError = (error: AjaxError) => {
 console.warn('Error:', error.message);
 return of([] as GitHubUser[]);
};

ajax<GitHubUser[]>(url)
 .pipe(
 map((response) => response.response),
 catchError(atrapaError),
 )
 .subscribe((users) => console.log('usuarios', users));

En este ejemplo, el consumidor siempre recibe un arreglo. Si la petición falla, la UI puede renderizar un estado vacío sin romper la suscripción. Esta decisión es adecuada para listas tolerantes a fallo, pero no para operaciones donde ocultar el error afectaría consistencia o seguridad.

La salida de consola confirma que el error se captura dentro del pipeline y el stream continúa con el valor de reemplazo definido por of.

Warning

No uses catchError para silenciar errores críticos de forma indiscriminada. Retorna valores de fallback solo cuando el dominio lo permite; en otros casos, transforma el error y propágalo con throwError.

ajax.getJSON para consumir respuestas JSON

Cuando solo necesitas el cuerpo JSON, ajax.getJSON reduce el ruido del AjaxResponse. Este método ejecuta una petición GET, parsea la respuesta como JSON y permite enviar encabezados.

import { ajax } from 'rxjs/ajax';

interface DelayResponse {
 headers: Record<string, string>;
 origin: string;
 url: string;
}

const url = 'https://httpbin.org/delay/1';

const response$ = ajax.getJSON<DelayResponse>(url, {
 'Content-Type': 'application/json',
 'mi-token': '1234',
});

response$.subscribe({
 next: (data) => console.log('data', data),
 error: (error) => console.warn('Error en getJSON', error),
});

getJSON es una buena opción para consultas simples donde no necesitas inspeccionar status, xhr o encabezados de respuesta. Si esos metadatos importan, usa ajax directamente para conservar el contexto completo.

Métodos post, put y delete con rxjs/ajax

rxjs/ajax también expone métodos especializados para verbos HTTP comunes: ajax.get, ajax.post, ajax.put, ajax.patch y ajax.delete. Todos retornan observables y pueden participar en el mismo pipeline de operadores.

import { ajax } from 'rxjs/ajax';

interface UserPayload {
 id: number;
 name: string;
}

interface HttpBinResponse<T> {
 json: T;
 url: string;
}

const url = 'https://httpbin.org/anything/users';
const headers = {
 'Content-Type': 'application/json',
 'x-client': 'rxjs-demo',
};

ajax.post<HttpBinResponse<UserPayload>>(url, { id: 1, name: 'Ada' }, headers).subscribe({
 next: (response) => console.log('POST', response.response.json),
 error: (error) => console.warn('Error en POST', error),
});

ajax.put<HttpBinResponse<UserPayload>>(`${url}/1`, { id: 1, name: 'Ada Lovelace' }, headers).subscribe({
 next: (response) => console.log('PUT', response.response.json),
 error: (error) => console.warn('Error en PUT', error),
});

ajax.delete(`${url}/1`, headers).subscribe({
 next: (response) => console.log('DELETE', response.status),
 error: (error) => console.warn('Error en DELETE', error),
});

La forma especializada es legible cuando el método HTTP es fijo y la configuración es pequeña. Para casos con más parámetros, la forma de objeto suele ser más mantenible.

Configuración avanzada con objeto

La función ajax acepta un objeto de configuración. Esta variante agrupa url, method, headers, body, responseType y otros parámetros en una sola estructura, evitando firmas largas y facilitando la composición dinámica.

import { ajax } from 'rxjs/ajax';
import { catchError, map, of } from 'rxjs';

interface CreateUserRequest {
 name: string;
 role: 'admin' | 'editor' | 'viewer';
}

interface CreateUserResponse {
 json: CreateUserRequest;
 url: string;
}

const requestBody: CreateUserRequest = {
 name: 'Grace Hopper',
 role: 'admin',
};

const createUser$ = ajax<CreateUserResponse>({
 url: 'https://httpbin.org/anything/users',
 method: 'POST',
 headers: {
 'Content-Type': 'application/json',
 Authorization: 'Bearer demo-token',
 },
 body: requestBody,
 responseType: 'json',
}).pipe(
 map((response) => response.response.json),
 catchError((error) => {
 console.warn('No fue posible crear el usuario', error);
 return of(null);
 }),
);

createUser$.subscribe((user) => console.log('usuario creado', user));

Esta forma es especialmente útil en servicios donde construyes peticiones desde parámetros de dominio. También facilita extraer una función reutilizable que retorne un observable tipado sin ejecutar la petición hasta que exista una suscripción.

Tip

Mantén las funciones HTTP como fábricas de observables: reciben parámetros de dominio y retornan Observable<T>. Evita suscribirte dentro del servicio si el consumidor necesita cancelar, componer o manejar errores en una capa superior.

Composición con cancelación

Una de las ventajas prácticas de rxjs/ajax aparece en búsquedas o autocompletados. switchMap cancela la petición anterior cuando llega un nuevo término, evitando condiciones de carrera y respuestas obsoletas.

import { fromEvent } from 'rxjs';
import { ajax } from 'rxjs/ajax';
import { catchError, debounceTime, distinctUntilChanged, map, of, switchMap } from 'rxjs';

const input = document.querySelector<HTMLInputElement>('#search')!;

const results$ = fromEvent<InputEvent>(input, 'input').pipe(
 map((event) => (event.target as HTMLInputElement).value.trim()),
 debounceTime(300),
 distinctUntilChanged(),
 switchMap((query) => {
 if (!query) {
 return of([]);
 }

 return ajax.getJSON<unknown[]>(`/api/search?q=${encodeURIComponent(query)}`).pipe(
 catchError(() => of([])),
 );
 }),
);

results$.subscribe((results) => renderResults(results));

Con fetch, este patrón requiere coordinar manualmente AbortController para cada búsqueda pendiente. Con RxJS, la cancelación es una consecuencia directa de la desuscripción que switchMap realiza sobre el observable interno anterior.

Conclusión

rxjs/ajax convierte las peticiones HTTP en streams composables. Esta integración permite mapear respuestas, centralizar errores con catchError, cancelar trabajo pendiente mediante desuscripción y coordinar tráfico HTTP con eventos de interfaz o temporizadores.

Con este artículo cerramos la serie RxJs: partimos de la naturaleza de los observables, recorrimos funciones de creación, operadores básicos, transformación, combinación y finalmente peticiones AJAX. El objetivo común fue diseñar flujos asíncronos explícitos, cancelables y mantenibles usando las primitivas reactivas correctas.

SQL: Lógica Condicional con la Expresión CASE

Dacadev — Thu, 11 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una consulta necesita clasificar registros, calcular valores derivados o protegerse de casos límite, la lógica condicional en SQL evita mover decisiones simples a la capa de aplicación. Después de trabajar con filtrado de datos con WHERE, el siguiente paso natural es usar la expresión CASE para transformar resultados directamente dentro del query.

Note

En este artículo analizaremos cómo usar CASE en SQL con condiciones múltiples, validaciones de existencia, protección contra división por cero, actualizaciones condicionales y manejo explícito de valores NULL.

La expresión CASE cumple un rol similar a if / else if / else o switch / case en lenguajes de programación. Su valor está en que opera dentro del motor de base de datos: puedes derivar columnas, etiquetar estados y condicionar cálculos sin postprocesar cada fila en tu backend.

Observemos un primer ejemplo directo. A partir de una columna active, convertimos 1 y 0 en etiquetas más legibles:

mysql> SELECT first_name, last_name,
 -> CASE
 -> WHEN active = 1 THEN 'ACTIVE'
 -> ELSE 'INACTIVE'
 -> END activity_type
 -> FROM customer;
+-------------+--------------+---------------+
| first_name | last_name | activity_type |
+-------------+--------------+---------------+
| MARY | SMITH | ACTIVE |
| PATRICIA | JOHNSON | ACTIVE |
| LINDA | WILLIAMS | ACTIVE |
| BARBARA | JONES | ACTIVE |
| ELIZABETH | BROWN | ACTIVE |
| JENNIFER | DAVIS | ACTIVE |
...
| KENT | ARSENAULT | ACTIVE |
| TERRANCE | ROUSH | INACTIVE |
| RENE | MCALISTER | ACTIVE |
| EDUARDO | HIATT | ACTIVE |
| TERRENCE | GUNDERSON | ACTIVE |
| ENRIQUE | FORSYTHE | ACTIVE |
| FREDDIE | DUGGAN | ACTIVE |
| WADE | DELVALLE | ACTIVE |
| AUSTIN | CINTRON | ACTIVE |
+-------------+--------------+---------------+
599 rows in set (0.00 sec)

La expresión CASE

La expresión CASE evalúa una o varias condiciones y retorna un valor según la primera coincidencia encontrada. En SQL, CASE no es solo una herramienta cosmética; también permite modelar reglas de negocio dentro de consultas, reportes y operaciones UPDATE.

Existen dos variantes principales:

Searched CASE: cada WHEN contiene una condición completa.
Simple CASE: se evalúa una expresión base contra valores específicos.

Info

Si ninguna condición coincide y no defines ELSE, el resultado de CASE será NULL. Conviene declarar ELSE explícitamente cuando el consumidor del dato espera una categoría estable.

Searched CASE

El Searched CASE es la forma más flexible porque cada rama puede evaluar una condición distinta. Su estructura general es:

CASE
 WHEN C1 THEN E1
 WHEN C2 THEN E2
 ...
 WHEN CN THEN EN
 [ELSE ED]
END

En este patrón, C1, C2 y CN representan condiciones booleanas. Cuando una condición se cumple, CASE retorna su expresión asociada (E1, E2, EN) y deja de evaluar las siguientes ramas.

Analicemos una clasificación de categorías de películas:

CASE
 WHEN category.name IN ('Children','Family','Sports','Animation')
 THEN 'All Ages'
 WHEN category.name = 'Horror'
 THEN 'Adult'
 WHEN category.name IN ('Music','Games')
 THEN 'Teens'
 ELSE 'Other'
END

Esta variante permite mezclar operadores como IN, =, comparaciones numéricas, subconsultas y funciones. También se puede usar para evitar cálculos innecesarios en ciertas filas.

Consideremos el siguiente caso: si un cliente está inactivo, queremos retornar 0; si está activo, contamos sus rentas:

mysql> SELECT c.first_name, c.last_name,
 -> CASE
 -> WHEN active = 0 THEN 0
 -> ELSE
 -> (SELECT count(*) FROM rental r
 -> WHERE r.customer_id = c.customer_id)
 -> END num_rentals
 -> FROM customer c;
+-------------+--------------+-------------+
| first_name | last_name | num_rentals |
+-------------+--------------+-------------+
| MARY | SMITH | 32 |
| PATRICIA | JOHNSON | 27 |
| LINDA | WILLIAMS | 26 |
| BARBARA | JONES | 22 |
| ELIZABETH | BROWN | 38 |
| JENNIFER | DAVIS | 28 |
...
| TERRANCE | ROUSH | 0 |
| RENE | MCALISTER | 26 |
| EDUARDO | HIATT | 27 |
| TERRENCE | GUNDERSON | 30 |
| ENRIQUE | FORSYTHE | 28 |
| FREDDIE | DUGGAN | 25 |
| WADE | DELVALLE | 22 |
| AUSTIN | CINTRON | 19 |
+-------------+--------------+-------------+
599 rows in set (0.01 sec)

Simple CASE

El Simple CASE es útil cuando todas las ramas comparan la misma expresión contra valores concretos. En lugar de repetir category.name = ..., colocamos category.name una sola vez después de CASE.

CASE category.name
 WHEN 'Children' THEN 'All Ages'
 WHEN 'Family' THEN 'All Ages'
 WHEN 'Sports' THEN 'All Ages'
 WHEN 'Animation' THEN 'All Ages'
 WHEN 'Horror' THEN 'Adult'
 WHEN 'Music' THEN 'Teens'
 WHEN 'Games' THEN 'Teens'
 ELSE 'Other'
END

Esta forma es más compacta y legible cuando la decisión depende de una única columna o expresión. Su limitación es que no permite condiciones heterogéneas por rama; para eso conviene usar Searched CASE.

Tip

Usa Simple CASE cuando estás mapeando valores discretos de una misma columna. Usa Searched CASE cuando necesitas rangos, IN, EXISTS, comparaciones entre columnas o reglas más compuestas.

Comprobar la existencia

Uno de los usos más prácticos de CASE es combinarlo con EXISTS. Esta técnica permite crear columnas tipo bandera (Y / N, true / false, 1 / 0) según la existencia de filas relacionadas.

Observemos una consulta que marca si un actor participó en películas con ciertas clasificaciones:

mysql> SELECT a.first_name, a.last_name,
 -> CASE
 -> WHEN EXISTS (SELECT 1 FROM film_actor fa
 -> INNER JOIN film f ON fa.film_id = f.film_id
 -> WHERE fa.actor_id = a.actor_id
 -> AND f.rating = 'G') THEN 'Y'
 -> ELSE 'N'
 -> END g_actor,
 -> CASE
 -> WHEN EXISTS (SELECT 1 FROM film_actor fa
 -> INNER JOIN film f ON fa.film_id = f.film_id
 -> WHERE fa.actor_id = a.actor_id
 -> AND f.rating = 'PG') THEN 'Y'
 -> ELSE 'N'
 -> END pg_actor,
 -> CASE
 -> WHEN EXISTS (SELECT 1 FROM film_actor fa
 -> INNER JOIN film f ON fa.film_id = f.film_id
 -> WHERE fa.actor_id = a.actor_id
 -> AND f.rating = 'NC-17') THEN 'Y'
 -> ELSE 'N'
 -> END nc17_actor
 -> FROM actor a
 -> WHERE a.last_name LIKE 'S%' OR a.first_name LIKE 'S%';
+------------+-------------+---------+----------+------------+
| first_name | last_name | g_actor | pg_actor | nc17_actor |
+------------+-------------+---------+----------+------------+
| JOE | SWANK | Y | Y | Y |
| SANDRA | KILMER | Y | Y | Y |
| CAMERON | STREEP | Y | Y | Y |
| SANDRA | PECK | Y | Y | Y |
| SISSY | SOBIESKI | Y | Y | N |
| NICK | STALLONE | Y | Y | Y |
| SEAN | WILLIAMS | Y | Y | Y |
| GROUCHO | SINATRA | Y | Y | Y |
| SCARLETT | DAMON | Y | Y | Y |
| SPENCER | PECK | Y | Y | Y |
| SEAN | GUINESS | Y | Y | Y |
| SPENCER | DEPP | Y | Y | Y |
| SUSAN | DAVIS | Y | Y | Y |
| SIDNEY | CROWE | Y | Y | Y |
| SYLVESTER | DERN | Y | Y | Y |
| SUSAN | DAVIS | Y | Y | Y |
| DAN | STREEP | Y | Y | Y |
| SALMA | NOLTE | Y | N | Y |
| SCARLETT | BENING | Y | Y | Y |
| JEFF | SILVERSTONE | Y | Y | Y |
| JOHN | SUVARI | Y | Y | Y |
| JAYNE | SILVERSTONE | Y | Y | Y |
+------------+-------------+---------+----------+------------+
22 rows in set (0.00 sec)

También podemos usar CASE con una subconsulta escalar. Aquí se clasifica la disponibilidad de una película según la cantidad de copias en inventario:

mysql> SELECT f.title,
 -> CASE (SELECT count(*) FROM inventory i 
 -> WHERE i.film_id = f.film_id)
 -> WHEN 0 THEN 'Out Of Stock'
 -> WHEN 1 THEN 'Scarce'
 -> WHEN 2 THEN 'Scarce'
 -> WHEN 3 THEN 'Available'
 -> WHEN 4 THEN 'Available'
 -> ELSE 'Common'
 -> END film_availability
 -> FROM film f
 -> ;
+-----------------------------+-------------------+
| title | film_availability |
+-----------------------------+-------------------+
| ACADEMY DINOSAUR | Common |
| ACE GOLDFINGER | Available |
| ADAPTATION HOLES | Available |
| AFFAIR PREJUDICE | Common |
| AFRICAN EGG | Available |
| AGENT TRUMAN | Common |
| AIRPLANE SIERRA | Common |
| AIRPORT POLLOCK | Available |
| ALABAMA DEVIL | Common |
| ALADDIN CALENDAR | Common |
| ALAMO VIDEOTAPE | Common |
| ALASKA PHANTOM | Common |
| ALI FOREVER | Available |
| ALICE FANTASIA | Out Of Stock |
...
| YOUNG LANGUAGE | Scarce |
| YOUTH KICK | Scarce |
| ZHIVAGO CORE | Scarce |
| ZOOLANDER FICTION | Common |
| ZORRO ARK | Common |
+-----------------------------+-------------------+
1000 rows in set (0.01 sec)

Errores de división por cero

La división por cero no está definida matemáticamente y los motores de base de datos deben tratarla como un caso especial. En MySQL, por ejemplo, una división directa entre cero puede retornar NULL:

mysql> SELECT 100 / 0;
+---------+
| 100 / 0 |
+---------+
| NULL |
+---------+
1 row in set (0.00 sec)

En reportes, un NULL inesperado puede contaminar cálculos posteriores o romper supuestos del consumidor. CASE permite controlar el denominador antes de ejecutar la división.

mysql> SELECT c.first_name, c.last_name,
 -> sum(p.amount) tot_payment_amt,
 -> count(p.amount) num_payments,
 -> sum(p.amount) /
 -> CASE WHEN count(p.amount) = 0 THEN 1
 -> ELSE count(p.amount)
 -> END avg_payment
 -> FROM customer c
 -> LEFT OUTER JOIN payment p
 -> ON c.customer_id = p.customer_id
 -> GROUP BY c.first_name, c.last_name;
+------------+------------+-----------------+--------------+-------------+
| first_name | last_name | tot_payment_amt | num_payments | avg_payment |
+------------+------------+-----------------+--------------+-------------+
| MARY | SMITH | 118.68 | 32 | 3.708750 |
| PATRICIA | JOHNSON | 128.73 | 27 | 4.767778 |
| LINDA | WILLIAMS | 135.74 | 26 | 5.220769 |
| BARBARA | JONES | 81.78 | 22 | 3.717273 |
| ELIZABETH | BROWN | 144.62 | 38 | 3.805789 |
...
| EDUARDO | HIATT | 130.73 | 27 | 4.841852 |
| TERRENCE | GUNDERSON | 117.70 | 30 | 3.923333 |
| ENRIQUE | FORSYTHE | 96.72 | 28 | 3.454286 |
| FREDDIE | DUGGAN | 99.75 | 25 | 3.990000 |
| WADE | DELVALLE | 83.78 | 22 | 3.808182 |
| AUSTIN | CINTRON | 83.81 | 19 | 4.411053 |
+------------+------------+-----------------+--------------+-------------+
599 rows in set (0.07 sec)

Warning

Esta técnica evita el error o el NULL, pero no siempre significa que dividir entre 1 sea semánticamente correcto. En métricas financieras o analíticas, valida si conviene retornar 0, NULL controlado o una etiqueta explícita.

Actualizaciones condicionales

CASE también puede usarse dentro de UPDATE. Esto permite modificar registros según reglas calculadas al momento de la escritura.

El siguiente ejemplo desactiva clientes activos si su última renta ocurrió hace 90 días o más; en caso contrario, mantiene el registro activo:

UPDATE customer
SET active =
 CASE
 WHEN 90 <= (SELECT datediff(now(), max(rental_date))
 FROM rental r
 WHERE r.customer_id = customer.customer_id)
 THEN 0
 ELSE 1
 END
WHERE active = 1;

Esta aproximación concentra la regla en una sola sentencia SQL. Antes de ejecutar un UPDATE de este tipo en producción, conviene probar el mismo CASE en un SELECT, revisar cuántas filas cambiarán y ejecutar la operación dentro de una transacción si el motor lo permite.

Manejo de valores NULL

Los valores NULL aparecen con frecuencia cuando usamos LEFT OUTER JOIN, porque no siempre existe una fila relacionada. CASE nos permite reemplazarlos por un valor controlado para reportes o interfaces.

SELECT c.first_name, c.last_name,
 CASE
 WHEN a.address IS NULL THEN 'Unknown'
 ELSE a.address
 END address,
 CASE
 WHEN ct.city IS NULL THEN 'Unknown'
 ELSE ct.city
 END city,
 CASE
 WHEN cn.country IS NULL THEN 'Unknown'
 ELSE cn.country
 END country
FROM customer c
 LEFT OUTER JOIN address a
 ON c.address_id = a.address_id
 LEFT OUTER JOIN city ct
 ON a.city_id = ct.city_id
 LEFT OUTER JOIN country cn
 ON ct.country_id = cn.country_id;

En varios motores también existen funciones como COALESCE, útiles para este caso específico. Aun así, CASE sigue siendo preferible cuando la lógica depende de más de una condición o cuando el valor de salida no es simplemente el primer dato no nulo.

Cierre

La expresión CASE convierte SQL en una herramienta más expresiva para preparar datos cerca de donde viven. Con ella puedes clasificar filas, derivar columnas, controlar casos límite, ejecutar actualizaciones condicionales y normalizar valores faltantes.

Como regla práctica, usa CASE para reglas de presentación, clasificación y cálculo que pertenecen naturalmente al resultado de la consulta. Si la lógica empieza a depender de múltiples procesos externos o de reglas de dominio altamente cambiantes, evalúa moverla a una capa de aplicación o a una vista bien documentada.

En el siguiente artículo de la serie vamos a trabajar con agrupamiento y funciones agregadas, donde GROUP BY, COUNT, SUM y otras funciones nos permitirán resumir datos de manera consistente.

Estilos CSS: Posicionamiento, z-index y diseño responsive

Dacadev — Wed, 10 Jun 2026 00:00:00 -0500

Tabla de Contenido

Hasta ahora hemos trabajado con elementos que viven en el flujo normal del documento. El posicionamiento rompe ese flujo: te permite anclar una cabecera al viewport, superponer un modal, desplegar un menú o fijar una barra lateral mientras el usuario hace scroll. Combinado con z-index y las media queries, el posicionamiento es la base de las interacciones dinámicas y del diseño adaptable.

Esta es la quinta entrega de la serie Estilos CSS. Cubriremos los cinco valores de position, los contextos de apilamiento con z-index y los fundamentos del diseño responsive.

Note

Entenderás cuándo usar cada tipo de posicionamiento, por qué z-index a veces “no funciona” por culpa de los contextos de apilamiento, y cómo escribir media queries con un enfoque mobile first.

La propiedad position

La propiedad position acepta cinco valores que cambian cómo se ubica un elemento:

static (por defecto) — el elemento permanece en el flujo normal.
relative — se desplaza respecto a su posición original sin salir del flujo.
absolute — se extrae del flujo y se posiciona respecto a su ancestro posicionado más cercano.
fixed — se extrae del flujo y se posiciona respecto al viewport.
sticky — combina relative y fixed según el scroll.

Las propiedades top, right, bottom y left controlan la ubicación (y, en algunos casos, el tamaño) de los elementos posicionados.

Fixed: anclado al viewport

position: fixed extrae el elemento del flujo normal —los demás se reorganizan como si no existiera— y lo ancla a una posición relativa al viewport, donde permanece aunque el usuario haga scroll. Es la base de los modales: un fondo semitransparente que cubre toda la pantalla y un cuerpo centrado encima.

.modal-backdrop {
 position: fixed;
 top: 0; right: 0; bottom: 0; left: 0;
 background-color: rgba(0, 0, 0, 0.5);
}

.modal-body {
 position: fixed;
 top: 3em; bottom: 3em; right: 20%; left: 20%;
 background-color: white;
 overflow: auto;
}

Tip

Al posicionar no estás obligado a declarar los cuatro lados. Si omites bottom y height, la altura la determina el contenido de forma natural. Combinar lados con width/height te da control total sobre el tamaño.

Absolute: relativo al ancestro posicionado

position: absolute también extrae el elemento del flujo, pero se posiciona respecto al primer ancestro que tenga una posición distinta de static. Si ningún ancestro está posicionado, usa el bloque contenedor inicial (el tamaño del viewport).

Este es el patrón para colocar un botón de cierre en la esquina de un modal: el padre se marca como position: relative y el botón como position: absolute.

.modal-body { position: relative; }
.modal-close { position: absolute; top: 0.3em; right: 0.3em; }

✕ Cuerpo del modal

El botón de cierre está posicionado en la esquina con absolute respecto a este contenedor relative.

Relative: desplazamiento sin salir del flujo

A diferencia de los anteriores, position: relative no extrae el elemento del flujo; lo traslada respecto a su posición original, dejando su hueco intacto. Tampoco permite redimensionarlo con la combinación de lados.

Su uso más frecuente es establecer un bloque contenedor para descendientes absolutos. Es la base de un menú desplegable: el contenedor es relative y el menú es absolute, mostrándose con :hover.

.dropdown { position: relative; display: inline-block; }

.dropdown-menu { position: absolute; top: 100%; left: 0; display: none; }

.dropdown:hover .dropdown-menu { display: block; }

Menú principal ▾

Pasa el cursor sobre el botón para desplegar el menú.

Sticky: lo mejor de relative y fixed

position: sticky mantiene el elemento en su posición normal hasta que, al hacer scroll, alcanza el umbral definido por top/bottom; en ese momento se “pega” como si fuera fixed. Cuando el contenido vuelve, recupera su comportamiento relativo. Es ideal para barras laterales y cabeceras de sección que deben permanecer visibles.

.afijo { position: sticky; top: 1em; }

Stacking contexts y z-index

Cuando varios elementos posicionados se solapan, z-index controla el orden de apilamiento en el eje Z. Acepta enteros positivos y negativos: a mayor valor, más al frente.

.uno { position: relative; z-index: 1; }
.dos { position: relative; z-index: 2; } /* queda por encima de .uno */

Aquí está la trampa que confunde a muchos: cada elemento posicionado con z-index crea su propio contexto de apilamiento. Un hijo dentro de un contexto con z-index: 1 nunca podrá superar a un elemento de un contexto hermano con z-index: 2, aunque el hijo tenga z-index: 99999.

Warning

z-index tiene dos “gotchas”: solo funciona sobre elementos posicionados (cualquier position distinto de static), y al usarlo creas un nuevo contexto de apilamiento. Si un z-index enorme “no funciona”, casi siempre es porque su elemento está atrapado en un contexto de apilamiento de menor prioridad.

Responsive: estilos que se adaptan

La enorme variedad de pantallas obliga a diseñar interfaces que respondan a distintos tamaños. La filosofía mobile first consiste en escribir primero los estilos para móvil y luego ampliarlos progresivamente hacia tablets y escritorio.

Media queries

Una media query aplica un bloque de CSS solo cuando se cumple una condición sobre el viewport. Conviene usar em en los umbrales para que respeten el zoom y la configuración del usuario.

@media (min-width: 35em) {
 .titulo { font-size: 2.25rem; }
}

Puedes combinar condiciones con lógica:

/* AND: ambas condiciones */
@media (min-width: 20em) and (max-width: 35em) { /* ... */ }

/* OR: cualquiera de las dos */
@media (max-width: 20em), (min-width: 35em) { /* ... */ }

Entre las características consultables están min-width, max-width, min-height, orientation: landscape | portrait y min-resolution: 2dppx (para pantallas retina). El catálogo completo está en la documentación de @media en MDN.

Breakpoints con mobile first

Los breakpoints son los puntos donde el diseño cambia de un tamaño a otro. Con el enfoque mobile first, los estilos base sirven al móvil y cada media query añade ajustes para pantallas mayores:

.titulo { font-size: 1.5rem; } /* móvil (base) */

@media (min-width: 35em) { /* tablet */
 .titulo { font-size: 2rem; }
}

@media (min-width: 50em) { /* escritorio */
 .titulo { font-size: 2.5rem; }
}

Este título cambia de tamaño según el ancho

Redimensiona la ventana para cruzar los breakpoints de 35em y 50em.

Estilos para impresión

Las media queries también cubren el medio de impresión. @media print aplica reglas cuando el usuario imprime o exporta a PDF:

@media print {
 * { color: black !important; background: none !important; }
}

Conclusión

El posicionamiento te da control fino sobre dónde vive cada elemento: fixed para modales, absolute para tooltips y menús, relative como ancla, y sticky para elementos que acompañan el scroll. Sumado a un manejo consciente de los contextos de apilamiento y a media queries con enfoque mobile first, tienes las piezas para construir interfaces dinámicas y adaptables.

Note

🚀 La próxima entrega explora los fondos y las sombras: gradientes, modos de mezcla y las propiedades box-shadow y text-shadow para dar profundidad a tus componentes.

RxJs: Operadores de combinación de observables

Dacadev — Tue, 09 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una aplicación reactiva necesita coordinar eventos de teclado, clics, respuestas HTTP y temporizadores, el reto no está solo en crear observables, sino en decidir cómo sincronizar sus emisiones. Combinar observables RxJS correctamente evita acoplamiento innecesario, carreras difíciles de depurar y estados intermedios inconsistentes en la interfaz.

En este artículo analizaremos operadores y funciones de combinación de RxJS: startWith, endWith, concat, merge, combineLatest y forkJoin. Cada uno resuelve un problema distinto: inicializar un stream, añadir una emisión final, concatenar secuencias, mezclar eventos concurrentes, sincronizar últimos valores o esperar a que varias fuentes finalicen.

Note

Este artículo forma parte de la serie RxJs. Venimos de revisar Operadores no tan comunes y después continuaremos con Ajax con RxJs. Aquí nos enfocamos en operadores de combinación y en cómo elegir el adecuado según el comportamiento esperado del flujo.

`startWith`: inicializar un observable con una primera emisión

El operador startWith permite definir una o varias emisiones iniciales antes de que el observable fuente empiece a entregar sus propios valores. Es útil cuando una suscripción necesita un estado inicial inmediato, por ejemplo, para pintar una vista antes de que ocurra el primer evento real.

En el diagrama, el valor a se emite antes que cualquier valor proveniente del observable original. La suscripción no necesita esperar a que la fuente produzca el primer dato.

Ejemplo de uso:

import { of } from 'rxjs';
import { startWith } from 'rxjs/operators';

const numeros$ = of(1, 2, 3).pipe(
 startWith(3)
);

numeros$.subscribe(console.log);

Este flujo primero emite 3 por efecto de startWith(3) y después continúa con las emisiones de of(1, 2, 3). En escenarios de UI, este patrón suele aparecer cuando necesitas mostrar un valor por defecto antes de recibir eventos del usuario o datos remotos.

Tip

startWith no modifica la fuente original; crea un nuevo observable con emisiones prefijadas. Esta distinción mantiene la composición declarativa del pipeline.

`endWith`: añadir emisiones al completar el stream

El operador endWith trabaja en el extremo opuesto de startWith. En lugar de emitir valores al inicio, agrega emisiones al final, justo cuando el observable fuente completa.

Esto implica una condición importante: la fuente debe completar. Si el observable nunca envía la señal de complete, endWith no tendrá oportunidad de emitir sus valores finales.

El modo de uso puede combinar ambos operadores:

import { of } from 'rxjs';
import { startWith, endWith } from 'rxjs/operators';

const numeros$ = of(1, 2, 3).pipe(
 startWith('a', 'b', 'c'),
 endWith('x', 'y', 'z'),
);

numeros$.subscribe(console.log);

El resultado incluye las emisiones iniciales, los valores originales y las emisiones finales:

endWith es apropiado para flujos finitos donde quieres señalar un cierre lógico, adjuntar un marcador final o emitir un estado de terminación después de procesar una secuencia.

`concat`: combinar observables RxJS de forma secuencial

La función concat concatena observables uno detrás de otro. Se suscribe al primer observable, espera a que complete y solo entonces avanza al siguiente. El resultado es un observable nuevo que conserva el orden secuencial de las fuentes.

Warning

concat es una función de creación/combinación; no debe confundirse con concatMap. concatMap proyecta cada emisión hacia un observable interno y los aplana en orden. concat, en cambio, recibe fuentes ya definidas y las ejecuta secuencialmente.

El diagrama muestra que las emisiones del segundo stream no empiezan hasta que el primero completa. Esta propiedad es crítica cuando el orden tiene semántica de negocio, por ejemplo, inicializar una configuración antes de consumir un flujo dependiente.

Su modo de uso es:

import { concat, interval } from 'rxjs';
import { take } from 'rxjs/operators';

const intervalo$ = interval(1000);

concat(
 intervalo$.pipe(take(2)),
 intervalo$.pipe(take(3)),
 [1, 2, 3, 5] // un iterable u objeto compatible con ObservableInput
).subscribe(console.log);

El primer intervalo$.pipe(take(2)) emite dos valores y completa. Después se ejecuta el segundo intervalo$.pipe(take(3)). Finalmente, concat consume el arreglo [1, 2, 3, 5] como una fuente compatible con ObservableInput.

El resultado respeta ese orden:

La restricción operativa más importante es que cada fuente debe completar para que concat avance. Si el primer observable es infinito, el segundo nunca se suscribirá.

`merge`: combinar emisiones concurrentes en un solo observable

La función merge combina las emisiones de dos o más observables en un único stream de salida. A diferencia de concat, no espera a que una fuente complete para suscribirse a la siguiente; todas las fuentes activas pueden emitir de forma concurrente.

merge completa únicamente cuando todos los observables de entrada han completado. En streams de eventos del DOM, como click o keyup, esto normalmente significa que el flujo permanece activo durante toda la vida de la página, salvo que se aplique una estrategia de finalización explícita.

Modo de uso:

import { fromEvent, merge } from 'rxjs';
import { pluck } from 'rxjs/operators';

const keyup$ = fromEvent(document, 'keyup');
const click$ = fromEvent(document, 'click');

merge(
 keyup$.pipe(pluck('type')),
 click$.pipe(pluck('type'))
).subscribe(console.log);

En este caso, ambos observables se transforman para emitir únicamente el tipo de evento. El stream resultante recibe tanto keyup como click, sin imponer un orden artificial entre ellos.

El resultado en consola evidencia que ambos eventos se combinan en una sola suscripción:

Info

merge es una buena elección cuando las fuentes son independientes y quieres reaccionar a cualquiera de ellas con la misma lógica de downstream.

`combineLatest`: sincronizar los últimos valores emitidos

La función combineLatest combina múltiples observables y emite un arreglo con el último valor disponible de cada fuente. Su comportamiento tiene una regla clave: no emite hasta que todos los observables participantes hayan emitido al menos una vez.

Después de esa primera sincronización, cada nueva emisión de cualquier fuente produce una nueva salida con el valor actualizado de esa fuente y los últimos valores conocidos de las demás. Esto es especialmente útil para formularios, filtros, coordenadas de UI y estados derivados.

El código de uso puede ser parecido a esto:

import { combineLatest, fromEvent } from 'rxjs';
import { pluck } from 'rxjs/operators';

const input1 = document.createElement('input');
const input2 = document.createElement('input');

input1.placeholder = 'email@example.com';

input2.placeholder = '*******';
input2.type = 'password';

document.querySelector('body')?.append(input1, input2);

// helper
const getInputString = (elem: HTMLElement) => {
 return fromEvent<KeyboardEvent>(elem, 'keyup')
 .pipe(
 pluck<KeyboardEvent>('target', 'value')
 );
};

combineLatest(
 getInputString(input1),
 getInputString(input2)
).subscribe(console.log);

El ejemplo conserva la firma posicional usada durante mucho tiempo en RxJS. En código moderno, especialmente con RxJS 7+, suele preferirse la firma con arreglo porque escala mejor y es más explícita:

combineLatest([
 getInputString(input1),
 getInputString(input2),
]).subscribe(console.log);

También conviene considerar que pluck pertenece a un estilo más antiguo de transformación. Para proyectos nuevos, map con acceso explícito suele ser más legible y compatible con la evolución del ecosistema.

Warning

Si una de las fuentes de combineLatest nunca emite, el observable combinado tampoco emitirá. Para evitar estados bloqueados, puedes inicializar fuentes con startWith cuando tenga sentido semántico.

`forkJoin`: esperar la última emisión de observables finitos

La función forkJoin emite una sola vez con la última emisión de cada observable de entrada, pero únicamente cuando todos completan. Este comportamiento la convierte en una herramienta precisa para coordinar operaciones finitas, como peticiones HTTP simultáneas.

Warning

Los observables pasados a forkJoin deben ser finitos. Si alguno nunca completa, forkJoin nunca emitirá resultado.

El diagrama muestra que la salida aparece al final, cuando todas las fuentes han completado y existe un último valor para cada una.

Modo de uso:

import { of, interval, forkJoin } from 'rxjs';
import { take, delay } from 'rxjs/operators';

const numeros$ = of(1, 2, 3, 4);
const intervalo$ = interval(1000).pipe(take(3));
const letras$ = of('a', 'b', 'c').pipe(delay(3500));

// forkJoin(
// numeros$,
// intervalo$,
// letras$
// ).subscribe(console.log);

// forkJoin(
// numeros$,
// intervalo$,
// letras$
// ).subscribe(resp => {
// console.log('numeros', resp[0]);
// console.log('intervalo', resp[1]);
// console.log('letras', resp[2]);
// });

// forkJoin({
// numeros$,
// intervalo$,
// letras$
// }).subscribe(resp => {
// console.log(resp);
// });

forkJoin({
 num: numeros$,
 int: intervalo$,
 let: letras$
}).subscribe(resp => {
 console.log(resp);
});

La forma con objeto es especialmente práctica porque conserva nombres semánticos en la respuesta. En lugar de depender de índices como resp[0], resp[1] o resp[2], el consumidor trabaja con propiedades explícitas: num, int y let.

Tip

El uso más común de forkJoin aparece cuando haces peticiones AJAX simultáneas y necesitas continuar solo cuando todas han terminado correctamente.

Cómo elegir entre `concat`, `merge`, `combineLatest` y `forkJoin`

Estos operadores pueden parecer similares porque todos combinan fuentes, pero su semántica de tiempo es distinta:

Usa concat cuando el orden secuencial sea obligatorio y cada fuente deba completar antes de iniciar la siguiente.
Usa merge cuando las fuentes sean independientes y quieras reaccionar a cualquiera de ellas tan pronto como emita.
Usa combineLatest cuando necesites calcular estado derivado a partir del último valor conocido de varias fuentes activas.
Usa forkJoin cuando esperes observables finitos y solo necesites el resultado final de cada uno.
Usa startWith y endWith para insertar emisiones de inicio o cierre dentro de un pipeline.

Esta elección tiene impacto directo en latencia, orden de ejecución y condiciones de completado. En sistemas reactivos, estos detalles definen si el flujo se mantiene responsivo o si queda bloqueado esperando una emisión que nunca llega.

Conclusión

Combinar observables RxJS requiere distinguir entre concurrencia, secuencialidad y sincronización de valores. concat serializa fuentes, merge las mezcla, combineLatest deriva estado desde los últimos valores y forkJoin espera resultados finales de observables finitos.

Dominar estas diferencias permite diseñar pipelines más predecibles y expresivos. En el siguiente artículo aplicaremos estos conceptos al trabajo con peticiones AJAX, donde forkJoin, mergeMap y otros operadores empiezan a interactuar con latencia real de red y manejo de errores.

Estilos CSS: Layouts con Float, Flexbox y Grid

Dacadev — Mon, 08 Jun 2026 00:00:00 -0500

Tabla de Contenido

Maquetar es componer la estructura visual de una página: columnas, rejillas, barras laterales, galerías. Durante años se hizo con herramientas que no se diseñaron para ello —float nació para envolver texto alrededor de imágenes— hasta que llegaron Flexbox y CSS Grid, dos sistemas pensados específicamente para layout. Conocer los tres te permite entender el código heredado y elegir la herramienta correcta para cada problema.

Esta es la cuarta entrega de la serie Estilos CSS. Recorreremos float y la técnica clearfix, el modelo unidimensional de Flexbox y el sistema bidimensional de Grid, con ejemplos que puedes ver renderizados.

Note

Aprenderás cuándo sigue siendo útil float, cómo controlar el tamaño de los ítems con flex, y cómo posicionar elementos en una rejilla con grid-template.

Float: el origen y el clearfix

float extrae un elemento del flujo normal y lo desplaza hacia un lado de su contenedor; el contenido adyacente fluye a su alrededor. Ese fue su propósito original: envolver texto alrededor de una imagen.

.imagen { float: left; margin-right: 1em; }

float

Este párrafo fluye alrededor del bloque flotado. El texto se ajusta al margen del elemento extraído del flujo, exactamente el caso de uso para el que float fue concebido: envolver contenido alrededor de una figura.

Cuando usas float, necesitas limpiar el flujo para que el contenedor vuelva a comportarse con normalidad. El patrón estándar es el clearfix, implementado con un pseudo-elemento:

.clearfix::before,
.clearfix::after {
 display: table;
 content: " ";
}

.clearfix::after {
 clear: both;
}

Tip

Para layouts modernos, float casi siempre se reemplaza por Flexbox o Grid. Resérvalo para su propósito original: envolver texto alrededor de un elemento.

Flexbox: layout en una dimensión

Al aplicar display: flex a un contenedor, este se convierte en un flex container y sus hijos en flex items. Flexbox organiza los ítems a lo largo de un eje principal y los alinea en el eje transversal, ajustando tamaños de forma flexible.

Un contenedor flex tiene dos ejes:

Eje principal (main) — la dirección en la que se colocan los ítems (horizontal por defecto).
Eje transversal (cross) — perpendicular al principal.

Alinear ítems con justify-content y align-items

justify-content controla la distribución a lo largo del eje principal: flex-start, flex-end, center, space-between, space-around.
align-items controla la alineación en el eje transversal: stretch (por defecto), flex-start, flex-end, center, baseline.

.barra {
 display: flex;
 justify-content: space-between;
 align-items: center;
}

Logo Menú Perfil

Controlar el tamaño: flex-grow, flex-shrink y flex-basis

La propiedad abreviada flex agrupa tres propiedades que gobiernan el tamaño de cada ítem:

flex-basis — el tamaño base (de partida) del ítem antes de crecer o encoger. Su valor inicial es auto.
flex-grow — el factor de crecimiento para repartir el espacio sobrante. 0 no crece.
flex-shrink — el factor de encogimiento cuando falta espacio.

.col-a { flex: 1; } /* crece para ocupar el espacio sobrante */
.col-b { flex: 2; } /* crece al doble que col-a */

flex: 1

flex: 2 (el doble de ancho)

Dirección y envoltura

flex-direction cambia el eje principal: row (por defecto), row-reverse, column, column-reverse.
flex-wrap permite que los ítems salten a una nueva línea cuando no caben: nowrap (por defecto), wrap, wrap-reverse.
flex-flow es la abreviatura de ambas: flex-flow: row wrap.

Propiedades del ítem

align-self — sobrescribe align-items para un ítem concreto.
order — reordena los ítems sin tocar el HTML; el valor inicial es 0.

Info

Flexbox crea automáticamente columnas de igual altura y es la herramienta ideal para centrar un elemento. Para un catálogo de bugs conocidos y sus soluciones, consulta flexbugs.

CSS Grid: layout en dos dimensiones

Mientras Flexbox trabaja en un solo eje, CSS Grid organiza el contenido en filas y columnas simultáneamente. Antes de usarlo conviene fijar su vocabulario:

Grid line — las líneas que forman la estructura de la rejilla.
Grid track — el espacio entre dos líneas adyacentes (una fila o una columna).
Grid cell — la intersección de una fila y una columna.
Grid area — un rectángulo formado por una o más celdas.

Una rejilla básica

Se activa con display: grid y se definen las pistas con grid-template-columns y grid-template-rows. La unidad fr representa una fracción del espacio disponible.

.grid {
 display: grid;
 grid-template-columns: 1fr 1fr 1fr;
 gap: 0.5em;
}

La función repeat() evita la repetición: grid-template-columns: repeat(3, 1fr) equivale a 1fr 1fr 1fr.

Posicionar ítems por líneas

Cada línea de la rejilla tiene un número. Con grid-column y grid-row indicas dónde empieza y termina un ítem usando la sintaxis inicio / fin:

.destacado {
 grid-column: 1 / 3; /* abarca de la línea 1 a la 3 */
 grid-row: span 2; /* abarca dos pistas verticales */
}

grid-column: 1 / 3

Áreas con nombre

La forma más legible de componer un layout es nombrar las áreas con grid-template-areas y asignar cada elemento con grid-area:

.contenedor {
 display: grid;
 grid-template-areas:
 "titulo titulo"
 "nav nav"
 "main aside";
 grid-template-columns: 2fr 1fr;
 gap: 1em;
}

header { grid-area: titulo; }
nav { grid-area: nav; }
.main { grid-area: main; }
.aside { grid-area: aside; }

titulo

nav

main

aside

Rejilla implícita y galerías responsivas

Cuando no conoces de antemano la cantidad de ítems —por ejemplo, datos que vienen de una API— la rejilla implícita crece automáticamente para acomodarlos. La combinación de auto-fill con minmax() produce galerías que se adaptan al ancho disponible sin media queries:

.galeria {
 display: grid;
 grid-template-columns: repeat(auto-fill, minmax(180px, 1fr));
 gap: 1em;
}

Redimensiona la ventana: las columnas se reorganizan solas.

Warning

Con Grid solo puedes formar rectángulos. No se pueden crear formas en L o U directamente; se simulan dejando celdas vacías (con . en grid-template-areas) o combinando áreas.

Flexbox y Grid: complementarios, no rivales

No tienes que elegir uno. La combinación más potente es usar Grid para la estructura macro de la página (cabecera, contenido, barra lateral, pie) y Flexbox para alinear el contenido dentro de cada zona (una barra de navegación, una tarjeta, un grupo de botones).

Conclusión

float resuelve el envolvimiento de texto; Flexbox domina el layout en una dimensión y el centrado; Grid organiza estructuras bidimensionales complejas. Elegir la herramienta adecuada para cada problema —y combinarlas— es lo que distingue una maquetación robusta de una llena de parches.

Note

🚀 En la próxima entrega abordamos el posicionamiento (relative, absolute, fixed, sticky), los contextos de apilamiento con z-index y el diseño responsive con media queries.

SQL: Filtrado de Datos con la Cláusula WHERE

Dacadev — Mon, 08 Jun 2026 00:00:00 -0500

Tabla de Contenido

El filtrado de datos en SQL es una operación diaria cuando trabajas con bases relacionales: rara vez necesitas todas las filas de una tabla. La cláusula WHERE expresa condiciones precisas para reducir resultados, evitar lecturas innecesarias y alinear la consulta con la lógica de negocio. Este es el artículo #2 de la serie SQL; si necesitas repasar SELECT, FROM y el modelo general de consulta, revisa Fundamentos de SQL.

Note

Aprenderás a usar WHERE con igualdad, desigualdad, rangos, BETWEEN, IN, subconsultas, LIKE, expresiones regulares y NULL, tanto en lectura como en modificación.

La cláusula WHERE y las condiciones booleanas

La cláusula WHERE filtra filas evaluando una o más condiciones. Cada condición produce un resultado lógico que el motor de base de datos usa para decidir si una fila entra o no en el resultado final.

En la práctica, esas condiciones suelen combinar varios tipos de operadores:

Operadores de comparación: =, !=, <, >, <>, LIKE, IN, BETWEEN.
Operadores aritméticos: +, -, *, /, cuando necesitas comparar expresiones calculadas.
Operadores lógicos: AND, OR, NOT, para componer filtros más específicos.

Aunque WHERE es el punto central para filtrar filas, también existe HAVING, que se utiliza después de agrupar datos con GROUP BY. La diferencia es importante: WHERE filtra filas antes de la agregación; HAVING filtra grupos después de calcular agregados.

Condiciones de igualdad

La condición de igualdad compara una columna contra una expresión. Esa expresión puede ser un literal, un número, una fecha o incluso el resultado de una subconsulta.

title = 'RIVER OUTLAW'
fed_id = '111-11-1111'
amount = 375.25
film_id = (SELECT film_id FROM film WHERE title = 'RIVER OUTLAW')

Observemos un caso concreto usando la base de datos de ejemplo Sakila. La consulta obtiene los correos de clientes que rentaron películas el 2005-06-14:

mysql> SELECT c.email
 -> FROM customer c
 -> INNER JOIN rental r
 -> ON c.customer_id = r.customer_id
 -> WHERE date(r.rental_date) = '2005-06-14';
+---------------------------------------+
| email |
+---------------------------------------+
| CATHERINE.CAMPBELL@sakilacustomer.org |
| JOYCE.EDWARDS@sakilacustomer.org |
...
| TERRENCE.GUNDERSON@sakilacustomer.org |
+---------------------------------------+
16 rows in set (0.03 sec)

Aquí date(r.rental_date) transforma el DATETIME a fecha antes de comparar. En producción, aplicar funciones sobre columnas puede limitar el uso eficiente de índices.

Condiciones de desigualdad

La desigualdad expresa el caso contrario: queremos excluir filas que coinciden con un valor. En SQL puedes escribirla con <>, != o usando NOT según el motor y el estilo del equipo.

mysql> SELECT c.email
 -> FROM customer c
 -> INNER JOIN rental r
 -> ON c.customer_id = r.customer_id
 -> WHERE date(r.rental_date) <> '2005-06-14';

+-----------------------------------+
| email |
+-----------------------------------+
...
| AUSTIN.CINTRON@sakilacustomer.org |
| AUSTIN.CINTRON@sakilacustomer.org |
| AUSTIN.CINTRON@sakilacustomer.org |
| AUSTIN.CINTRON@sakilacustomer.org |
+-----------------------------------+
16028 rows in set (0.03 sec)

La diferencia semántica es directa: en lugar de seleccionar rentas del día indicado, excluimos ese día.

Modificación de datos con condiciones de igualdad

WHERE no solo aparece en SELECT. También es crítico en UPDATE y DELETE, donde define exactamente qué filas serán modificadas o eliminadas.

DELETE FROM rental
WHERE year(rental_date) = 2004;

DELETE FROM rental
WHERE year(rental_date) <> 2005 AND year(rental_date) <> 2006;

El primer caso elimina rentas del año 2004; el segundo elimina rentas que no pertenecen ni a 2005 ni a 2006.

Warning

Antes de ejecutar un DELETE o UPDATE con WHERE, valida la condición con un SELECT equivalente. Un filtro demasiado amplio puede modificar más filas de las esperadas.

Condiciones de rango

Para filtrar rangos puedes combinar operadores como <, <=, > y >= con AND u OR. Esto funciona con fechas, números y otros tipos comparables.

mysql> SELECT customer_id, rental_date
 -> FROM rental
 -> WHERE rental_date < '2005-05-25';
+-------------+---------------------+
| customer_id | rental_date |
+-------------+---------------------+
| 130 | 2005-05-24 22:53:30 |
| 459 | 2005-05-24 22:54:33 |
...
| 239 | 2005-05-24 23:31:46 |
+-------------+---------------------+
8 rows in set (0.00 sec)

mysql> SELECT customer_id, rental_date
 -> FROM rental
 -> WHERE rental_date <= '2005-06-16'
 -> AND rental_date >= '2005-06-14';
+-------------+---------------------+
| customer_id | rental_date |
+-------------+---------------------+
| 416 | 2005-06-14 22:53:33 |
| 516 | 2005-06-14 22:55:13 |
...
| 148 | 2005-06-15 23:20:26 |
| 237 | 2005-06-15 23:36:37 |
| 155 | 2005-06-15 23:55:27 |
| 341 | 2005-06-15 23:57:20 |
| 149 | 2005-06-15 23:58:53 |
+-------------+---------------------+
364 rows in set (0.00 sec)

Usando BETWEEN

BETWEEN permite expresar un rango con una sintaxis más compacta. El valor menor va a la izquierda, el mayor a la derecha, y ambos límites son inclusivos.

mysql> SELECT customer_id, rental_date
 -> FROM rental
 -> WHERE rental_date BETWEEN '2005-06-14' AND '2005-06-16';
+-------------+---------------------+
| customer_id | rental_date |
+-------------+---------------------+
| 416 | 2005-06-14 22:53:33 |
| 516 | 2005-06-14 22:55:13 |
...
| 148 | 2005-06-15 23:20:26 |
| 237 | 2005-06-15 23:36:37 |
| 155 | 2005-06-15 23:55:27 |
| 341 | 2005-06-15 23:57:20 |
| 149 | 2005-06-15 23:58:53 |
+-------------+---------------------+
364 rows in set (0.00 sec)

Tip

BETWEEN puede usarse con fechas, horas, números y strings. Recuerda que los límites son inclusivos, así que valida cuidadosamente rangos de tiempo cuando trabajes con columnas DATETIME.

Condiciones de pertenencia con IN

Las condiciones de pertenencia permiten verificar si un valor existe dentro de una lista. Primero, analicemos la versión con OR:

mysql> SELECT title, rating
 -> FROM film
 -> WHERE rating = 'G' OR rating = 'PG';
+---------------------------+--------+
| title | rating |
+---------------------------+--------+
| ACADEMY DINOSAUR | PG |
| ACE GOLDFINGER | G |
...
| WEDDING APOLLO | PG |
| WEREWOLF LOLA | G |
| WEST LION | G |
...
| YOUNG LANGUAGE | G |
+---------------------------+--------+
372 rows in set (0.00 sec)

La misma condición puede escribirse de forma más clara con IN:

SELECT title, rating
FROM film
WHERE rating IN ('G','PG');

También puedes combinar pertenencia y negación usando NOT IN:

SELECT title, rating
FROM film
WHERE rating NOT IN ('PG-13','R', 'NC-17');

IN mejora la legibilidad cuando comparas una columna contra múltiples valores discretos y evita repetir la misma columna.

Subconsultas dentro de IN

IN no está limitado a listas escritas manualmente. También puedes usar una subconsulta para calcular dinámicamente los valores válidos de comparación.

mysql> SELECT title, rating
 -> FROM film
 -> WHERE rating IN (SELECT rating FROM film WHERE title LIKE '%PET%');
+---------------------------+--------+
| title | rating |
+---------------------------+--------+
| ACADEMY DINOSAUR | PG |
| ACE GOLDFINGER | G |
...
| WEDDING APOLLO | PG |
| WEREWOLF LOLA | G |
| WEST LION | G |
...
| YOUNG LANGUAGE | G |
+---------------------------+--------+
372 rows in set (0.00 sec)

La subconsulta obtiene los rating de películas cuyo título contiene PET; la consulta externa recupera las películas con esos ratings.

Condiciones de coincidencia con LIKE

Las condiciones de coincidencia permiten buscar patrones de texto en lugar de valores exactos. Con LIKE, SQL ofrece dos comodines principales:

Comodín	Significado
`_`	Exactamente un carácter
`%`	Cualquier cantidad de caracteres, incluyendo cero

Consideremos este patrón: _A_T%S. Significa: un carácter cualquiera, luego A, luego un carácter cualquiera, luego T, luego cualquier secuencia, y finalmente S.

mysql> SELECT last_name, first_name
 -> FROM customer
 -> WHERE last_name LIKE '_A_T%S';
+-----------+------------+
| last_name | first_name |
+-----------+------------+
| MATTHEWS | ERICA |
| WALTERS | CASSANDRA |
| WATTS | SHELLY |
+-----------+------------+
3 rows in set (0.00 sec)

LIKE es útil para búsquedas simples. Un patrón que inicia con %, como '%PET%', suele ser más costoso porque limita el uso de índices tradicionales.

Expresiones regulares

Algunos motores permiten filtrar texto con expresiones regulares. En MySQL, por ejemplo, se usa REGEXP. Otros motores tienen variantes propias, así que siempre valida la sintaxis de tu base de datos.

mysql> SELECT last_name, first_name
 -> FROM customer
 -> WHERE last_name REGEXP '^[QY]';
+-------------+------------+
| last_name | first_name |
+-------------+------------+
| YOUNG | CYNTHIA |
| QUALLS | STEPHEN |
| QUINTANILLA | ROGER |
| YANEZ | LUIS |
| YEE | MARVIN |
| QUIGLEY | TROY |
+-------------+------------+
6 rows in set (0.16 sec)

El patrón ^[QY] indica que el apellido debe iniciar con Q o Y. Las expresiones regulares son más expresivas que LIKE, pero menos portables entre motores.

Filtrado de valores NULL

NULL es un caso especial en SQL. No representa false, cero ni una cadena vacía; representa ausencia de valor o valor desconocido. Por esa razón, no debes comparar NULL con =.

Para consultar valores nulos se usa IS NULL, y para excluirlos se usa IS NOT NULL.

mysql> SELECT rental_id, customer_id
 -> FROM rental
 -> WHERE return_date IS NULL;
+-----------+-------------+
| rental_id | customer_id |
+-----------+-------------+
| 11496 | 155 |
| 11541 | 335 |
...
| 15867 | 505 |
| 15875 | 41 |
| 15894 | 168 |
| 15966 | 374 |
+-----------+-------------+
183 rows in set (0.01 sec)

Info

NULL = NULL no se evalúa como verdadero en SQL estándar. Cuando una comparación involucra NULL, el resultado puede ser desconocido; por eso IS NULL y IS NOT NULL son operadores específicos para este caso.

Cierre

La cláusula WHERE convierte una tabla completa en un conjunto de filas relevante. Dominar igualdad, desigualdad, rangos, pertenencia, patrones y NULL te permite escribir consultas más precisas y seguras.

Como regla práctica, diseña filtros explícitos, valida condiciones destructivas con SELECT, y considera el impacto de funciones, comodines y expresiones regulares sobre los índices. En el siguiente artículo abordaremos Lógica condicional con CASE, una herramienta clave para transformar valores dentro de tus consultas.

RxJs: Operadores no tan comunes

Dacadev — Sun, 07 Jun 2026 00:00:00 -0500

Tabla de Contenido

En flujos reactivos de interfaz, temporizadores o eventos del DOM, no siempre necesitas transformar cada emisión. Con frecuencia el problema operativo consiste en limitar una suscripción, cancelar un Observable ante una señal externa o eliminar emisiones repetidas. Estos operadores RxJS resuelven ese tipo de control sin introducir estado mutable adicional ni lógica imperativa alrededor de la suscripción.

Note

Este artículo forma parte de la serie RxJs. Venimos de revisar operadores de transformación y aquí analizaremos take, first, takeWhile, takeUntil, skip, distinct, distinctUntilChanged y distinctUntilKeyChanged. El siguiente artículo aborda los operadores de combinación.

La referencia formal de estos operadores está en la documentación oficial de RxJS y en el modelo conceptual de ReactiveX. En este artículo nos concentraremos en su comportamiento práctico, especialmente en cuándo completan el flujo y cómo comparan valores.

`take`: limitar emisiones de un Observable

take permite definir cuántas emisiones del Observable fuente queremos recibir. Una vez alcanza ese límite, el operador completa la cadena y cancela la suscripción aguas arriba.

Este patrón es útil cuando el consumidor solo necesita una muestra finita de un flujo potencialmente largo, como los primeros eventos, los primeros valores de un intervalo o una respuesta inicial.

import { of } from "rxjs";
import { take, tap } from "rxjs/operators";

const numeros$ = of(1, 2, 3, 4, 5);

numeros$
 .pipe(
 tap((valor) => console.log("tap", valor)),
 take(3),
 )
 .subscribe({
 next: (valor) => console.log("next", valor),
 complete: () => console.log("complete"),
 });

El tap se ejecuta solo para los valores que alcanzan la suscripción antes de que take(3) complete el flujo.

Tip

take es una forma declarativa de evitar suscripciones más largas de lo necesario. En flujos infinitos como interval, puede prevenir fugas si el ciclo de vida esperado es finito.

`first`: tomar la primera emisión o la primera que cumpla una condición

first obtiene la primera emisión del Observable y completa la suscripción. Su caso básico se parece a take(1), pero también acepta un predicado para esperar la primera emisión que cumpla una condición.

import { fromEvent } from "rxjs";
import { first } from "rxjs/operators";

const click$ = fromEvent<PointerEvent>(document, "click");

click$.pipe(first()).subscribe({
 next: (event) => console.log("next", event),
 complete: () => console.log("complete"),
});

Después del primer clic, el flujo completa y deja de escuchar nuevos eventos.

`first` con predicado

Cuando first recibe un predicado, ignora las emisiones previas hasta encontrar la primera que devuelva true.

import { fromEvent } from "rxjs";
import { first, tap } from "rxjs/operators";

const click$ = fromEvent<PointerEvent>(document, "click");

click$
 .pipe(
 tap(() => console.log("tap")),
 first((event) => event.clientY >= 150),
 )
 .subscribe({
 next: (event) => console.log("next", event),
 complete: () => console.log("complete"),
 });

El tap confirma que el flujo sigue recibiendo clics, pero first solo emite cuando la coordenada clientY cumple la condición.

Warning

Si la fuente completa sin que el predicado de first se cumpla, RxJS puede emitir un error EmptyError. Considera un valor por defecto o un operador alternativo cuando ese escenario sea válido.

`takeWhile`: emitir mientras se mantenga una condición

takeWhile mantiene la suscripción activa mientras el predicado devuelva true. En cuanto una emisión no cumple la condición, el operador completa el flujo.

En este ejemplo tomamos clics mientras la coordenada y sea menor o igual a 150.

import { fromEvent } from "rxjs";
import { map, takeWhile } from "rxjs/operators";

const click$ = fromEvent<PointerEvent>(document, "click");

click$
 .pipe(
 map(({ x, y }) => ({ x, y })),
 takeWhile(({ y }) => y <= 150, true),
 )
 .subscribe({
 next: (coords) => console.log("next", coords),
 complete: () => console.log("complete"),
 });

El segundo argumento, conocido como bandera inclusive, indica si la emisión que rompe la condición también debe enviarse al suscriptor. Por defecto es false; con true, el valor que provoca el cierre se conserva.

Info

takeWhile modela límites basados en datos. Es diferente de filter: filter descarta valores y continúa; takeWhile completa el flujo cuando la condición deja de cumplirse.

`takeUntil`: cancelar un flujo con otro Observable

takeUntil recibe un segundo Observable, llamado normalmente notifier. El flujo principal emite hasta que ese notifier produce su primera emisión; en ese momento la cadena completa.

Este patrón es común para cancelar intervalos, peticiones, listeners o cualquier proceso reactivo asociado al ciclo de vida de un componente.

import { fromEvent, interval } from "rxjs";
import { takeUntil } from "rxjs/operators";

const boton = document.createElement("button");
boton.innerHTML = "Detener timing";

document.querySelector("body")?.append(boton);

const counter$ = interval(1000);
const click$ = fromEvent(boton, "click");

counter$.pipe(takeUntil(click$)).subscribe({
 next: (valor) => console.log("next", valor),
 complete: () => console.log("complete"),
});

El contador sigue emitiendo cada segundo hasta que el botón produce un evento click.

Tip

En aplicaciones con componentes, takeUntil suele conectarse a una señal de destrucción para liberar recursos y cerrar suscripciones de forma predecible.

`skip`: omitir emisiones iniciales

skip ignora las primeras n emisiones del Observable fuente y deja pasar las posteriores. Es útil cuando las primeras señales representan inicialización, ruido operativo o eventos que no deben activar la lógica principal.

Aplicado al ejemplo anterior, podemos exigir varios clics antes de cancelar el contador. Con skip(2), el tercer clic es el primero que llega a takeUntil.

import { fromEvent, interval } from "rxjs";
import { skip, takeUntil, tap } from "rxjs/operators";

const boton = document.createElement("button");
boton.innerHTML = "Detener timing";

document.querySelector("body")?.append(boton);

const counter$ = interval(1000);
const click$ = fromEvent(boton, "click").pipe(
 tap(() => console.log("tap-antes")),
 skip(2),
 tap(() => console.log("tap-despues")),
);

counter$.pipe(takeUntil(click$)).subscribe({
 next: (valor) => console.log("next", valor),
 complete: () => console.log("complete"),
});

La salida muestra que los primeros clics existen, pero no cruzan la frontera marcada por skip.

`distinct`: eliminar valores repetidos globalmente

distinct evita que el flujo emita valores ya observados previamente. La comparación base usa igualdad estricta (===), por lo que tipo y valor deben coincidir.

import { of } from "rxjs";
import { distinct } from "rxjs/operators";

const numeros$ = of(1, 1, 1, 3, 3, 2, 2, 4, 5, 3, 1);

numeros$.pipe(distinct()).subscribe(console.log);

El operador conserva una memoria interna de valores ya emitidos y descarta repeticiones posteriores.

`distinct` con selector para objetos

Con objetos, dos instancias con la misma estructura no son iguales por referencia. Para resolverlo, distinct acepta un selector que define la clave de comparación.

import { from } from "rxjs";
import { distinct } from "rxjs/operators";

interface Personaje {
 nombre: string;
}

const personajes: Personaje[] = [
 { nombre: "Megaman" },
 { nombre: "Zero" },
 { nombre: "X" },
 { nombre: "Zero" },
 { nombre: "Zero" },
 { nombre: "Zero" },
 { nombre: "X" },
 { nombre: "Megaman" },
 { nombre: "Megaman" },
];

from(personajes)
 .pipe(distinct((personaje) => personaje.nombre))
 .subscribe(console.log);

En este caso la unicidad se calcula por nombre, no por referencia del objeto.

Warning

distinct mantiene un registro de claves ya vistas. En flujos largos o infinitos, evalúa el impacto en memoria o usa una estrategia con cierre explícito.

`distinctUntilChanged`: evitar repeticiones consecutivas

distinctUntilChanged compara cada emisión con la emisión inmediatamente anterior. Solo descarta duplicados consecutivos; si un valor reaparece más adelante después de otro valor distinto, puede emitirse de nuevo.

import { of } from "rxjs";
import { distinctUntilChanged } from "rxjs/operators";

const numeros$ = of(1, "1", 1, 1, 3, 3, 2, 2, 2, 4, 5, 3, 1);

numeros$.pipe(distinctUntilChanged()).subscribe(console.log);

La igualdad por defecto también usa ===; por eso 1 y "1" no se consideran duplicados.

`distinctUntilChanged` con comparador

Para objetos, el comparador recibe el valor anterior y el actual. Debe retornar true cuando ambos se consideran equivalentes y, por tanto, el valor actual debe omitirse.

import { from } from "rxjs";
import { distinctUntilChanged } from "rxjs/operators";

interface Personaje {
 nombre: string;
}

const personajes: Personaje[] = [
 { nombre: "Megaman" },
 { nombre: "Megaman" },
 { nombre: "Zero" },
 { nombre: "X" },
 { nombre: "Zero" },
 { nombre: "Zero" },
 { nombre: "Zero" },
 { nombre: "X" },
 { nombre: "Megaman" },
 { nombre: "Megaman" },
];

from(personajes)
 .pipe(
 distinctUntilChanged(
 (anterior, actual) => anterior.nombre === actual.nombre,
 ),
 )
 .subscribe(console.log);

El flujo descarta únicamente los personajes consecutivos con el mismo nombre.

`distinctUntilKeyChanged`: comparación consecutiva por propiedad

distinctUntilKeyChanged aplica la misma idea de distinctUntilChanged, pero optimizada para objetos cuando la comparación depende de una propiedad concreta.

import { from } from "rxjs";
import { distinctUntilKeyChanged } from "rxjs/operators";

interface Personaje {
 nombre: string;
}

const personajes: Personaje[] = [
 { nombre: "Megaman" },
 { nombre: "Megaman" },
 { nombre: "Zero" },
 { nombre: "X" },
 { nombre: "Zero" },
 { nombre: "Zero" },
 { nombre: "Zero" },
 { nombre: "X" },
 { nombre: "Megaman" },
 { nombre: "Megaman" },
];

from(personajes)
 .pipe(distinctUntilKeyChanged("nombre"))
 .subscribe(console.log);

La intención queda más explícita que con un comparador manual cuando solo necesitas evaluar una clave.

Conclusión

Estos operadores no son secundarios; resuelven decisiones críticas de ciclo de vida, cancelación y deduplicación en flujos reactivos. take, first, takeWhile, takeUntil y skip controlan cuántas emisiones llegan al consumidor y cuándo termina la suscripción. distinct, distinctUntilChanged y distinctUntilKeyChanged controlan repetición y semántica de igualdad.

La regla práctica es seleccionar el operador según el límite que necesitas expresar: cantidad, condición, señal externa, emisiones iniciales o duplicados. Esa precisión mantiene tus pipelines de RxJS más declarativos, auditables y fáciles de mantener.

Estilos CSS: Dominando el modelo de caja

Dacadev — Sat, 06 Jun 2026 00:00:00 -0500

Tabla de Contenido

El modelo de caja es el sistema con el que CSS calcula el tamaño y el espaciado de cada elemento. Parece trivial, pero es la fuente número uno de layouts impredecibles: un width: 50% que termina midiendo más de la mitad, dos columnas que no encajan, márgenes que desaparecen sin razón aparente. Todos esos síntomas se explican entendiendo cómo el navegador compone una caja.

Esta es la tercera entrega de la serie Estilos CSS. Analizaremos las cuatro regiones de una caja, el cambio de comportamiento que introduce box-sizing, el control de overflow, el manejo de alturas, el centrado vertical y el colapso de márgenes.

Note

Comprenderás por qué box-sizing: border-box debería ser tu valor por defecto y aprenderás a resolver los problemas clásicos de altura, centrado vertical y colapso de márgenes.

Las cuatro regiones de una caja

Todo elemento HTML se compone, de adentro hacia afuera, de cuatro capas:

content — el área donde vive el contenido (texto, imágenes).
padding — el espacio interno entre el contenido y el borde.
border — el borde que rodea el padding.
margin — el espacio externo que separa la caja de sus vecinos.

<div class="caja">content + padding + border + margin</div>

content

El área azul es el content; el beige es el padding; el trazo turquesa es el border; el espacio punteado exterior es el margin.

`box-sizing`: content-box vs border-box

La propiedad box-sizing decide qué incluye el width y el height que declaras.

content-box (valor por defecto) — width y height miden solo el contenido. El padding y el border se suman por fuera, agrandando el tamaño final.
border-box — width y height miden el conjunto de contenido + padding + border. El tamaño que declaras es el tamaño real renderizado.

Mira dos cajas con width: 200px y padding: 20px, una con cada modelo:

.content-box { box-sizing: content-box; } /* ancho real: 200 + 40 = 240px */
.border-box { box-sizing: border-box; } /* ancho real: 200px */

content-box → mide 246px en total

border-box → mide 200px en total

Por eso es práctica recomendada activar border-box de forma global, heredándolo para no romper estilos de terceros:

:root { box-sizing: border-box; }

*, ::before, ::after { box-sizing: inherit; }

Warning

Evita los números mágicos: valores arbitrarios (margin-top: 37px) que “cuadran” un diseño por casualidad. Haz que el contenido se adapte al contenedor, no al revés.

Alturas: el flujo normal manda

La altura de un contenedor es orgánica por defecto: la define su contenido, no el contenedor. Esto tiene dos consecuencias prácticas:

Definir height en porcentaje rara vez funciona, porque se refiere a la altura del padre, que a su vez depende de su contenido.
Para que un height: 100% funcione, el padre necesita una altura explícita en unidades absolutas.

En lugar de fijar alturas, prefiere restringir el rango con min-height y max-height, dejando que el contenido fluya:

.panel { min-height: 6em; max-height: 12em; }

`overflow`: qué hacer cuando el contenido se desborda

Cuando el contenido excede el tamaño de su caja, overflow define el comportamiento:

Valor	Comportamiento
`visible` (por defecto)	El contenido se desborda y permanece visible.
`hidden`	El contenido que se sale se recorta.
`scroll`	Siempre añade barras de desplazamiento.
`auto`	Añade barras solo si hace falta.

.recorte { overflow: auto; max-height: 5em; }

Este contenedor tiene overflow: auto y una altura máxima.

Cuando el contenido supera esa altura, aparece una barra de desplazamiento.

Línea adicional para forzar el desbordamiento.

Y una más para asegurar el scroll.

Puedes controlar cada eje por separado con overflow-x y overflow-y, aunque mezclar valores distintos suele dar resultados poco predecibles.

Centrado vertical

Centrar verticalmente fue durante años un dolor de cabeza en CSS. La propiedad vertical-align no sirve para esto: solo aplica a elementos inline y a celdas de tabla. Hoy tenemos varias soluciones según el escenario:

¿Puedes usar la altura natural? Aplica un padding igual arriba y abajo.
¿Necesitas altura fija? Usa display: table-cell con vertical-align: middle.
El caso general: usa flexbox.
¿Una sola línea de texto? Usa line-height igual a la altura del contenedor.

La solución moderna por excelencia es flexbox, que centra en ambos ejes con tres declaraciones:

.centro {
 display: flex;
 align-items: center; /* eje vertical */
 justify-content: center; /* eje horizontal */
 min-height: 8em;
}

Centrado en ambos ejes

Márgenes negativos

A diferencia de padding y border, los márgenes admiten valores negativos, lo que te permite tirar de un elemento hacia afuera de su posición natural o solaparlo con su vecino.

.solapado { margin-top: -1.5em; }

Bloque base

Bloque con margin-top negativo que se solapa

Colapso de márgenes (margin collapsing)

Cuando dos márgenes verticales se encuentran, no se suman: se colapsan, quedando solo el de mayor valor. Si un párrafo tiene margin-bottom: 30px y el siguiente margin-top: 20px, la separación entre ambos será de 30px, no 50px.

Info

El colapso de márgenes solo ocurre con márgenes verticales (arriba y abajo). Los márgenes horizontales (izquierda y derecha) nunca colapsan.

Hay varias formas de impedir el colapso cuando no lo deseas:

Aplicar overflow: auto (o cualquier valor distinto de visible) al contenedor.
Añadir un border o un padding entre los dos márgenes.
Usar un contenedor flotado, inline-block o con posición absoluta/fija.
Usar flexbox o grid: los márgenes entre ítems del layout no colapsan.
Los elementos con display: table-cell no tienen margen, así que no colapsan.

Conclusión

El modelo de caja deja de ser un misterio cuando interiorizas que box-sizing controla la aritmética del tamaño, que la altura es orgánica por naturaleza y que los márgenes verticales colapsan. Activar border-box de forma global y apoyarte en flexbox para el centrado elimina la mayoría de los problemas clásicos de maquetación.

Note

🚀 La siguiente entrega cubre los sistemas de layout: float, flexbox y CSS Grid, las herramientas con las que componemos la estructura completa de una página.

RxJs: Operadores de transformación

Dacadev — Fri, 05 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una aplicación combina eventos de UI, peticiones HTTP y procesos asíncronos, el flujo deja de ser una secuencia plana de valores y empieza a producir observables internos. Los operadores de transformación RxJS resuelven ese punto crítico: convierten un observable de observables en un flujo consumible, controlando concurrencia, cancelación, orden y exclusión de trabajo duplicado.

Note

Este artículo forma parte de la serie RxJs. Venimos de analizar Operadores de tiempo y aquí abordaremos mergeAll, mergeMap, switchMap, concatMap y exhaustMap; después continuaremos con Operadores no tan comunes.

La documentación oficial de RxJS describe estos operadores como herramientas para trabajar con higher-order observables: observables cuyas emisiones son, a su vez, otros observables. En términos prácticos, aparecen cada vez que un evento dispara trabajo asíncrono: una búsqueda, un guardado, una carga incremental o una operación remota.

La diferencia entre estos operadores no es cosmética. Elegir uno u otro define cómo se comporta el sistema ante emisiones rápidas: si ejecuta todo en paralelo, cancela lo anterior, serializa las tareas o ignora nuevos eventos mientras una operación sigue activa.

`mergeAll`: aplanar observables internos con concurrencia

mergeAll trabaja sobre un observable que emite observables. Se suscribe a cada observable interno y reemite sus valores en el flujo resultante. El resultado se completa únicamente cuando el observable exterior se completa y todos los observables internos activos también han completado.

Este operador es útil cuando ya tienes construidos los observables internos y solo necesitas aplanarlos. Por ejemplo, una capa previa puede generar varias operaciones independientes: guardar un borrador, registrar auditoría y sincronizar métricas. Si ninguna depende del resultado de la otra, mergeAll permite ejecutarlas con concurrencia.

En el diagrama, cada emisión del flujo superior representa un observable interno. mergeAll mezcla sus emisiones conforme llegan, sin preservar necesariamente el orden original entre observables.

import { from, mapTo, mergeAll, timer } from 'rxjs';

const saveDraft$ = timer(300).pipe(mapTo('draft saved'));
const sendAudit$ = timer(100).pipe(mapTo('audit sent'));
const syncMetrics$ = timer(200).pipe(mapTo('metrics synced'));

from([saveDraft$, sendAudit$, syncMetrics$])
 .pipe(mergeAll())
 .subscribe(console.log);

// audit sent
// metrics synced
// draft saved

El ejemplo muestra un comportamiento clave: el orden de salida depende del tiempo de finalización de cada observable interno. Si necesitas preservar orden estricto, mergeAll no es la herramienta adecuada; concatMap encaja mejor en ese caso.

Tip

Usa mergeAll cuando ya tienes observables internos construidos y deseas aplanarlos. Si primero necesitas transformar cada valor del flujo exterior en un observable, normalmente mergeMap expresa mejor la intención.

`mergeMap`: transformar y mezclar con concurrencia completa

mergeMap combina dos pasos: transforma cada emisión del observable fuente en un observable interno y luego mezcla las emisiones de todos esos observables. Conceptualmente equivale a aplicar map para crear observables y después mergeAll para aplanarlos.

Su semántica favorece la concurrencia. Cada emisión entrante dispara una nueva suscripción interna, y las suscripciones anteriores permanecen activas hasta completar. Esto lo hace adecuado para operaciones independientes donde cancelar trabajo previo sería incorrecto, como escrituras, telemetría, cargas paralelas o procesamiento de elementos sin dependencia de orden.

import { from, mergeMap } from 'rxjs';
import { ajax } from 'rxjs/ajax';

interface User {
 id: number;
 name: string;
}

const userIds = [101, 102, 103, 104];

from(userIds)
 .pipe(
 mergeMap(
 (id) => ajax.getJSON<User>(`/api/users/${id}`),
 4 // límite de concurrencia
 )
 )
 .subscribe((user) => {
 console.log('Usuario cargado:', user.name);
 });

Aunque mergeMap suele asociarse con “concurrencia completa”, RxJS permite limitar esa concurrencia con el segundo argumento. Este detalle es importante cuando el flujo fuente puede emitir muchos valores y cada valor dispara trabajo costoso, como peticiones HTTP o acceso a recursos externos.

Warning

mergeMap no cancela observables internos anteriores. Si el flujo fuente emite más rápido de lo que los internos completan, puedes acumular trabajo concurrente y aumentar presión sobre red, memoria o servicios remotos.

`switchMap`: cancelar lo anterior y conservar lo más reciente

switchMap también transforma cada emisión en un observable interno, pero mantiene activa solo la suscripción más reciente. Cuando llega una nueva emisión desde el observable fuente, cancela la suscripción interna anterior y se cambia al nuevo observable.

Esta semántica es ideal para escenarios donde el resultado anterior pierde relevancia al aparecer una entrada más nueva. El caso clásico es un typeahead o autocomplete: si el usuario escribe rea y luego react, la respuesta de rea ya no debe actualizar la UI aunque llegue después.

import {
 debounceTime,
 distinctUntilChanged,
 fromEvent,
 map,
 of,
 switchMap,
} from 'rxjs';
import { ajax } from 'rxjs/ajax';

interface SearchResult {
 id: string;
 title: string;
}

const input = document.querySelector<HTMLInputElement>('#search')!;

fromEvent<InputEvent>(input, 'input')
 .pipe(
 map((event) => (event.target as HTMLInputElement).value.trim()),
 debounceTime(300),
 distinctUntilChanged(),
 switchMap((term) =>
 term.length === 0
 ? of([])
 : ajax.getJSON<SearchResult[]>(`/api/search?q=${encodeURIComponent(term)}`)
 )
 )
 .subscribe((results) => {
 console.log('Resultados vigentes:', results);
 });

El valor operativo de switchMap está en la cancelación. En Angular, por ejemplo, cancelar la suscripción a una petición HTTP puede abortar la solicitud subyacente; en otros contextos, al menos evita que respuestas obsoletas lleguen al consumidor final.

Info

Elige switchMap cuando el sistema debe representar el estado más reciente: búsquedas, filtros dinámicos, navegación dependiente de parámetros o recarga de datos por selección activa.

`concatMap`: preservar orden y ejecutar de forma secuencial

concatMap transforma cada emisión en un observable interno, pero no se suscribe al siguiente hasta que el observable interno actual completa. En lugar de mezclar resultados, crea una cola: procesa una tarea, espera su finalización y continúa con la siguiente.

Este comportamiento es crucial cuando el orden importa o cuando el backend espera operaciones serializadas. Casos típicos incluyen guardar cambios en secuencia, ejecutar comandos de dominio, procesar pasos de onboarding o enviar eventos que deben respetar causalidad.

import { concatMap, from } from 'rxjs';
import { ajax } from 'rxjs/ajax';

interface OrderCommand {
 orderId: string;
 status: 'validated' | 'charged' | 'confirmed';
}

const commands: OrderCommand[] = [
 { orderId: 'A-100', status: 'validated' },
 { orderId: 'A-100', status: 'charged' },
 { orderId: 'A-100', status: 'confirmed' },
];

from(commands)
 .pipe(
 concatMap((command) =>
 ajax.post('/api/orders/commands', command, {
 'Content-Type': 'application/json',
 })
 )
 )
 .subscribe(() => {
 console.log('Comando procesado en orden');
 });

La principal ventaja de concatMap es la predictibilidad. La desventaja es la latencia acumulada: si cada operación tarda 500 ms y tienes diez elementos, el flujo tardará al menos cinco segundos en procesar la cola completa.

Warning

concatMap puede acumular una cola grande si la fuente emite más rápido de lo que completan los observables internos. Evalúa backpressure, límites de entrada o estrategias de descarte si el volumen no está controlado.

`exhaustMap`: ignorar nuevas emisiones mientras hay trabajo activo

exhaustMap transforma una emisión en un observable interno y, mientras ese observable está activo, ignora todas las emisiones posteriores del observable fuente. Cuando el observable interno completa, el operador queda listo para aceptar una nueva emisión.

Este patrón es útil cuando una operación no debe ejecutarse dos veces en paralelo. Formularios de login, botones de pago, acciones de envío y procesos idempotentes costosos suelen beneficiarse de esta semántica: el primer evento inicia el trabajo y los siguientes clics se descartan hasta terminar.

import { exhaustMap, fromEvent } from 'rxjs';
import { ajax } from 'rxjs/ajax';

interface PaymentResult {
 transactionId: string;
}

const payButton = document.querySelector<HTMLButtonElement>('#pay')!;
const payload = { orderId: 'A-100' };

fromEvent(payButton, 'click')
 .pipe(
 exhaustMap(() =>
 ajax.post<PaymentResult>('/api/payments', payload, {
 'Content-Type': 'application/json',
 })
 )
 )
 .subscribe((response) => {
 console.log('Pago procesado:', response.response.transactionId);
 });

A diferencia de switchMap, exhaustMap no cancela el trabajo activo. A diferencia de mergeMap, tampoco crea trabajo adicional. Su contrato es deliberadamente estricto: “ignorar mientras esté ocupado”.

Cuándo elegir cada operador de transformación RxJS

La elección correcta depende de la política de concurrencia que necesita el sistema, no solo de la forma del código.

Usa mergeAll cuando recibes observables internos ya creados y quieres mezclarlos.
Usa mergeMap cuando cada emisión dispara trabajo independiente y aceptas concurrencia.
Usa switchMap cuando solo importa el resultado más reciente y conviene cancelar lo anterior.
Usa concatMap cuando necesitas orden, serialización o consistencia secuencial.
Usa exhaustMap cuando una operación activa debe bloquear nuevas emisiones hasta completar.

Una regla práctica es observar qué debería ocurrir si llegan tres emisiones rápidas. Si las tres deben ejecutarse, mergeMap. Si solo la última importa, switchMap. Si las tres deben ejecutarse en orden, concatMap. Si solo la primera debe ejecutarse y las demás deben ignorarse mientras está activa, exhaustMap.

Conclusión

Los operadores de transformación RxJS definen cómo se conectan eventos de alto nivel con trabajo asíncrono real. mergeAll, mergeMap, switchMap, concatMap y exhaustMap no son variantes intercambiables; cada uno codifica una política distinta de concurrencia, cancelación y orden.

Al diseñar flujos reactivos en TypeScript, conviene elegir el operador a partir del contrato del dominio. Esa decisión reduce condiciones de carrera, evita respuestas obsoletas, controla presión sobre recursos externos y hace que la intención del flujo sea explícita para el equipo.