RxJs · DacaCode

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.

RxJs · DacaCode

RxJs: Peticiones HTTP/AJAX con rxjs/ajax y catchError

fetch frente a rxjs/ajax

rxjs ajax para peticiones HTTP

catchError rxjs: recuperar el stream ante fallos

ajax.getJSON para consumir respuestas JSON

Métodos post, put y delete con rxjs/ajax

Configuración avanzada con objeto

Composición con cancelación

Conclusión

RxJs: Operadores de combinación de observables

startWith: inicializar un observable con una primera emisión

endWith: añadir emisiones al completar el stream

concat: combinar observables RxJS de forma secuencial

merge: combinar emisiones concurrentes en un solo observable

combineLatest: sincronizar los últimos valores emitidos

forkJoin: esperar la última emisión de observables finitos

Cómo elegir entre concat, merge, combineLatest y forkJoin

Conclusión

RxJs: Operadores no tan comunes

take: limitar emisiones de un Observable

first: tomar la primera emisión o la primera que cumpla una condición

first con predicado

takeWhile: emitir mientras se mantenga una condición

takeUntil: cancelar un flujo con otro Observable

skip: omitir emisiones iniciales

distinct: eliminar valores repetidos globalmente

distinct con selector para objetos

distinctUntilChanged: evitar repeticiones consecutivas

distinctUntilChanged con comparador

distinctUntilKeyChanged: comparación consecutiva por propiedad

Conclusión

RxJs: Operadores de transformación

mergeAll: aplanar observables internos con concurrencia

mergeMap: transformar y mezclar con concurrencia completa

switchMap: cancelar lo anterior y conservar lo más reciente

concatMap: preservar orden y ejecutar de forma secuencial

exhaustMap: ignorar nuevas emisiones mientras hay trabajo activo

Cuándo elegir cada operador de transformación RxJS

Conclusión

RxJs: Operadores de tiempo

Por qué usar operadores de tiempo RxJS

debounceTime: esperar silencio antes de emitir

throttleTime: limitar la frecuencia de emisión

Configuración leading y trailing

sampleTime: tomar snapshots periódicos del último valor

sample: emitir cuando otro observable lo indique

auditTime: emitir el último valor al cerrar una ventana

Comparación rápida de operadores de tiempo

Conclusión

RxJs: Operadores básicos

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

map: transformar emisiones con map filter rxjs

pluck: extraer propiedades anidadas

mapTo: reemplazar cada emisión por un valor constante

filter: filtrar emisiones del stream

Encadenamiento con el operador pipe rxjs

tap: efectos secundarios sin transformar el flujo

reduce: acumular y emitir al completar

scan: acumular y emitir cada estado intermedio

Conclusión

RxJs: Funciones para crear Observables

Crear observables RxJS con funciones de creación

of: emitir cada argumento como un valor independiente

from: convertir iterables, arreglos y promesas en Observables

fromEvent: crear Observables desde eventos del DOM

Identificar el tipo del evento sin usar any

range: generar secuencias numéricas

range(count): contar desde cero

range(start, count): definir inicio y cantidad

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

interval: emitir valores periódicamente

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

Configuraciones especiales de timer

asyncScheduler: programar trabajo asíncrono

Reprogramar una tarea y cancelar la suscripción

Conclusión

RxJs: Observables, Subscriptions y Subjects

Crear observables rxjs con new Observable

La interfaz Observer: next, error y complete

`startWith`: inicializar un observable con una primera emisión

`endWith`: añadir emisiones al completar el stream

`concat`: combinar observables RxJS de forma secuencial

`merge`: combinar emisiones concurrentes en un solo observable

`combineLatest`: sincronizar los últimos valores emitidos

`forkJoin`: esperar la última emisión de observables finitos

Cómo elegir entre `concat`, `merge`, `combineLatest` y `forkJoin`

`take`: limitar emisiones de un Observable

`first`: tomar la primera emisión o la primera que cumpla una condición

`first` con predicado

`takeWhile`: emitir mientras se mantenga una condición

`takeUntil`: cancelar un flujo con otro Observable

`skip`: omitir emisiones iniciales

`distinct`: eliminar valores repetidos globalmente

`distinct` con selector para objetos

`distinctUntilChanged`: evitar repeticiones consecutivas

`distinctUntilChanged` con comparador

`distinctUntilKeyChanged`: comparación consecutiva por propiedad

`mergeAll`: aplanar observables internos con concurrencia

`mergeMap`: transformar y mezclar con concurrencia completa

`switchMap`: cancelar lo anterior y conservar lo más reciente

`concatMap`: preservar orden y ejecutar de forma secuencial

`exhaustMap`: ignorar nuevas emisiones mientras hay trabajo activo

`debounceTime`: esperar silencio antes de emitir

`throttleTime`: limitar la frecuencia de emisión

Configuración `leading` y `trailing`

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

`sample`: emitir cuando otro observable lo indique

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

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

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

`pluck`: extraer propiedades anidadas

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

`filter`: filtrar emisiones del stream

`tap`: efectos secundarios sin transformar el flujo

`reduce`: acumular y emitir al completar

`scan`: acumular y emitir cada estado intermedio

`of`: emitir cada argumento como un valor independiente

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

`fromEvent`: crear Observables desde eventos del DOM

Identificar el tipo del evento sin usar `any`

`range`: generar secuencias numéricas

`range(count)`: contar desde cero

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

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

`interval`: emitir valores periódicamente

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

Configuraciones especiales de `timer`

`asyncScheduler`: programar trabajo asíncrono

Crear observables rxjs con `new Observable`

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

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

Finalizar desde el observable con `complete()`

Encadenar suscripciones con `.add()`

`Subject RxJS`: multicast y observable caliente

Emitir y completar desde un `Subject`