observable(): exponer un signal como observable

En la lección anterior trajiste fuentes externas hacia dentro de Solid con from. observable hace el viaje contrario: toma un Accessor de Solid y lo envuelve en un objeto que cualquier consumidor de observables —RxJS a la cabeza— reconoce como una fuente nativa. Bajo el capó implementa el protocolo de observables de TC39: un método subscribe que arranca un efecto por cada suscriptor y la clave especial Symbol.observable que anuncia “soy interoperable”. Con from y observable en las manos, la frontera entre el grafo de Solid y el universo de RxJS deja de ser un muro y pasa a ser una puerta giratoria.

Un signal visto desde fuera

observable recibe un accessor y devuelve un objeto con dos capacidades. La primera es un método subscribe(observer), donde observer sigue la forma de TC39 —un objeto con next, error y complete, o directamente una función que hace de next—. Al suscribirte, observable monta por dentro un efecto reactivo aislado en su propio createRoot: lee el accessor, llama a observer.next con el valor actual de inmediato, y vuelve a llamarlo cada vez que el signal cambia. Te devuelve un objeto con unsubscribe que dispone ese efecto.

import { createSignal, observable } from "solid-js";

const [cuenta, setCuenta] = createSignal(0);
const cuenta$ = observable(cuenta);

const sub = cuenta$.subscribe((v) => console.log("emite:", v)); // emite: 0 ya
setCuenta(1); // emite: 1
setCuenta(2); // emite: 2
sub.unsubscribe();

La segunda capacidad es la clave Symbol.observable: el objeto devuelto se implementa a sí mismo bajo esa clave. Ese es el apretón de manos del protocolo TC39, el que permite que una librería ajena diga “dame tu observable” sin saber nada de Solid.

El protocolo TC39 y la interoperabilidad con RxJS

Symbol.observable es una propuesta de estándar que fija un contrato mínimo para que observables de distintas librerías se entiendan. RxJS lo respeta: su propia función from sabe reconocer cualquier objeto que exponga Symbol.observable y adoptarlo como una fuente nativa. Ahí está la pieza que abre todo el catálogo de operadores de RxJS a un signal de Solid.

import { createSignal, observable } from "solid-js";
import { from as rxFrom } from "rxjs";
import { debounceTime, map, distinctUntilChanged } from "rxjs/operators";

const [texto, setTexto] = createSignal("");

const busqueda$ = rxFrom(observable(texto)).pipe(
  map((t) => t.trim()),
  distinctUntilChanged(),
  debounceTime(300),
);

busqueda$.subscribe((consulta) => lanzarBusqueda(consulta));

Fíjate en lo que ocurre: texto es un signal de Solid corriente, editado por un input; observable(texto) lo expone; el from de RxJS lo adopta; y a partir de ahí operan map, distinctUntilChanged y debounceTime, que son territorio donde RxJS brilla. Has delegado la coreografía temporal —recortar, deduplicar, antirebotar— a la herramienta que mejor la expresa, sin sacar el estado del grafo de Solid.

flowchart LR
S[accessor de solid] --> O[observable lo expone push]
O --> X[rxjs from lo adopta]
X --> P[pipe con map debounce filter]
P --> B[de vuelta a solid con from]
style O fill:#89b4fa,color:#11111b
style P fill:#f9e2af,color:#11111b
style B fill:#a6e3a1,color:#11111b

Duales: el viaje de ida y vuelta

from y observable son operaciones inversas, y verlas como par es lo que desbloquea el patrón más potente: el viaje redondo. Sacas un signal a RxJS con observable, aplicas los operadores que quieras, y traes el resultado de vuelta a Solid con from. El estado nunca deja de ser reactivo dentro de Solid; solo hace una excursión por RxJS para aprovechar sus operadores temporales.

import { createSignal, from, observable, createEffect } from "solid-js";
import { from as rxFrom } from "rxjs";
import { debounceTime } from "rxjs/operators";

const [texto, setTexto] = createSignal("");

// solid -> rxjs -> operadores -> solid
const textoDebounced = from(
  rxFrom(observable(texto)).pipe(debounceTime(300)),
);

createEffect(() => console.log("estable:", textoDebounced())); // Accessor de nuevo

El resultado, textoDebounced, vuelve a ser un Accessor<string | undefined> que lees en el grafo como cualquier signal. Las dos fronteras —salida con observable, entrada con from— son simétricas, y esa simetría es la que hace que integrar RxJS en Solid no sea un parche sino una composición limpia.

La forma del observer y sus límites

El observer que pasas a subscribe sigue la forma de TC39: un objeto con next, error y complete, o una función suelta que hace de next. observable invoca next en cada cambio del signal, pero conviene conocer sus límites para no llevarse sorpresas al componer con operadores ajenos.

const sub = observable(cuenta).subscribe({
  next: (v) => pintar(v),
  error: (e) => console.error(e),     // rara vez se dispara solo
  complete: () => console.log("fin"), // nunca por su cuenta
});

Dos límites importan. El primero: observable no emite complete por iniciativa propia, porque un signal no “termina” —vive mientras viva su dueño—; la secuencia se corta cuando llamas a unsubscribe o cuando el dueño se dispone. El segundo: si leer el accessor lanza una excepción, esta se propaga como un error normal de JavaScript en vez de enrutarse automáticamente al canal error del observer, así que un catchError de RxJS aguas abajo no lo verá salvo que lo captures tú. Son las costuras esperables de un puente entre dos modelos de error distintos, y saberlas evita depurar a ciegas cuando el flujo cruzado no se comporta como un observable puro.