RxDart vs FxDart › #49 · Cada llamada alimenta la siguiente

Cada llamada alimenta la siguiente

Empate async

• fx
• toAsync
• map
• scan

Requisito

Cuatro pasos de API corren estrictamente uno tras otro — login, perfil, pedidos, factura — y cada petición se construye a partir de la respuesta anterior (el id de sesión alimenta la llamada de perfil, el id de usuario alimenta la llamada de pedidos, …). Imprime cada paso con su respuesta. La tabla de la API falsa está en el código; las dos versiones deben imprimir las líneas que aparecen bajo Salida esperada.

login -> session-9
profile -> user-42
orders -> order-7
invoice -> pdf-3

Lado a lado

Por qué difieren

Ningún modelo tiene que pelear aquí por la secuencialidad. El asyncMap de RxDart pausa la fuente mientras corre cada future, así que las llamadas son seriales por construcción; un pipeline pull solo pide el siguiente valor después de que el anterior se resolviera, así que es serial por defecto. La diferencia interesante es dónde vive la dependencia — el token que cada respuesta entrega a la petición siguiente.

El lado RxDart lo enhebra por una variable mutable sobre la que el mapper se cierra: idiomático, compacto, y ligeramente fuera del pipeline — el flujo de datos entre pasos es invisible para la cadena de operadores. El lado FxDart lo enhebra por el acumulador de scan, de modo que la respuesta anterior es una entrada explícita del paso siguiente; el coste es que scan emite su semilla, que la impresión tiene que saltarse. Una variable oculta frente a una línea de semilla saltada — un empate genuino, decidido por si prefieres el estado capturado en un closure o el estado visible en el pliegue.