Typescripts · DacaCode

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
en compilación]
 B -- ok --> D[JS + sourceMap]
 D --> E[Runtime]
 E -- error --> F[Stack trace sobre TS
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.

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.

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<K, V>"] --> A["MyMap<string, number>"]
 G --> B["MyMap<string, boolean>"]
 G --> C["MyMap<number, Hero>"]

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.

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,
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.

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.

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
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.

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.

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.

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.

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.

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.

RxJs: Operadores de tiempo

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

Tabla de Contenido

Cuando un flujo de eventos del navegador emite con demasiada frecuencia, la lógica de aplicación puede terminar procesando ruido en lugar de señales útiles. Los operadores de tiempo RxJS permiten controlar esa presión temporal en escenarios como búsquedas con autocompletado, eventos de scroll, clics repetidos, métricas periódicas o capturas de estado. En este artículo analizaremos debounceTime, throttleTime, sampleTime, sample y auditTime con ejemplos en TypeScript y diagramas de canicas.

Note

Este artículo forma parte de la serie RxJs. Venimos de Operadores básicos y continuaremos con Operadores de transformación. Aquí abordaremos cómo regular emisiones en el tiempo sin acoplar la lógica de negocio a temporizadores manuales.

Por qué usar operadores de tiempo RxJS

En RxJS, un observable puede emitir valores con una cadencia muy superior a la capacidad real de procesamiento de la interfaz o del backend. Un keyup puede dispararse en cada tecla, un mousemove puede emitir decenas de veces por segundo y un botón puede recibir clics duplicados antes de que termine una operación asíncrona. Sin control temporal, el sistema incrementa latencia, consumo de CPU y llamadas innecesarias.

Los operadores de tiempo resuelven este problema dentro del pipeline reactivo. En lugar de mezclar setTimeout, flags mutables y cancelaciones manuales, expresamos la política de emisión con operadores declarativos. Esto mantiene la suscripción enfocada en consumir valores ya estabilizados, muestreados o limitados.

Info

En ReactiveX, estos operadores suelen representarse con diagramas de canicas porque el comportamiento depende tanto del valor como del instante de emisión. Los diagramas del artículo provienen de la nota original y se conservan como referencia visual.

`debounceTime`: esperar silencio antes de emitir

debounceTime emite el último valor del observable fuente solo cuando transcurre un intervalo sin nuevas emisiones. Si llega otro valor antes de que venza el temporizador, el valor anterior se descarta y el conteo vuelve a empezar. Esta semántica es especialmente útil para entradas de texto, filtros de búsqueda y eventos donde interesa la intención final del usuario, no cada evento intermedio.

Consideremos un flujo de clics. La suscripción recibirá un evento únicamente si pasan tres segundos sin otro clic adicional:

import { fromEvent } from 'rxjs';
import { debounceTime } from 'rxjs/operators';

const click$ = fromEvent<PointerEvent>(document, 'click');

click$
 .pipe(debounceTime(3000))
 .subscribe(console.log);

En formularios, debounceTime suele combinarse con distinctUntilChanged para evitar trabajo duplicado cuando el valor estabilizado no cambió realmente. La nota original usa pluck('target', 'value'); funciona como referencia histórica, pero pluck está deprecado en RxJS 7. La alternativa moderna es map.

import { fromEvent } from 'rxjs';
import { debounceTime, distinctUntilChanged, map } from 'rxjs/operators';

const input = document.createElement('input');
document.body.appendChild(input);

const input$ = fromEvent<KeyboardEvent>(input, 'keyup');

input$
 .pipe(
 debounceTime(1500),
 map((event) => (event.target as HTMLInputElement).value),
 distinctUntilChanged()
 )
 .subscribe(console.log);

Warning

pluck aparece en muchos ejemplos clásicos de RxJS, pero está deprecado. Para código nuevo, usa map y extrae explícitamente la propiedad requerida; el resultado es más tipado y más claro para TypeScript.

`throttleTime`: limitar la frecuencia de emisión

throttleTime permite emitir un valor y luego ignorar nuevas emisiones durante una ventana temporal. Por defecto, emite el primer valor de cada ventana y descarta los valores posteriores hasta que el intervalo termina. Es una estrategia útil cuando necesitas una respuesta inmediata, pero quieres proteger el sistema contra ráfagas de eventos.

El siguiente ejemplo procesa como máximo un valor de teclado cada 1500 milisegundos:

import { fromEvent } from 'rxjs';
import { distinctUntilChanged, map, throttleTime } from 'rxjs/operators';

const input = document.createElement('input');
document.body.appendChild(input);

const input$ = fromEvent<KeyboardEvent>(input, 'keyup');

input$
 .pipe(
 throttleTime(1500),
 map((event) => (event.target as HTMLInputElement).value),
 distinctUntilChanged()
 )
 .subscribe(console.log);

Configuración `leading` y `trailing`

La configuración avanzada de throttleTime permite decidir si se emite el valor inicial de la ventana (leading) y/o el último valor capturado durante esa ventana (trailing). Esta configuración es importante cuando necesitas respuesta inmediata y, además, preservar el estado final de una ráfaga.

import { asyncScheduler, fromEvent } from 'rxjs';
import { distinctUntilChanged, map, throttleTime } from 'rxjs/operators';

const input = document.createElement('input');
document.body.appendChild(input);

const input$ = fromEvent<KeyboardEvent>(input, 'keyup');

input$
 .pipe(
 throttleTime(1500, asyncScheduler, {
 leading: true,
 trailing: true,
 }),
 map((event) => (event.target as HTMLInputElement).value),
 distinctUntilChanged()
 )
 .subscribe(console.log);

Con leading: true, la primera emisión sale de inmediato. Con trailing: true, el último valor observado durante la ventana se emite al cerrar el intervalo. Esta combinación es adecuada para interacciones donde importa tanto la reacción inicial como el estado final.

Tip

Usa debounceTime cuando solo importa el valor estabilizado. Usa throttleTime cuando necesitas una primera respuesta rápida y una frecuencia máxima controlada.

`sampleTime`: tomar snapshots periódicos del último valor

sampleTime toma una muestra del último valor emitido por la fuente cada cierto intervalo. A diferencia de throttleTime, el reloj no se inicia por una emisión del observable fuente; el operador usa un intervalo periódico. Si no hubo valores nuevos desde el último tick, no emite nada.

El siguiente pipeline captura la última posición de clic cada dos segundos, siempre que haya ocurrido al menos un clic durante ese periodo:

import { fromEvent } from 'rxjs';
import { map, sampleTime } from 'rxjs/operators';

const click$ = fromEvent<PointerEvent>(document, 'click');

click$
 .pipe(
 sampleTime(2000),
 map(({ x, y }) => ({ x, y }))
 )
 .subscribe(console.log);

Esta estrategia encaja bien en telemetría, dashboards o cálculos de posición donde no necesitas procesar cada evento, sino observar el estado más reciente a una cadencia fija. También reduce el acoplamiento entre la frecuencia de entrada y la frecuencia de procesamiento.

`sample`: emitir cuando otro observable lo indique

sample generaliza la idea de muestreo: en lugar de usar un intervalo fijo, recibe un observable notificador. Cada vez que el notificador emite, sample publica el último valor conocido de la fuente, si existe uno disponible desde la muestra anterior.

En este ejemplo, interval$ genera valores cada 500 milisegundos, pero solo se emite el último valor cuando ocurre un clic:

import { fromEvent, interval } from 'rxjs';
import { sample } from 'rxjs/operators';

const interval$ = interval(500);
const click$ = fromEvent<PointerEvent>(document, 'click');

interval$
 .pipe(sample(click$))
 .subscribe(console.log);

sample es útil cuando un evento externo define el momento de lectura. Por ejemplo, puedes mantener un stream de estado interno y emitir snapshots solo cuando el usuario confirma una acción, cuando llega una señal de sincronización o cuando otro subsistema solicita una captura.

`auditTime`: emitir el último valor al cerrar una ventana

auditTime inicia una ventana temporal cuando recibe una emisión de la fuente. Durante esa ventana ignora las emisiones intermedias, pero conserva la última. Al finalizar el intervalo, emite ese último valor capturado.

Su comportamiento resulta útil cuando el primer valor de una ráfaga no es tan relevante como el valor final dentro de una ventana de procesamiento. El siguiente ejemplo registra cada clic con tap, transforma la posición y luego deja pasar el último valor cada dos segundos desde el inicio de cada ventana:

import { fromEvent } from 'rxjs';
import { auditTime, map, tap } from 'rxjs/operators';

const click$ = fromEvent<PointerEvent>(document, 'click');

click$
 .pipe(
 map(({ x, y }) => ({ x, y })),
 tap((value) => console.log('tap', value)),
 auditTime(2000)
 )
 .subscribe(console.log);

La diferencia práctica frente a debounceTime es que auditTime no espera silencio global para emitir. Si hay una ráfaga continua, seguirá emitiendo el último valor de cada ventana auditada. Frente a throttleTime, auditTime se enfoca en el valor final de la ventana, no en el inicial.

Info

auditTime es una buena opción para flujos de alta frecuencia donde necesitas snapshots finales por ventana: movimientos de puntero, scroll, reflujo visual o mediciones periódicas derivadas de eventos continuos.

Comparación rápida de operadores de tiempo

Operador	Cuándo emite	Caso típico
`debounceTime`	Cuando pasa un intervalo sin nuevas emisiones	Búsqueda después de que el usuario deja de escribir
`throttleTime`	Al inicio de una ventana; opcionalmente también al final	Clics, scroll o resize con respuesta inmediata
`sampleTime`	En ticks periódicos, si hay un valor nuevo	Telemetría o snapshots a cadencia fija
`sample`	Cuando emite otro observable notificador	Capturar estado bajo demanda
`auditTime`	Al final de una ventana iniciada por la fuente	Emitir el último valor de una ráfaga temporal

Conclusión

Los operadores de tiempo RxJS permiten diseñar pipelines reactivos con políticas temporales explícitas. debounceTime reduce ruido esperando estabilidad, throttleTime limita frecuencia con respuesta inicial, sampleTime toma snapshots periódicos, sample delega el momento de lectura a otro observable y auditTime conserva el último valor de una ventana.

Elegir correctamente entre estos operadores evita temporizadores manuales, reduce estado mutable y mantiene el control de emisiones cerca del flujo que lo necesita. En el siguiente artículo de la serie abordaremos operadores de transformación para modificar la forma de los valores que viajan por el stream.

RxJs: Operadores básicos

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

Tabla de Contenido

En una aplicación reactiva, el problema rara vez consiste solo en recibir eventos; el reto aparece al transformar, filtrar y acumular emisiones sin acoplar la lógica de negocio a cada suscripción. Los operadores rxjs resuelven ese punto al permitir que un Observable exponga un flujo derivado, más específico y más seguro para quien lo consume.

Note

Este artículo forma parte de la serie RxJs. Venimos de analizar Funciones para crear Observables y aquí abordaremos pipe, map, pluck, mapTo, filter, encadenamiento, tap, reduce y scan. El siguiente paso será estudiar Operadores de tiempo.

Qué son los operadores rxjs y cómo funciona `pipe`

Un operador es una función que recibe las emisiones de un Observable y devuelve otro Observable con un comportamiento derivado. Ese comportamiento puede transformar valores, filtrar emisiones, ejecutar efectos secundarios controlados o acumular estado a lo largo del stream.

En RxJS, los operadores se aplican con el método pipe. Esta API permite declarar una cadena de procesamiento explícita, donde cada operador recibe la salida del anterior y entrega su resultado al siguiente. La documentación oficial de RxJS describe este patrón como la base para componer flujos asincrónicos de manera declarativa.

import { range, map } from 'rxjs';

range(1, 5)
 .pipe(
 map((value) => value * 10)
 )
 .subscribe(console.log);

La suscripción no debería cargar con toda la lógica de transformación. En un diseño mantenible, subscribe se reserva para consumir el resultado final, mientras que pipe documenta la estrategia de procesamiento del flujo.

Tip

Mantén la lógica de transformación dentro de pipe. Esto reduce acoplamiento, facilita pruebas unitarias sobre operadores y evita suscripciones con demasiada responsabilidad.

`map`: transformar emisiones con `map filter rxjs`

El operador map proyecta cada emisión del Observable original hacia un nuevo valor. Es equivalente al concepto de proyección funcional: por cada entrada existe una salida, sin modificar el origen y sin alterar la cantidad de emisiones.

En el diagrama de canicas, cada valor emitido pasa por una función de transformación y continúa en el stream resultante con una nueva representación. Esto permite convertir modelos, normalizar datos o derivar valores calculados antes de que lleguen a la suscripción.

import { range, map } from 'rxjs';

const source$ = range(1, 5);

const multiplied$ = source$.pipe(
 map<number, number>((value) => value * 10)
);

source$.subscribe((value) => console.log('source', value));
multiplied$.subscribe((value) => console.log('map', value));

También puedes escribirlo de forma compacta cuando no necesitas conservar una referencia al Observable intermedio:

import { range, map } from 'rxjs';

range(1, 5)
 .pipe(
 map<number, number>((value) => value * 10)
 )
 .subscribe(console.log);

El resultado conserva el orden de las emisiones y aplica la función a cada valor individual.

map es una pieza central en pipelines donde necesitas convertir eventos del DOM, respuestas HTTP o estructuras de dominio en datos listos para la capa que los consume.

`pluck`: extraer propiedades anidadas

El operador pluck extrae propiedades de objetos emitidos por un Observable. En notas y proyectos con RxJS más antiguos aparece con frecuencia para leer rutas como target.baseURI dentro de un evento del DOM.

Un ejemplo clásico consiste en escuchar eventos keyup y extraer una propiedad anidada del objeto KeyboardEvent.

import { fromEvent } from 'rxjs';
import { pluck } from 'rxjs/operators';

const keyup$ = fromEvent<KeyboardEvent>(document, 'keyup');

const baseUri$ = keyup$.pipe(
 pluck('target', 'baseURI')
);

keyup$.subscribe(console.log);
baseUri$.subscribe((value) => console.log('pluck', value));

Al presionar una tecla, el Observable original emite el evento completo, mientras que el stream derivado emite solo la propiedad seleccionada.

Warning

pluck está deprecado en versiones modernas de RxJS. Prefiere map con acceso explícito a propiedades, porque ofrece mejor tipado, autocompletado y refactorización segura.

La alternativa recomendada usa map:

import { fromEvent, map } from 'rxjs';

const keyup$ = fromEvent<KeyboardEvent>(document, 'keyup');

const baseUri$ = keyup$.pipe(
 map((event) => event.target instanceof Element ? event.target.baseURI : '')
);

baseUri$.subscribe((value) => console.log('baseURI', value));

`mapTo`: reemplazar cada emisión por un valor constante

El operador mapTo transforma cualquier entrada en un valor constante. Es útil cuando el contenido de la emisión original no importa y solo necesitas representar una señal semántica, por ejemplo: “hubo interacción”, “se presionó una tecla” o “se completó un paso”.

import { fromEvent, mapTo } from 'rxjs';

const keyup$ = fromEvent<KeyboardEvent>(document, 'keyup');

const keyPressed$ = keyup$.pipe(
 mapTo('Tecla presionada')
);

keyPressed$.subscribe((value) => console.log('mapTo', value));

Cada evento keyup se reemplaza por la misma cadena.

En código moderno, también puedes usar map(() => valor) para lograr el mismo resultado y mantener consistencia con el resto de tus transformaciones.

`filter`: filtrar emisiones del stream

El operador filter deja pasar únicamente las emisiones que cumplen un predicado. A diferencia de map, este operador sí puede cambiar la cantidad de emisiones que recibe la suscripción, porque descarta los valores que no satisfacen la condición.

El callback de filter recibe el valor emitido y el índice de la emisión. Esto permite aplicar reglas basadas en el contenido del valor o en su posición dentro del stream.

import { range, filter } from 'rxjs';

range(10, 20)
 .pipe(
 filter((value, index) => {
 console.log('index', index);
 return value % 2 === 1;
 })
 )
 .subscribe(console.log);

En este caso, solo pasan los números impares.

filter también es útil con objetos de dominio. El siguiente ejemplo convierte un arreglo en un Observable y deja pasar únicamente los personajes de tipo heroe.

import { from, filter } from 'rxjs';

interface Personaje {
 tipo: 'heroe' | 'villano';
 nombre: string;
}

const personajes: Personaje[] = [
 { tipo: 'heroe', nombre: 'Batman' },
 { tipo: 'heroe', nombre: 'Robin' },
 { tipo: 'villano', nombre: 'Joker' }
];

from(personajes)
 .pipe(
 filter((personaje) => personaje.tipo === 'heroe')
 )
 .subscribe((personaje) => console.log('filter', personaje));

El stream resultante contiene solo los objetos que cumplen el predicado.

Info

filter no transforma el valor; controla si una emisión continúa o se descarta. Si necesitas modificar el valor después del filtrado, encadena un map a continuación.

Encadenamiento con el operador pipe rxjs

El operador pipe rxjs permite componer varios operadores en una secuencia legible. Cada paso debería tener una responsabilidad clara: extraer un dato, filtrar una condición, transformar un modelo o ejecutar un efecto secundario controlado.

import { fromEvent, filter, map } from 'rxjs';

const enterKey$ = fromEvent<KeyboardEvent>(document, 'keyup').pipe(
 map((event) => event.code),
 filter((keyCode) => keyCode === 'Enter')
);

enterKey$.subscribe((keyCode) => console.log('chain', keyCode));

Aquí el primer operador transforma KeyboardEvent en event.code, y el segundo operador deja pasar únicamente la tecla Enter. La suscripción recibe un stream ya procesado, sin conocer el detalle del evento original del DOM.

Esta composición es especialmente importante cuando el flujo crece. En lugar de acumular lógica imperativa dentro de callbacks, puedes expresar el pipeline de datos como una serie de transformaciones pequeñas y verificables.

`tap`: efectos secundarios sin transformar el flujo

El operador tap ejecuta efectos secundarios sobre las emisiones, pero no modifica el valor que atraviesa el pipeline. Es una herramienta frecuente para depuración, métricas, logging o integración con observabilidad, siempre que no se use para alterar estado crítico de forma opaca.

import { range, map, tap } from 'rxjs';

const numbers$ = range(1, 5);

numbers$
 .pipe(
 tap((value) => console.log('tap-antes', value)),
 map((value) => value * 10),
 tap({
 next: (value) => console.log('tap-despues', value),
 complete: () => console.log('se terminó todo')
 })
 )
 .subscribe((value) => console.log('subs', value));

tap acepta un callback para next o un objeto con handlers como next, error y complete. En ambos casos, el valor que continúa hacia el siguiente operador permanece intacto.

Warning

Evita usar tap como sustituto de map o filter. Si un paso cambia el valor del stream, debe expresarse con un operador de transformación explícito.

`reduce`: acumular y emitir al completar

El operador reduce aplica una función acumuladora sobre las emisiones y entrega un único resultado cuando el Observable completa. Su comportamiento es apropiado para streams finitos, como arreglos, rangos o secuencias delimitadas con operadores como take.

import { interval, reduce, take, tap } from 'rxjs';

const totalReducer = (accumulator: number, current: number) => {
 return accumulator + current;
};

interval(500)
 .pipe(
 take(6),
 tap(console.log),
 reduce(totalReducer, 5)
 )
 .subscribe({
 next: (value) => console.log('next', value),
 complete: () => console.log('complete')
 });

El segundo argumento de reduce define el valor inicial del acumulador. En el ejemplo, el acumulador inicia en 5, procesa seis emisiones del interval y emite el total solo cuando take(6) completa el flujo.

Warning

reduce necesita que el Observable complete para emitir el resultado. En streams infinitos o de larga vida, como eventos del DOM sin delimitador, no recibirás salida si no aplicas un operador que cierre la secuencia.

`scan`: acumular y emitir cada estado intermedio

El operador scan también aplica una función acumuladora, pero emite cada estado intermedio del acumulador. Esta diferencia lo convierte en una pieza clave para modelar estado reactivo: contadores, historial de acciones, progreso incremental o snapshots derivados de eventos.

Comparar reduce y scan sobre la misma secuencia deja clara la diferencia operativa.

import { from, reduce, scan } from 'rxjs';

const numbers = [1, 2, 3, 4, 5];

const totalAccumulator = (accumulator: number, current: number) => {
 return accumulator + current;
};

from(numbers)
 .pipe(
 reduce(totalAccumulator, 0)
 )
 .subscribe((value) => console.log('reduce', value));

from(numbers)
 .pipe(
 scan(totalAccumulator, 0)
 )
 .subscribe((value) => console.log('scan', value));

reduce emite solo el total final. scan emite 1, 3, 6, 10 y 15, porque cada emisión representa el nuevo estado acumulado.

En arquitecturas reactivas, scan suele ser más útil que reduce cuando el consumidor necesita reaccionar a cada transición de estado, no solo al resultado final.

Conclusión

Los operadores básicos de RxJS permiten convertir streams genéricos en flujos especializados y mantenibles. map transforma, filter controla qué continúa, tap observa sin modificar, reduce acumula hasta completar y scan expone cada estado acumulado.

Dominar pipe y estos operadores establece una base sólida para operadores más avanzados. En el siguiente artículo de la serie abordaremos operadores de tiempo, donde la latencia, la frecuencia de emisión y la coordinación temporal pasan a ser parte central del diseño reactivo.

RxJs: Funciones para crear Observables

Dacadev — Sat, 30 May 2026 00:00:00 -0500

Tabla de Contenido

Cuando modelamos interacciones de usuario, temporizadores, colecciones o tareas diferidas, la decisión inicial suele ser cómo crear observables RxJS sin introducir acoplamiento innecesario ni perder claridad sobre la sincronía del flujo. En RxJS, las funciones de creación encapsulan patrones comunes para construir Observables a partir de valores, iterables, eventos del DOM y relojes internos.

Note

Este artículo forma parte de la serie RxJs. Venimos de analizar Observables y aquí abordaremos of, from, fromEvent, range, interval, timer y asyncScheduler. El siguiente paso será estudiar Operadores básicos.

Crear observables RxJS con funciones de creación

Las funciones de creación producen un Observable sin escribir manualmente el constructor new Observable(...). Esto reduce código repetitivo y comunica la intención del stream: emitir valores estáticos, recorrer una colección, escuchar eventos o programar emisiones en el tiempo.

La diferencia más importante está en la naturaleza síncrona o asíncrona del observable resultante. of, from y range pueden emitir inmediatamente durante la suscripción. fromEvent, interval y timer, en cambio, dependen de eventos externos o del paso del tiempo.

Info

Un observable puede ser finito o infinito. of, from, range y timer(2000) completan; fromEvent e interval no completan por sí mismos y requieren cancelar la suscripción o aplicar operadores como take.

`of`: emitir cada argumento como un valor independiente

of crea un observable síncrono a partir de los argumentos que recibe. Cada argumento se convierte en una emisión individual y, al terminar la lista, el stream envía complete.

Esta característica es útil para valores estáticos, pruebas unitarias, mocks de servicios o flujos donde necesitas transformar una secuencia pequeña sin depender de una fuente externa.

import { of } from 'rxjs';

const obs$ = of(1, 'string', true, () => {}, 1.14);

console.log('Inicio del obs$');
obs$.subscribe({
 next: value => console.log('next:', value),
 complete: () => console.log('Completado!'),
});
console.log('Fin del obs$');

Como of es síncrono, todas las emisiones ocurren antes de ejecutar console.log('Fin del obs$'). Esta propiedad es relevante cuando mezclas streams síncronos con lógica de UI o con efectos secundarios que dependen del orden de ejecución.

Tip

Si pasas un arreglo a of, el arreglo completo se emite como un único valor. Si necesitas emitir cada elemento del arreglo, usa from.

`from`: convertir iterables, arreglos y promesas en Observables

from crea un observable a partir de estructuras que ya representan una secuencia o un valor diferido: arreglos, iterables, strings, Promise, entre otros. Con un arreglo, emite cada elemento de manera independiente y luego completa.

import { from } from 'rxjs';

interface Personaje {
 tipo: 'heroe' | 'villano';
 nombre: string;
}

const personajes: Personaje[] = [
 { tipo: 'heroe', nombre: 'Batman' },
 { tipo: 'heroe', nombre: 'Robin' },
 { tipo: 'villano', nombre: 'Joker' },
];

from(personajes).subscribe(personaje => console.log('from', personaje));

La diferencia conceptual entre of(personajes) y from(personajes) es crítica. El primero emite un solo arreglo; el segundo emite tres objetos. Esa elección define el contrato del stream para los operadores posteriores.

`fromEvent`: crear Observables desde eventos del DOM

fromEvent convierte una fuente de eventos en un observable. Recibe el target que expone eventos —por ejemplo document, window o un elemento HTML— y el nombre del evento.

import { fromEvent } from 'rxjs';

const clicks$ = fromEvent<PointerEvent>(document, 'click');
const keyups$ = fromEvent<KeyboardEvent>(document, 'keyup');

clicks$.subscribe(({ x, y }) => console.log('click:', x, y));
keyups$.subscribe(event => console.log('key:', event.key));

Este observable es infinito por defecto. El navegador seguirá emitiendo eventos mientras exista la suscripción, por lo que en componentes con ciclo de vida —por ejemplo Angular, React o Web Components— debes liberar recursos cuando el componente se desmonta.

Identificar el tipo del evento sin usar `any`

En TypeScript conviene evitar fromEvent<any>, porque rompe el contrato de tipos justo en la frontera del sistema. Una forma práctica de identificar el tipo consiste en inspeccionar temporalmente el evento y reemplazar any por la interfaz específica.

import { fromEvent } from 'rxjs';

const source$ = fromEvent<any>(document, 'click');
source$.subscribe(console.log);

Al revisar el objeto emitido en consola o desde el editor, puedes identificar si corresponde a PointerEvent, KeyboardEvent, MouseEvent, InputEvent u otro tipo del DOM. Después reemplazas any por el tipo correcto.

const source$ = fromEvent<PointerEvent>(document, 'click');

source$.subscribe(({ x, y }) => {
 console.log({ x, y });
});

Warning

fromEvent no completa automáticamente. En flujos de UI, combina la suscripción con takeUntil, AbortController, el ciclo de vida del framework o una suscripción compuesta para evitar fugas de memoria.

`range`: generar secuencias numéricas

range crea una secuencia numérica finita. Por defecto emite de forma síncrona, lo que permite usarlo para generar índices, alimentar pruebas o construir flujos deterministas.

`range(count)`: contar desde cero

Cuando recibe un solo argumento, range interpreta ese valor como la cantidad de emisiones. El conteo inicia en 0.

import { range } from 'rxjs';

const src$ = range(5);

console.log('Inicio');
src$.subscribe(value => console.log(value));
console.log('Fin');

El resultado emite 0, 1, 2, 3 y 4. No emite 5, porque el parámetro define la cantidad de valores, no el límite superior inclusivo.

`range(start, count)`: definir inicio y cantidad

Con dos argumentos, el primero define el valor inicial y el segundo la cantidad de emisiones.

import { range } from 'rxjs';

const src$ = range(2, 5);

console.log('Inicio');
src$.subscribe(value => console.log(value));
console.log('Fin');

Este stream emite 2, 3, 4, 5 y 6. El contrato sigue siendo finito y síncrono.

`range(start, count, asyncScheduler)`: diferir la ejecución

asyncScheduler permite programar las emisiones de forma asíncrona. El cambio se observa en el orden de los console.log: primero se ejecuta el código síncrono restante y luego comienzan las emisiones.

import { asyncScheduler, range } from 'rxjs';

const src$ = range(2, 5, asyncScheduler);

console.log('Inicio');
src$.subscribe(value => console.log(value));
console.log('Fin');

Info

asyncScheduler no convierte el trabajo en paralelismo real. Programa tareas asíncronas sobre la cola de ejecución, similar a diferir trabajo con temporizadores.

`interval`: emitir valores periódicamente

interval crea un observable asíncrono e infinito. Recibe un periodo en milisegundos y emite un contador incremental en cada tick.

import { interval } from 'rxjs';

const observer = {
 next: (value: number) => console.log('next', value),
 complete: () => console.log('complete'),
};

const interval$ = interval(1000);

console.log('Inicio');
const subscription = interval$.subscribe(observer);
console.log('Fin');

// En una aplicación real, cancela la suscripción según el ciclo de vida.
// subscription.unsubscribe();

interval no emite complete. Si necesitas un número limitado de emisiones, puedes combinarlo con operadores como take, takeUntil o timeout, que analizaremos en artículos posteriores de la serie.

`timer`: emitir después de un tiempo o iniciar un intervalo diferido

timer también es asíncrono, pero su configuración inicial es distinta. Con un único parámetro numérico, espera esa cantidad de milisegundos, emite 0 y completa.

import { timer } from 'rxjs';

const observer = {
 next: (value: number) => console.log('next', value),
 complete: () => console.log('complete'),
};

const timer$ = timer(2000);

console.log('Inicio');
timer$.subscribe(observer);
console.log('Fin');

Configuraciones especiales de `timer`

timer acepta configuraciones que cubren varios casos operativos:

timer(0) agenda la emisión tan pronto como la cola de tareas lo permita, después del trabajo síncrono actual.
timer(2000, 1000) espera dos segundos y luego se comporta como un intervalo que emite cada segundo.
timer(fecha) permite agendar la primera emisión para un instante específico usando un objeto Date.

import { timer } from 'rxjs';

const timer$ = timer(2000, 1000);

console.log('Inicio');
timer$.subscribe({
 next: value => console.log('next', value),
 complete: () => console.log('complete'),
});
console.log('Fin');

Warning

timer(2000, 1000) deja de ser finito. Después de la primera emisión, continúa como un intervalo y debe cancelarse cuando ya no sea necesario.

`asyncScheduler`: programar trabajo asíncrono

asyncScheduler permite programar tareas usando la infraestructura de schedulers de RxJS. Puede reemplazar casos simples de setTimeout y habilita patrones donde una tarea se reprograma a sí misma.

import { asyncScheduler } from 'rxjs';

const saludar = () => console.log('hola mundo');

console.log('Inicio');
asyncScheduler.schedule(saludar);
console.log('Fin');

También puedes definir un retraso explícito en milisegundos y pasar un único estado a la función programada.

import { asyncScheduler } from 'rxjs';

const saludar = (nombre: string) => console.log(`hola mundo, ${nombre}`);

console.log('Inicio');
asyncScheduler.schedule(saludar, 2000, 'David');
console.log('Fin');

Si necesitas pasar múltiples valores, usa un objeto como estado y desestructúralo en la función. Esto mantiene una firma estable y evita depender de parámetros posicionales adicionales.

Reprogramar una tarea y cancelar la suscripción

Una acción programada puede invocar this.schedule(...) para encadenar la siguiente ejecución. La suscripción resultante permite detener el ciclo.

import { asyncScheduler, SchedulerAction } from 'rxjs';

console.log('Inicio');

const subscription = asyncScheduler.schedule(function (
 this: SchedulerAction<number>,
 state: number
) {
 console.log('state', state);
 this.schedule(state + 1, 1000);
}, 1000, 0);

asyncScheduler.schedule(() => {
 subscription.unsubscribe();
 console.log('Unsubscribe');
}, 6000);

console.log('Fin');

Tip

Usa schedulers cuando necesites controlar explícitamente cuándo ocurre la ejecución. Para transformación de streams, normalmente conviene preferir operadores de RxJS antes que programar tareas manualmente.

Conclusión

Las funciones de creación definen el contrato inicial del stream. of emite argumentos, from expande estructuras iterables o promesas, fromEvent conecta eventos del DOM, range genera secuencias numéricas, interval modela ticks periódicos y timer cubre emisiones diferidas o intervalos con retardo inicial.

Dominar estas diferencias evita errores sutiles de sincronía, fugas de suscripción y contratos ambiguos entre productores y consumidores. Con esta base, el siguiente paso natural es aplicar operadores para transformar, filtrar y combinar emisiones dentro de una arquitectura reactiva mantenible.

RxJs: Observables, Subscriptions y Subjects

Dacadev — Thu, 28 May 2026 00:00:00 -0500

Tabla de Contenido

Cuando un flujo asíncrono combina eventos de usuario, timers, llamadas HTTP y actualizaciones de estado, el problema no es solo recibir datos: es modelar correctamente la vida útil de cada stream. Observables RxJS permite representar esos flujos como secuencias cancelables, componibles y explícitas, con una semántica clara para emisión, error, finalización y limpieza de recursos.

Note

Este artículo forma parte de la serie RxJs. Venimos de Introducción a las extensiones reactivas y aquí analizaremos Observable, Observer, Subscription, unsubscribe, teardown callbacks y Subject. El siguiente paso será Funciones para crear Observables.

Crear observables rxjs con `new Observable`

En RxJS, un Observable representa una fuente de valores que puede emitir cero, uno o muchos elementos a lo largo del tiempo. La forma más directa de construir uno es instanciar Observable y entregar una función de suscripción. Esa función recibe un subscriber, que actúa como canal para emitir valores con next, reportar errores con error o finalizar con complete.

import { Observable } from 'rxjs';

const obs$ = new Observable<string>((subscriber) => {
 subscriber.next('Hola');
 subscriber.next('mundo');

 subscriber.next('Hola');
 subscriber.next('mundo');

 subscriber.complete();

 // Después de complete(), estas emisiones ya no llegan al consumidor.
 subscriber.next('Hola');
 subscriber.next('mundo');
});

La convención del sufijo $ en obs$ no es obligatoria, pero ayuda a comunicar que una variable representa un stream. También es importante declarar el tipo del observable, por ejemplo Observable<string>, porque TypeScript podrá validar el contrato entre la fuente y sus consumidores.

complete() no destruye el objeto observable; cierra la ejecución de esa suscripción específica. A partir de ese punto, el consumidor ya no recibe nuevas emisiones de esa instancia de ejecución.

Tip

Modela el tipo del stream desde el inicio. Un Observable<User> comunica mucho más que un Observable<unknown> y reduce errores en operadores, observers y callbacks de suscripción.

La interfaz `Observer`: `next`, `error` y `complete`

Para consumir un observable usamos subscribe. En versiones modernas de RxJS es preferible pasar un objeto compatible con la interfaz Observer, en lugar de usar la sobrecarga antigua de tres callbacks separados.

import { Observable, Observer } from 'rxjs';

const observer: Observer<string> = {
 next: (valor) => {
 console.log('siguiente', valor);
 },
 error: (err) => {
 console.error('error', err);
 },
 complete: () => {
 console.info('completado');
 },
};

const obs$ = new Observable<string>((subscriber) => {
 subscriber.next('Hola');
 subscriber.next('mundo');
 subscriber.complete();
});

obs$.subscribe(observer);

La interfaz divide explícitamente los tres canales del stream:

next: se ejecuta cada vez que el observable emite un valor.
error: se ejecuta cuando la fuente reporta un fallo terminal.
complete: se ejecuta cuando la fuente finaliza correctamente.

error y complete son señales terminales. Después de cualquiera de ellas, la suscripción queda cerrada y no debe esperarse más trabajo desde esa ejecución.

// Forma antigua: evita esta sobrecarga en código nuevo.
obs$.subscribe(
 (valor) => console.log('Next', valor),
 (err) => console.error('Error', err),
 () => console.info('complete'),
);

// Forma recomendada.
obs$.subscribe(observer);

La documentación oficial de ReactiveX describe este contrato como una secuencia de notificaciones donde el observable invoca al observer. RxJS conserva esa idea y la adapta al ecosistema JavaScript con cancelación explícita mediante suscripciones.

`Subscription` y `unsubscribe`: controlar la vida útil del stream

Cada llamada a subscribe crea una Subscription. Esa suscripción representa la ejecución activa entre un observable y un consumidor. Si el observable administra recursos externos, como un setInterval, un WebSocket o un listener del DOM, la suscripción debe liberar esos recursos cuando el consumidor ya no los necesita.

import { Observable } from 'rxjs';

const intervalos$ = new Observable<number>((subscriber) => {
 let contador = 0;

 const intervalId = setInterval(() => {
 contador++;
 subscriber.next(contador);
 }, 1000);

 return () => {
 clearInterval(intervalId);
 console.log('Intervalo destruido');
 };
});

const subs1 = intervalos$.subscribe((valor) => console.log('subs1:', valor));
const subs2 = intervalos$.subscribe((valor) => console.log('subs2:', valor));
const subs3 = intervalos$.subscribe((valor) => console.log('subs3:', valor));

setTimeout(() => {
 subs1.unsubscribe();
 subs2.unsubscribe();
 subs3.unsubscribe();

 console.log('Completado Timeout');
}, 3000);

En este ejemplo, cada suscripción recibe su propio contador porque el observable es cold: la producción de datos ocurre dentro de la función de suscripción. Tres suscripciones implican tres ejecuciones independientes del setInterval.

La función retornada desde el constructor del observable es el teardown callback. RxJS la ejecuta cuando llamamos unsubscribe() o cuando la suscripción se cierra por una señal terminal. Es el lugar correcto para liberar timers, conexiones, listeners o cualquier recurso asociado a esa ejecución.

Warning

No tratar unsubscribe() como un detalle opcional puede producir fugas de memoria y procesos activos innecesarios. En streams infinitos, como interval, eventos del DOM o sockets, la limpieza explícita es parte del diseño.

Finalizar desde el observable con `complete()`

También es posible cerrar la suscripción desde la propia fuente. Para ello, el observable invoca subscriber.complete(). Cuando esto ocurre, RxJS ejecuta el callback complete del observer y posteriormente ejecuta el teardown registrado.

import { Observable, Observer } from 'rxjs';

const observer: Observer<number> = {
 next: (valor) => {
 console.log('siguiente', valor);
 },
 error: (err) => {
 console.error('error', err);
 },
 complete: () => {
 console.info('completado');
 },
};

const intervalos$ = new Observable<number>((subscriber) => {
 let contador = 0;

 const intervalId = setInterval(() => {
 contador++;
 subscriber.next(contador);
 console.log('obs:', contador);
 }, 1000);

 setTimeout(() => {
 subscriber.complete();
 }, 2500);

 return () => {
 clearInterval(intervalId);
 console.log('Intervalo destruido');
 };
});

const subs1 = intervalos$.subscribe(observer);
const subs2 = intervalos$.subscribe(observer);
const subs3 = intervalos$.subscribe(observer);

setTimeout(() => {
 subs1.unsubscribe();
 subs2.unsubscribe();
 subs3.unsubscribe();

 console.log('Completado Timeout');
}, 6000);

Aunque el setTimeout final intenta cancelar las suscripciones a los seis segundos, cada una ya fue completada por el observable a los 2.5 segundos. La llamada posterior a unsubscribe() no vuelve a emitir complete; simplemente opera sobre una suscripción cerrada.

Esta diferencia es relevante en diseño de APIs. complete() comunica que la fuente terminó correctamente; unsubscribe() comunica que el consumidor ya no quiere recibir valores. Ambas rutas cierran la suscripción, pero expresan intenciones distintas.

Encadenar suscripciones con `.add()`

Cuando varias suscripciones comparten el mismo ciclo de vida, RxJS permite agruparlas con .add(). Esto evita repetir llamadas a unsubscribe() y centraliza la limpieza en una suscripción raíz.

const subs1 = intervalos$.subscribe(observer);
const subs2 = intervalos$.subscribe(observer);
const subs3 = intervalos$.subscribe(observer);

subs1.add(subs2);
subs1.add(subs3);

setTimeout(() => {
 subs1.unsubscribe();

 console.log('Completado Timeout');
}, 6000);

Al cancelar subs1, RxJS cancela también las suscripciones agregadas. Este patrón resulta útil cuando un componente, servicio o caso de uso crea múltiples streams relacionados y necesita destruirlos como una unidad.

Tip

Agrupa suscripciones solo cuando comparten el mismo ownership. Si dos streams tienen ciclos de vida diferentes, unirlos artificialmente puede cancelar trabajo legítimo antes de tiempo.

`Subject RxJS`: multicast y observable caliente

Un Subject combina dos roles: es un observable y también es un observer. Puede recibir valores mediante next, error o complete, y al mismo tiempo permite que múltiples consumidores se suscriban a él.

import { Observable, Subject } from 'rxjs';

const intervalo$ = new Observable<number>((subscriber) => {
 const intervalId = setInterval(() => {
 subscriber.next(Math.random());
 }, 3000);

 return () => clearInterval(intervalId);
});

const subject$ = new Subject<number>();

intervalo$.subscribe(subject$);

const subs1 = subject$.subscribe((num) => console.log('subs1:', num));
const subs2 = subject$.subscribe((num) => console.log('subs2:', num));

La diferencia clave es que Subject habilita multicast: una sola ejecución de la fuente puede distribuir la misma emisión a varios observers. En lugar de crear un setInterval por cada consumidor, el Subject actúa como punto de difusión.

flowchart LR
 A[Observable fuente] --> B[Subject]
 B --> C[Observer 1]
 B --> D[Observer 2]
 B --> E[Observer 3]

En términos de hot y cold observables, un observable es cold cuando la producción de datos ocurre dentro de la suscripción y cada consumidor obtiene su propia ejecución. Un observable es hot cuando la producción de datos existe fuera de una suscripción individual y puede compartirse entre varios consumidores.

El Subject puede convertir un flujo cold en un flujo hot desde la perspectiva de los subscribers conectados al subject. La fuente se ejecuta una vez y el Subject distribuye los valores a múltiples listeners.

Emitir y completar desde un `Subject`

Como Subject también es un observer, puede emitir valores propios. Esto permite introducir valores manualmente en el stream, además de reenviar los valores provenientes de una fuente.

import { Observable, Observer, Subject } from 'rxjs';

const observer: Observer<number> = {
 next: (valor) => {
 console.log('siguiente', valor);
 },
 error: (err) => {
 console.error('error', err);
 },
 complete: () => {
 console.info('completado');
 },
};

const intervalo$ = new Observable<number>((subscriber) => {
 const intervalId = setInterval(() => {
 subscriber.next(Math.random());
 }, 1000);

 return () => {
 clearInterval(intervalId);
 console.log('SetInterval terminado');
 };
});

const subject$ = new Subject<number>();
const baseInterval = intervalo$.subscribe(subject$);

const subs1 = subject$.subscribe(observer);
const subs2 = subject$.subscribe(observer);

setTimeout(() => {
 subject$.next(10);
 subject$.complete();

 baseInterval.unsubscribe();
}, 3500);

El detalle operativo es importante: llamar subject$.complete() cierra el subject y notifica a sus suscriptores, pero no necesariamente cancela la suscripción original que alimentaba al subject. Por eso el ejemplo ejecuta baseInterval.unsubscribe() de forma explícita.

Warning

Un Subject concentra poder y acoplamiento. Úsalo cuando necesitas multicast o una frontera explícita entre productor y consumidores; evita convertirlo en un bus global mutable sin ownership claro.

Conclusión

Los observables rxjs ofrecen un contrato robusto para representar streams asíncronos en TypeScript. Observer define cómo reaccionar ante next, error y complete; Subscription controla la vida útil de la ejecución; unsubscribe() dispara la limpieza mediante el teardown callback; y .add() permite componer ciclos de vida relacionados.

Subject amplía el modelo al habilitar multicast y convertir flujos cold en flujos hot bajo ciertas condiciones. Esta capacidad es útil, pero exige ownership explícito: completar el subject y cancelar la fuente no siempre son la misma operación.

En el siguiente artículo abordaremos las funciones para crear Observables, una forma más declarativa y menos manual de construir streams con RxJS.

RxJs: Introducción a las extensiones reactivas

Dacadev — Tue, 26 May 2026 00:00:00 -0500

Tabla de Contenido

En aplicaciones web modernas, la programación reactiva aparece cuando el sistema debe responder a múltiples fuentes de eventos sin bloquear la interfaz: entradas del usuario, respuestas HTTP, mensajes por WebSocket, timers, estado compartido y cambios que llegan en momentos distintos. Administrar esos flujos solo con callbacks o promesas aisladas suele aumentar el acoplamiento y dificulta expresar transformaciones, cancelaciones y composición de eventos. RxJs aborda este problema con extensiones reactivas basadas en flujos de datos observables.

Note

Este artículo abre la serie RxJs. Analizaremos qué son las extensiones reactivas, qué papel cumple ReactiveX, cómo se relacionan Observables, Subscribers y Operators, cómo leer diagramas de canicas y cómo preparar el proyecto base. No hay artículo anterior; el siguiente artículo es Observables.

Por qué usar extensiones reactivas en aplicaciones web

La expectativa actual de una interfaz es operar en tiempo real o casi real. Un formulario con autocompletado, un dashboard con métricas en vivo o una pantalla de trading no puede depender de recargas completas de página para reflejar cambios. La aplicación necesita reaccionar a eventos concurrentes y mantener la experiencia de usuario estable mientras ejecuta trabajo asíncrono.

Las extensiones reactivas permiten modelar esos eventos como flujos. En lugar de distribuir lógica en múltiples callbacks, representamos la fuente de datos como un Observable y aplicamos operadores para transformar, filtrar, combinar o controlar la frecuencia de sus emisiones.

Esta aproximación es útil cuando una interacción puede producir muchos valores a lo largo del tiempo. Una promesa representa un resultado único; un observable puede representar cero, uno, muchos o infinitos valores, además de errores y finalización.

import { fromEvent } from 'rxjs';
import { debounceTime, map } from 'rxjs/operators';

const searchInput = document.querySelector<HTMLInputElement>('#search')!;

const searchTerm$ = fromEvent<InputEvent>(searchInput, 'input').pipe(
 debounceTime(300),
 map((event) => (event.target as HTMLInputElement).value.trim())
);

searchTerm$.subscribe((term) => {
 console.log('Buscar:', term);
});

El sufijo $ en searchTerm$ es una convención frecuente para indicar que la variable representa un flujo observable. No es obligatorio, pero mejora la legibilidad cuando conviven valores normales y streams.

Tip

Usa RxJs cuando necesites componer eventos en el tiempo: entradas de usuario, sockets, polling, estado reactivo, cancelaciones, reintentos y coordinación entre múltiples fuentes asíncronas.

Cuándo usar programación reactiva con RxJs

RxJs aporta más valor cuando el problema se expresa naturalmente como una secuencia de emisiones. No todos los casos asíncronos requieren un Observable; una petición HTTP aislada puede resolverse con Promise sin introducir más abstracción. El punto fuerte de RxJs aparece cuando necesitas componer varias señales y mantener control explícito sobre su ciclo de vida.

Casos comunes de uso:

Eventos de interfaz de usuario: clicks, movimientos del mouse, inputs, scroll o drag and drop.
Notificación de cambios en objetos o estado compartido: propagación de cambios hacia múltiples consumidores.
Comunicación por sockets: mensajes que llegan indefinidamente y deben procesarse con filtros o transformaciones.
Flujos de información: secuencias que pueden combinar datos de red, timers, cache y eventos locales.
Control de concurrencia: cancelación de peticiones obsoletas, serialización de operaciones o limitación de frecuencia.

Consideremos un autocompletado. Cada tecla puede disparar una solicitud de red, pero no todas las solicitudes siguen siendo relevantes. RxJs permite aplicar debounceTime, eliminar valores repetidos con distinctUntilChanged y cancelar peticiones previas con switchMap.

import { fromEvent, switchMap } from 'rxjs';
import { debounceTime, distinctUntilChanged, map } from 'rxjs/operators';

const query$ = fromEvent<InputEvent>(searchInput, 'input').pipe(
 map((event) => (event.target as HTMLInputElement).value.trim()),
 debounceTime(300),
 distinctUntilChanged(),
 switchMap((query) => fetch(`/api/search?q=${encodeURIComponent(query)}`))
);

La implementación expresa la intención del flujo: capturar entrada, esperar estabilidad, evitar duplicados y ejecutar la consulta vigente. La lógica queda declarativa y evita coordinación manual con banderas de estado mutable.

Elementos de las extensiones reactivas

RxJs organiza su modelo alrededor de tres piezas principales: Observables, Subscribers y Operators. Entender la responsabilidad de cada una evita mezclar producción de datos, consumo y transformación en el mismo bloque de código.

Observables: la fuente de información

Un Observable representa una fuente de valores a lo largo del tiempo. Puede emitir múltiples valores, un único valor o ninguno. También puede emitir un error o completar su ciclo de vida.

Sus propiedades principales son:

Puede ser finito o infinito.
Puede emitir de forma síncrona o asíncrona.
Puede notificar valores, errores y finalización.
Puede encapsular detalles internos como eventos DOM, sockets, timers o APIs.

import { Observable } from 'rxjs';

const counter$ = new Observable<number>((subscriber) => {
 subscriber.next(1);
 subscriber.next(2);
 subscriber.next(3);
 subscriber.complete();
});

En este ejemplo, counter$ define la fuente de emisiones. La ejecución real ocurre cuando alguien se suscribe; antes de eso, solo existe la definición del flujo.

Subscribers: consumidores del flujo

Un Subscriber consume las emisiones de un observable. Puede reaccionar a valores (next), errores (error) y finalización (complete). La suscripción también representa un recurso que debe liberarse cuando el flujo deja de ser necesario, especialmente en observables infinitos.

const subscription = counter$.subscribe({
 next: (value) => console.log('Valor:', value),
 error: (error) => console.error('Error:', error),
 complete: () => console.log('Flujo completado'),
});

subscription.unsubscribe();

El consumidor no necesita conocer si los datos provienen de un arreglo, un WebSocket, un evento DOM o una API. Esa separación reduce el acoplamiento entre la fuente de datos y quienes procesan sus emisiones.

Operators: transformación, filtrado y composición

Los Operators son funciones que permiten trabajar con observables sin mutar directamente la fuente original. Se encadenan mediante pipe() y habilitan operaciones de transformación, filtrado, combinación y creación.

Algunos operadores frecuentes son:

Transformación: map, scan, groupBy.
Filtrado: filter, distinctUntilChanged, skip, debounceTime.
Combinación: merge, concat, combineLatest, zip.
Creación: of, from, interval, timer.

import { of } from 'rxjs';
import { filter, map, scan } from 'rxjs/operators';

of(1, 2, 3, 4, 5)
 .pipe(
 filter((value) => value % 2 === 1),
 map((value) => value * 10),
 scan((total, value) => total + value, 0)
 )
 .subscribe((value) => console.log(value));

Aquí el flujo filtra impares, transforma cada emisión y acumula el resultado. La fuente original no se modifica; cada operador devuelve un nuevo observable derivado.

Info

La composición con operadores es una de las razones principales para adoptar RxJs: permite expresar pipelines asíncronos complejos con una semántica consistente para valores, errores y finalización.

Beneficios de RxJs y las extensiones reactivas

El beneficio más visible de RxJs es evitar estructuras difíciles de mantener como el callback hell. Sin embargo, su valor no se limita a reemplazar callbacks. RxJs ofrece un modelo uniforme para tratar trabajo síncrono y asíncrono como flujos componibles.

Entre sus ventajas principales están:

Reduce el anidamiento de callbacks y centraliza la lógica del flujo.
Permite trabajar con tareas síncronas y asíncronas bajo la misma abstracción.
Usa operadores para simplificar transformación, filtrado y composición.
Facilita modificar streams sin alterar el consumidor final.
Mejora la legibilidad cuando el problema depende de eventos en el tiempo.
Permite anexar pasos al pipeline sin reescribir toda la implementación.

Esta capacidad de composición es especialmente relevante en aplicaciones grandes. Puedes aislar responsabilidades en operadores específicos y mantener flujos más predecibles, en lugar de dispersar estado mutable entre handlers independientes.

Warning

RxJs no elimina la complejidad del dominio. La desplaza hacia un modelo explícito de streams. Si el problema no involucra secuencias, cancelación, coordinación o múltiples emisiones, una abstracción más simple puede ser suficiente.

Qué es ReactiveX

ReactiveX es una API para programación asíncrona basada en observables. Su objetivo es proporcionar una forma consistente de componer secuencias de eventos y datos a través de operadores. RxJs es la implementación de ReactiveX para JavaScript y TypeScript, documentada oficialmente en rxjs.dev.

ReactiveX se apoya en tres ideas fundamentales: el patrón Observer, el patrón Iterator y la programación funcional. La combinación de estas ideas explica por qué RxJs puede representar datos que llegan en el tiempo, recorrer secuencias y aplicar transformaciones sin mutar la fuente.

Patrón Observer: notificación uno a muchos

El patrón Observer define una relación uno a muchos entre objetos. Cuando el sujeto cambia su estado, notifica a todos sus observadores. En RxJs, el observable cumple el rol de fuente y cada suscripción representa un consumidor interesado en sus emisiones.

flowchart LR
 S[Observable / Subject] -->|next value| A[Subscriber A]
 S -->|next value| B[Subscriber B]
 S -->|next value| C[Subscriber C]
 S -->|error / complete| A
 S -->|error / complete| B
 S -->|error / complete| C

Este patrón resulta natural para interfaces, sockets y estado compartido. La fuente emite cambios y los consumidores reaccionan sin conocer los detalles internos de producción.

Patrón Iterator: operaciones secuenciales

El patrón Iterator define una forma de acceder secuencialmente a los elementos de una colección. ReactiveX toma esa idea y la proyecta sobre el tiempo: en lugar de recorrer una colección ya disponible, procesa valores conforme se emiten.

Un arreglo entrega valores inmediatamente. Un observable puede entregar valores ahora, más tarde o nunca completar. Esa diferencia temporal es la razón por la que los operadores de RxJs son tan útiles para coordinar flujos asíncronos.

Programación funcional: composición sin mutación

La programación funcional aporta la idea de construir transformaciones con funciones específicas, predecibles y sin efectos secundarios innecesarios. Operadores como map y filter no mutan la fuente; generan nuevos observables derivados.

Esta disciplina reduce el acoplamiento y facilita razonar sobre el flujo. Cada operador cumple una responsabilidad concreta y el pipeline completo documenta el recorrido de los datos.

Diagrama de canicas en RxJs

Los diagramas de canicas son una convención visual para explicar cómo se comportan los observables a lo largo del tiempo. Cada línea representa un stream, cada canica representa una emisión, las barras verticales indican finalización y los operadores muestran cómo se transforma el flujo.

Este tipo de diagrama es especialmente útil para entender operadores temporales como debounceTime, throttleTime, delay, switchMap, mergeMap o concatMap. En lugar de describir cada emisión con texto, el diagrama permite comparar el flujo de entrada, el operador aplicado y el flujo resultante.

Al leer un diagrama de canicas, considera estos puntos:

El tiempo avanza de izquierda a derecha.
Cada símbolo o canica representa una emisión del observable.
La barra vertical representa complete.
Una X suele representar error.
Los operadores transforman la relación entre entrada y salida.

Tip

Cuando estudies un operador nuevo, revisa primero su diagrama de canicas y después valida el comportamiento con código. Esa secuencia reduce ambigüedad en operadores temporales y de concurrencia.

Configuración del proyecto para la serie RxJs

Para seguir la serie usaremos como base el repositorio del curso de Klerith: Klerith/curso-rxjs-inicio. Este proyecto proporciona una estructura inicial para practicar RxJs sin dedicar tiempo a configurar desde cero el entorno.

Puedes clonar el repositorio y preparar las dependencias con los comandos habituales:

git clone https://github.com/Klerith/curso-rxjs-inicio.git
cd curso-rxjs-inicio
npm install
npm start

Si prefieres crear un proyecto propio, instala RxJs desde npm y configura TypeScript según tu stack:

npm install rxjs

El objetivo de esta serie no es cubrir la configuración de bundlers, sino entender el modelo mental de RxJs y sus operadores. Mantener un proyecto pequeño al inicio permite enfocarse en observables, suscripciones, composición y manejo del ciclo de vida.

Conclusión

RxJs permite modelar eventos y datos asíncronos como flujos observables. Esta abstracción es útil cuando la aplicación necesita reaccionar a múltiples emisiones, coordinar fuentes, transformar datos y controlar el ciclo de vida de suscripciones.

ReactiveX combina Observer, Iterator y programación funcional para construir una API coherente alrededor de streams. En el siguiente artículo profundizaremos en Observables: cómo se crean, cuándo ejecutan, qué implica suscribirse y cómo gestionar su finalización correctamente.