Arquitecturas Reactivas de Streams

Javier Vélez Reyes
@javiervelezreye
Javier.velez.reyes@gmail.com
Arquitecturas Reac-vas de Streams
Arquitecturas de Frontend
Octubre 2014

@javiervelezreye 2
Presentación
Arquitecturas Reac:vas de Streams
Licenciado en informá2ca por la Universidad Politécnica de
Madrid (UPM) desde el año 2001 y doctor en informá2ca por la
Universidad Nacional de Educación a Distancia (UNED) desde el
año 2009, Javier es inves2gador y está especializado en el diseño
y análisis de la colaboración. Esta labor la compagina con
ac2vidades de evangelización, consultoría, mentoring y formación
especializada para empresas dentro del sector IT. Inquieto, ávido
lector y seguidor cercano de las innovaciones en tecnología.
I. ¿Quién Soy?

II. ¿A Qué Me Dedico?
Desarrollado Front/Back
Evangelización Web
Arquitectura SoVware
Formación & Consultoría IT
E-learning
Diseño de Sistemas de Colaboración
Learning Analy2cs
Gamiﬁcación Colabora2va

javier.velez.reyes@gmail.com
@javiervelezreye
linkedin.com/in/javiervelezreyes
gplus.to/javiervelezreyes
jvelez77
javiervelezreyes
youtube.com/user/javiervelezreyes

Javier Vélez Reyes
@javiervelezreye
Javier.veler.reyes@gmail.com
1 Introducción
§  La Web Como Modelo Reac2vo
§  Arquitecturas centradas en el modelo
§  Arquitecturas de Programación Funcional Reac2va
§  Principios de las Arquitecturas Reac2vas
Introducción

@javiervelezreye 4
Introducción
A. La Web Como Modelo Reac:vo
I. El Camino Hacia las Arquitecturas Reac:vas
La Web, como plataforma de interacción, es un sistema reac2vo. El árbol DOM que representa
en memoria el documento de la página en curso es un modelo de datos sujeto a cambios sobre
el que pueden registrarse funciones escuchadoras para cada uno de los eventos que el sistema
lanza como señalización de dichos cambios. La programación basada en escuchadores es el
más básico y nuclear de los modelos de construcción de aplica2vos Web.
index.html
<button id='btn'>
<button/>
Click
var btn = document.querySelector('#btn');
var sClicks = document.querySelector('#clicks');
var nClicks = 0;
btn.addEventListener('click', function () {
clicks.innerHTML = ++nClicks;
});
Clicks: <span id="clicks"></span>

@javiervelezreye 5
Introducción
B. Arquitecturas Centradas en el Modelo
Como evolución del modelo de construcción basado en programación de escuchadores,
emergieron una serie de arquitecturas que se recogen bajo el acrónico MV* por sus similitudes
entre sí. Todas ellas comparten la premisa de que están centradas en un modelo interno cuyos
cambios son atendidos por la vista a través de cierta lógica de control. En general este
paraguas recoge diversas variantes arquitectónicas.
Modelo
Vista Controlador
Usuario
manipula
actualiza
MVC
observa usa
Modelo
Adapter
Usuario
manipula
actualiza
MVA
observa usa
Model View Controller
El controlador manipula la vista en
respuesta a las interacciones del
usuario y el modelo actualiza la vista
Model View Adapter
El modelo no se comunica con la vista.
Es el adaptador el encargado de
propagar los cambios en ambas partes
Vista

@javiervelezreye 6
Introducción
M
V C
HMVC
Modelo
Presenter
Usuario
manipula
actualiza
MVP
observa usa
Model View Controller Jerárquico
Los modelos MVC se distribuyen entre el
aplicaCvo para cada componente que se
organizan agregaCvamente
Model ViewPresenter
Como extensión del MVA, el patrón MVP hace
que el controlador se mantenga a las escucha
de los cambios en la vista y el modelo
M
V C
M
V C
Vista

@javiervelezreye 7
Introducción
Model View View-Model
La vista y el modelo de vista permanecen
sincronizados a través de una arquitectura
de observadores y mutadores
Vista Modelo de Vista
Usuario
MVVM
Observa &
interacciona
Data
binding
Modelo
actualiza

@javiervelezreye 8
Introducción
C. Arquitecturas de Programación Funcional Reac:va
En contraposición a las propuestas anteriores que ar2culan su funcionamiento en base a un
proceso de escucha y transformación de un modelo de datos interno más o menos explicito
que representa el estado de la aplicación aparecen las arquitecturas de programación reac2va
donde los eventos son ges2onados por cadenas de transformación funcional que se encargan
de procesar la interacción del usuario de una manera declara2va, inmutable y sin estado.
index.html
<button id='btn'>
<button/>
Click
Clicks: <span id="clicks"></span>
Cadena de Transformación Funcional
Los eventos son recogidos de la plataforma Web
y se les hace atravesar una cadena de
transformaciones funcionales para procesar los
resultados

@javiervelezreye 9
Introducción
A. Dirigida por los Datos
II. Principios de Programación Reac:va
Las arquitecturas de programación funcional reac2va definen cadenas de transformación
funcional que son atravesadas por flujos de datos para su procesamiento. Se dice que este 2po
de soluciones está dirigida por los datos por que en ellos descansa gran parte de la lógica de la
aplicación y el propio comportamiento reac2vo del sistema.
Click
click, click, click...
filter
group
take(10)
f
Cadena de Transformación
La cadena de transformación filtra los eventos
de usuario, los agrupa por pares si éstos se
producen con cierta frecuencia temporal para
representar el doble click y finalmente absorbe
sólo los 10 primeros
Comportamiento dirigido por datos
La naturaleza de los datos atravesados
por la cadena de transformación
condiciona cuándo se ejecutará f

@javiervelezreye 10
Introducción
B. Centrada en la Composición
Las operaciones que forman parte del procesamiento de datos en programación reac2va se
encadenan de forma composi2va de manera que el resultado de cada transformación es la
entrada para la siguiente transformación. Para poder ar2cular adecuadamente esta
composición debemos tener en cuenta dos reglas de transformación funcional.
El Cpo del parámetro de entrada de una función debe
ser compaCble con el Cpo del valor de retorno devuelto
por la función anterior para que la composición pueda
arCcularse con éxito. Las arquitecturas reacCvas
también cumplen este requisito puesto que reciben
eventos como entrada y generan eventos de salida
II. Compa:bilidad Rango-Dominio
I. Dominio Simple
Dado que las funciones devuelven un único valor de
retorno, el número de parámetros de entrada que puede
aceptar una función en una composición debe ser
exactamente uno. En el caso de la programación reacCva,
la información se encapsula en una estructura de datos
que representa un evento lo que permite cumplir esta
condición
F
G
T
U
El Cpo de salida T debe ser compaCble con
el Cpo de entrada U. En términos OOP
diríamos que T debe ser subCpo de U
filter
group
f
event

@javiervelezreye 11
Introducción
C. Transparencia Referencial
El principio de transparencia referencial predica que en toda especiﬁcación funcional correcta,
cualquier función debe poder subs2tuirse en cualquier ámbito de aplicación por su expresión
funcional sin que ello afecte al resultado obtenido. Equivalentemente, esto implica que el valor
de retorno de las funciones, como cualquier transformación matemá2ca, sólo puede depender
de sus parámetros de entrada y no de condiciones ambientales.
f
Estado
Funciones Puras
Se dice que las operaciones de transformación
son funciones puras en tanto que garanCzan el
mantenimiento de la transparencia referencial.
Así, su valor de retorno sólo depende de los
parámetros de entrada y no del estado
ambiental (variables globales, variables
retenidas en ámbito léxico, operaciones de E/S,
etc.)

@javiervelezreye 12
Introducción
D. Comportamiento Idempotente
Un principio en estrecha relación con el de transparencia referencial es de de comportamiento
idempotente según el cual cada función de transformación debe devolver siempre el mismo
resultado para los mismos parámetros de entrada. Esto permite razonar algebraicamente
sobre la validez del procesamiento reac2vo.
La operación ﬁlter se encarga de dejar
pasar a la cadena composiCva sólo
aquellos eventos en los que x Cene un
valor par. Se trata de una operación
idempotente porque para el mismo evento
de entrada siempre procede igual
filter ( x es par )
scan (0)
f
Operación Idempotente
La operación scan cuenta el número de
eventos que atraviesan la atraviesa y
devuelve un evento con el valor de dicho
contador en cada invocación. Se trata de
una operación no idempotente porque el
valor devuelto depende del número de
invocaciones anteriores
Operación No Idempotente

@javiervelezreye 13
Introducción
E. Inmutabilidad de Datos
Un úl2mo principio heredado de la programación funcional que debemos tener en cuenta en
la construcción de arquitecturas reac2vas es el principio de inmutabilidad de datos. En
términos prác2cos la aplicación se este principio se traduce en que las funciones nunca deben
actualizar los parámetros de entrada como resultado de su ejecución sino solamente generar a
par2r de ellos resultados de salida.
Los eventos que atraviesan la
función f son transformados
para generar un resultado de
salida
Función Mutadora
function f(e) {
e.value = e.value + 10;
return e;
}
Función No Mutadora
function f(e) {
var ne = new Event (e);
ne.value = ne.value + 10;
return ne;
}
Para no modiﬁcar el evento a la
entrada, la función f construye
una nueva copia del mismo y lo
transforma para generar el
resultado de salida

Javier Vélez Reyes
@javiervelezreye
2 Conceptos
Esenciales
§  Arquitecturas Web Reac2vas
§  Visión Está2ca
§  Visión Dinámica
Conceptos Esenciales

@javiervelezreye 15
La programación funcional reac2va es un modelo de programación que pretende dar respuesta
a la demanda creciente de nuevos sistemas más ﬂexibles, elás2cos y tolerantes a fallos a par2r
de los principios propios de la programación funcional. Esta aproximación resulta muy
ventajosa en tanto que produce desarrollos más declara2vos y explícitos centrados en las
transformaciones que deben sufrir los datos para su procesamiento.
I. Arquitecturas Web Reac:vas
Las Arquitectura Web Reac-vas son sistemas soaware que
operan en reacción a los eventos ocurridos sobre el modelo de
datos DOM de la Web. Cada evento atraviesa una cadena de
transformación funcional para su procesamiento.
La lógica de negocio de una arquitectura
reacCva queda capturada en la cadena de
transformaciones que es atravesada por cada
evento. Estas transformaciones son en general
inmutables, idempotentes y agnósCcas de las
condiciones ambientales
I. Construcción Composi:va
Paradójicamente, las operaciones de
transformación que arCculan las arquitec-
turas reacCvas están en estrecha relación
con el Cempo ya que éste es un factor
determinante a la hora de construir modelos
de comportamiento reacCvo
II. Modelado Explicito del Tiempo

@javiervelezreye 16
Desde un punto de vista estructural, las arquitecturas de programación funcional reac2va
están caracterizadas por una colección de abstracciones funcionales. Estas abstracciones se
encadenan secuencialmente para que lleven a cabo las tareas de procesamiento y
transformación de eventos desde la fuente emisora a los sumideros receptores de manera que
toda la lógica de negocio se expresa de forma declara2va y distribuida a lo largo de la cadena.
II. Visión Está:ca
Fuente
La fuente es la encargada de
proporcionar los eventos a la
cadena de transformación
Cadena de Transformación
Las operaciones de transfor-
mación funcional se enca-
denan composiCvamente
Sumidero
Al ﬁnal de cada cadena se pueden
colocar receptores que recogen los
datos procesados e incluso pueden
mezclarse con otras cadenas
Transformación
Cada operación dentro de la cadena
es una transformación funcional no
mutadora
Stream de Eventos
Los eventos provenientes de la
fuente de datos ﬂuyen discrecional-
mente a lo largo del Cempo

@javiervelezreye 17
A. Línea de Tiempo
III. Visión Dinámica
El comportamiento de las arquitecturas reac2vas de programación funcional se encuentra en
estrecha relación con el factor 2empo. En efecto, la lógica de las operaciones que forman parte
de la cadena de transformación depende comúnmente de aspectos tales como el número de
eventos procesados hasta el momento, su frecuencia de aparición o su periodo. Esto permite
modelar fácilmente comportamientos sistémicos que dependen del 2empo.
Cada evento ocupa una
posición sobre la línea de
Cempos
Evento
Los streams también pueden generar
errores que se capturan y gesConan
como eventos especiales
Error
Indica la terminación de la
llegada y procesamiento de
eventos por parte del stream
Terminación
Representa el histórico de
eventos en un procesamiento
de eventos. La punta de
ﬂecha indica el momento
actual
Línea de :empo

@javiervelezreye 18
B. Diagramas de Reac:vidad
La mejor manera de razonar sobre las arquitectura reac2vas es por medio del uso de
diagramas de reac2vidad. Un diagrama de reac2vidad es una representación alterna de líneas
de 2empo y operaciones de transformación funcional. Cada una de estas operaciones recibe
como entrada la línea de 2empo anterior y genera como salida la línea subsiguiente.
clicks
groups
size 3 2 1
Double click 3 2
Cada operación recibe
una línea de Cempo
como entrada y genera a
su salída otra línea de
Cempo con eventos
nuevos
Operaciones
Cada línea es una proyección a
lo largo del Cempo de lo que
ocurre en el sistema en un
punto determinado de la
cadena
Líneas de Tiempo
buﬀer (throdle (250 ms))
map (get length of group)
ﬁlter (size > 1)

@javiervelezreye 19
B. Diagramas de Reac:vidad
Los diagramas de reac2vidad ofrecen una visión del comportamiento de las arquitecturas
reac2vas en torno a dos perspec2vas ortogonales. En cada ver2cal se puede comprobar cuál es
el proceso de transformación que sufre un evento en un momento del 2empo.
Horizontalmente, se contempla el comportamiento de cada fase a lo largo del 2empo
clicks
groups
size
Double click
Se razona sobre lo que
ocurre en un instante de
Cempo con el procesa-
miento de un evento
concreto a lo largo de la
cadena
Dimensión Ver:cal
Se razona acerca de cómo se
comporta cada fase y el
proceso independientemente
de la dimensión Cempo
Dimensión Horizontal
3 2 1
3 2
buﬀer (throdle (250 ms))
map (get length of group)
ﬁlter (size > 1)

@javiervelezreye 20
C. Operaciones Reac:vas
Para completar la descripción del comportamiento dinámico es necesario conocer las
principales operaciones que pueden aplicarse para definir cadenas de transformación. El léxico
de las mismas cambia de una librería a otra pero en esencia todas proporcionan el mismo
juego de facilidades declara2vas.
Operaciones de Creación
Las operaciones de creación permiten crear
disCntas fuentes de eventos en relación a
disCntos orígenes asíncronos de datos
subscribe ( f )
Operaciones de Terminación
Las operaciones de terminación permiten
definir sumideros al final de una cadena
reacCva
stream ( css )
values ( interval, v )
serie ( delay, it)
error ( f )
end ( f )

@javiervelezreye 21
Para completar la descripción del comportamiento dinámico es necesario conocer las
principales operaciones que pueden aplicarse para deﬁnir cadenas de transformación. El léxico
de las mismas cambia de una librería a otra pero en esencia todas proporcionan el mismo
juego de facilidades declara2vas.
Operaciones de Mezcla de Streams
Las operaciones de entrelazado y mezcla de streams de eventos permiten fusionar
varios streams de eventos para crear streams de eventos compuestos. Esto permite
que un mismo stream pueda ser procesado por más de una cadena de composición
de forma simultanea
concat
4 1
5 3 2 7 6
5 4 1 7 6
merge
4 1
5 3 2
3 2 1 5 4
startWith (v)
v
4 3 2
3 2 v 5 4
5

@javiervelezreye 22
Del capítulo anterior ya ha quedado patente que las arquitecturas reac2vas presentan una
clara formulación funcional. Se trata en esencia de deﬁnir cadenas de transformación que
serán atravesadas por los datos según van generándose. Sin embargo en términos más
prác2cos existen una serie de carácterís2cas diferenciales que resumimos a con2nuación.
Operaciones de Ges:ón Temporal
Las operaciones de gesCón del Cempo permiten modelar
comportamientos reacCvos que Cenen en cuenta condiciones temporales
en relación a los eventos. Dado que estas funciones dependen de las
condiciones ambientales y frecuentemente no Cenen un comportamiento
idempotente su ajuste al paradigma funcional queda un poco en
entredicho.
3 2 7 9
3 2 7 9
hold ( <5 )
3 2 7 9
7 9
skip (2)
3 2 7 9
3 2
take ( 2 )
3 2 7 9
3 2 7 9
delay ( 10 ms )
throdle ( 5 ms )

@javiervelezreye 23
Del capítulo anterior ya ha quedado patente que las arquitecturas reac2vas presentan una
clara formulación funcional. Se trata en esencia de definir cadenas de transformación que
serán atravesadas por los datos según van generándose. Sin embargo en términos más
prác2cos existen una serie de carácterís2cas diferenciales que resumimos a con2nuación.
Operaciones de Secuenciamiento
Las operaciones clásicas de secuenciamiento
(map, reduce, filter) se adaptan al modelo
unitario de procesamiento reacCvo
map ( f ) filter ( f )
3
3
4
7
scan ( 0, + )
Operaciones de Asincronía
Las operaciones asíncronas permiten
gesConar disCntos aspectos relacionados
con el carácter asíncrono de los eventos
3 4
7
reduce ( 0, + )
map ( p )
p
v
p
v
flatMap ( p )

Javier Vélez Reyes
@javiervelezreye
3 Un Framework Sencillo
de Programación
Reac-va
§  Modelos de Programación Reac2va
§  Framework Sencillo de Programación Reac2va
§  Evaluación
Un Framework Sencillo de Programación Reac-va

@javiervelezreye 25
Un Framework Sencillo de Programación Reac2va
A. Modelos de Operación Pull & Push
I. Modelos de Programación Reac:va
Es posible caracterizar las arquitecturas de programación funcional reac2va en virtud de la
naturaleza síncrona o asíncrona de los datos que procesan. Ello da lugar a sendos modelos de
operación conocidos con el nombre de Pull y Push respec2vamente. En el primer caso, es el
sumidero el que pide nuevos datos a la cadena mientas que en el segundo es la fuente la
encargada de empujar dichos datos proac2vamente en cuanto éstos son generados.
I. Modelo Pull
En el modelo pull, el sumidero solicita nuevos
datos y la solicitud recorre ascendentemente la
cadena hasta llegar a la fuente
La fuente es la enCdad pasiva
que genera nuevos datos bajo
demanda
I. Modelo Push
En el modelo push, a medida que se disponen de
nuevos datos, la fuente los empuja por la cadena
de transformación hacia abajo
La fuente es la enCdad acCva
que produce datos y los
entrega a la cadena
El sumidero es la enCdad
acCva que pide a la cadena
nuevos datos procesados para
ser consumidos
El sumidero es una enCdad
pasiva que se manCene a la
escucha para consumir datos
cuando llegan desde la cadena

@javiervelezreye 26
B. Modelos de Computación Con:nua & Discreta
Ortogonalmente, las fuentes también pueden clasiﬁcarse en virtud de la naturaleza con2nua o
discreta de los datos que procesan. En el primer caso, hablamos de modelos de streamimg
donde los datos son señales con2nuas y perdurables mientras que en el segundo caso, cada
dato representa una ocurrencia puntual en el 2empo y ello conforma arquitecturas dirigidas
por eventos.
I. Modelo Con:nuo
En el modelo de computación conCnua los datos
se corresponden con streams llamados señales o
comportamientos
Los sistemas reaccionan a los
cambios en el ﬂujo de datos. A
este cambio se le suele llamar
switching. En este Cpo de
sistemas la frecuencia de
muestreo es uno de los
parámetros caracterísCcos
I. Modelo Discreto
En el modelo discreto los datos se corresponden
con eventos que se producen en instantes
puntuales del Cempo
Los eventos son elementos
vehiculares que acarrean
valores de contexto transfor-
mados a través de la cadena
reacCva

@javiervelezreye 27
C. Clasificación
Es posible establecer las dos caracterizaciones anteriores como dos ejes dimensionales
dispuestos ortogonalmente. Ello da lugar a un espacio de clasificación que divide las
arquitecturas reac2vas en cuatro familias. Nosotros centraremos nuestra atención en
arquitecturas Web reac2vas.
Modelos Con:nuos
Basados en Streams
Modelos Discretos
Basados en Eventos
Modelos Síncronos
Modo Pull
Modelos Asíncronos
Modo Push
Programación Web Reac:va
BigData Event Processing
Modelo de Actores
WebSockets
Iteradores & Generadores
Colecciones Infinitas
Evaluación Perezosa
Signal Processing
Noise Generators
Streamming de datos
Video & Audio Streams
Web Audio API
WebRTC

@javiervelezreye 28
A. Generación de Fuentes
II. Framework Sencillo de Programación Reac:va
Como hemos visto en el capítulo anterior existe una gran variedad de constructores que
permiten deﬁnir fuentes asíncronas que funcionan en modo Push. Aquí nos centraremos en
presentar el código interno de las más comúnmente u2lizadas.
Adaptador de Evento Web
Los adaptadores de eventos son funciones
que recogen eventos Web y los redirigen a
una función manejadora pasada como
argumento en una segunda fase de
evaluación

En este ejemplo se ve cómo la función
fromTarget construye una fuente s a parCr
de un selector css y un Cpo de evento

function fromTarget(css, type) {
var target = document.querySelector (css);
return function (fn) {
target.addEventListener(type, function (e) {
fn(e);
});
};
}
function fromTargetAll(css, type) {
var targets = document.querySelectorAll (css);
[].forEach.call(targets, function (target) {
target.addEventListener(type, function (e) {
fn(e);
});
});
};
}
<button id="btn">click</button>
...
<script>
var s = fromTarget('#btn', 'click');
s(console.log);
</script>

@javiervelezreye 29
Adaptador de Colección
Los adaptadores de colección persiguen
generar fuentes push que iteran circular-
mente sobre los elementos de una colección
a intervalos regulares de Cempo

La función fromValues recibe un array de
valores y un intervalo de Cempo y construye
una función que emiCrá un evento con el
valor siguiente en la colección cada vez que
es invocado
function fromValues (values, ms) {
var idx = 0;
var hn = fn || function () {};
setInterval (function () {
fn(values[idx]);
idx = (idx + 1) % values.length;
}, ms || 1000);
};
}
var s = fromValues([1,2,3]);
s(console.log);
En este sencillo ejemplo, la construcción de la
fuente asíncrona de eventos emite circularmente, a
intervalos regulares de 1 segundo, los elementos
del array pasado como parámetro de entrada. Los
eventos se vinculan al escuchador de salida
estándar

@javiervelezreye 30
Adaptador de Iteración
La función serie toma una función genérica fn y
devuelve otra función iteradora que genera valores
consecuCvos aplicando dicha función

fromSerie es una fuente push que invoca la serie
pasada como parámetro a intervalos regulares de
Cempo. Esta es una manera de hacer un adaptador
Push sobre una fuente Pull

El código de ejemplo deﬁne la función inc y sobre ella
genera la serie de números naturales num. Despues
construye una fuente y la vincula a la salida estándar
function serie (fn, base) {
var value = base;
return function () {
value = fn(value);
return value;
};
}
function fromSerie (serie, ms) {
var hn = fn || function () {};
setInterval (function () {
var value = serie();
fn(value);
}, ms || 1000);
};
}
var inc = function (x) { return x + 1; }
var num = serie(inc, 0);
var s = fromSerie(num, 3000);
s(console.log);

@javiervelezreye 31
B. Operadores de Transformación
Hasta ahora damos soporte a la definición de fuentes de diferentes 2pos que se conectan en
modo Push a sumideros directamente. Definamos a con2nuación, la colección de operadores
de transformación que podrán ser u2lizados para definir cadenas en nuestro framework.
Operador map
El operador map es una función de orden superior
que recibe como parámetro una función fn genérica
y devuelve otra función como resultado. El
comportamiento de dicha función es invocar a fn con
los argumentos pasados como parámetro en esta
función de retorno

El siguiente código de ejemplo muestra un uso
protoipico de la función map que transforma cada
dato de entrada en su cuadrado. Para ello se aplica
map con una función anónima que define el
cuadrado y luego se aplica la función resultante
function map (fn) {
return fn.apply(this, arguments);
};
}
var sqr = map(function (x) {
return x * x;
});
sqr(3); // 9
0
1
1
1
2
4
3
9
map ( x => x * x )

@javiervelezreye 32
Operador filter
El operador filter recibe un predicado lógico como
parámetro y genera otra función como retorno cuyo
propósito es filtrar sólo aquellos argumentos que
saCsfagan dicho predicado. Si el filtro no es pasado
entonces la función devuelve undefined

En el ejemplo siguiente se aplica el operador filter
sobre un predicado lógico que determina si un valor
es par. El resultado es una función que sólo deja
filtrar los eventos con valor par.
function filter (fn) {
var out = fn.apply (this, arguments);
if (out) return arguments[0];
};
}
var even = filter(function (x) {
return x % 2 === 0;
});
even(2); // 2
even(3); // undefined
0
1
1 2
2
3
filter ( x => x % 2 === 0 )

@javiervelezreye 33
Operador scan
El operador scan es un operador con memoria. Cada
nuevo dato lo combina con un acumulador retenido
en ac a través de una función binaria de reducción
pasada como parámetro. El valor inicial del
acumulador se pasa como segundo parámetro b de
la función

En el ejemplo adjunto se aplica el operador scan
sobre la función reductora de la suma y con base en
0. Como resultado, cada evento devuelve la suma
acumulada de los valores en los eventos procesados
hasta el momento
function scan (fn, b) {
var ac = b;
var args = [].slice.call (arguments);
ac = fn.apply (this, [ac].concat(args));
return ac;
};
}
var add = scan(function (x, y) {
return x + y;
}, 0);
add(2); // 2 = 2 + 0
add(3); // 5 = 3 + 2
add(4); // 9 = 4 + 5
0
0
1
1
2
3
3
6
reduce ( ( x, y ) => x + y , 0 )

@javiervelezreye 34
C. Encadenamiento de Operadores
Nuestros operadores aplican funciones de transformación y devuelven el resultado de dicha
aplicación. Como tal no pueden encadenarse de acuerdo a una sintaxis de API fluida. Es
necesario definir una función que adapte cada función adecuadamente en este sen2do.
var numbers = fromValues([2,3,4])
.map(sqr)
.filter(even)
.scan(add, 0)
.end();
numbers(console.log); sqr
even
add
function fluent (hn) {
var cb = hn || function () {};
cb(fn.apply(this, arguments));
return this;
};
};
}
Se pretende transformar de forma transparente
las funciones map, filter y scan para que puedan
ser encadenadas en notación de punto a modo de
API fluida
El orden en que se incluyen las
transformaciones sqr, even y
add en la expresión de API
fluida corresponde al orden en
que éstas son añadidas en la
cadena reacCva
Necesitamos transformar los operadores a través de la
función fluid que genera una función para ejecutar el
operador, entregar el resultado a un manejador y devolver
una referencia al objeto de contexto sobre el que se aplica
el operador punto para poder seguir encadenando
operadores

@javiervelezreye 35
D. Composición de Transformaciones
Una vez logrado el obje2vo de encadenar operadores y antes de cerrar nuestro framework es
necesario deﬁnir una función de secuenciamiento que aplique composi2vamente cada función
de transformación dentro de la cadena. Veamos como hacerlo.
function sequence (fns) {
return function (x) {
return fns.reduce (function (ac, fn) {
return (ac !== void 0) ?
fn(ac) :
void 0;
}, x);
};
}
La función sequence recorre el array de funciones
pasado como parámetro y lo aplica composiCva-
mente a parCr del parámetro x. Como se ve la
implementación hace uso de una estrategia de
reducción con base en x y garanCza que en todo
momento cada función aplicada devuelve un
resultado no nulo
var s = sequence([
map(sqr),
filter(even),
scan(add, 0)
]);
s(3) // undefined (even(9) === false)
S(2) // 4
Para entender mejor como opera esta función pensemos
en un ejemplo con el array de funciones [sqr, even, add].
Pretendemos construir una función que cuando se invoque
sobre x devuelva el resultado composiCvo equivalente a
evaluar la expresión add ( even ( sqr ( x ) ) )

@javiervelezreye 36
E. Constructor Stream
Después de todo este trabajo sólo resta definir
el constructor Stream que proporciona el
objeto de contexto donde se definirá la cadena
de composición, incluir las funciones anterio-
res y añadir alguna lógica adicional para sopor-
tar el proceso de registro de escuchadores.
Patrón Stream Push
function Stream (source) {
var fns = [];
var lns = [];
var define = fluent (function (fn) {
fns.push (fn);
});
return {
map : define (map),
filter: define (filter),
scan : define (scan),
end: function () {
var seq = sequence(fns);
source(function (data) {
var result = seq(data);
lns.forEach(function (ln) {
if (result) ln (result);
});
});
return {
listen: function (ln) {
lns.push(ln);
}
};
}
};
}
La colección lns acumula los escuchadores que se
registran al stream para ser noCficados de cada
nuevo resultado procesado

La función end aplica sequence una vez para obtener
la cadena de composición y después arranca la
fuente con un manejador que obCene el siguiente
resultado y si es definido lo publica a cada
escuchador

Como retorno se devuelve un objeto con un método
listen que permite registrar nuevos manejadores
asociados a escuchadores interesados

@javiervelezreye 37
Antes de terminar repasaremos un par de ejemplos sencillos que pueden ser desarrollados con
nuestro framework de forma declara2va. Para cada ejemplo incluiremos a efectos
compara2vos la versión tradicional basada en eventos Web para apreciar sus diferencias.
III. Evaluación
var data = serie (function (x) { return x + 1; }, 0);
var source = fromSerie(data);
var stream = Stream (source)
.map (function (e) { return e * e; })
.filter (function (e) { return e % 2 === 0})
.scan (function (a, e) { return a + e; }, 0)
.end ();
stream.listen (console.log);
La serie de datos genera un iterador de
naturales que se emplea como fuente
push para una cadena de trasforma-
dores [sqr, event, add]. Tras ﬁnalizar la
declaración de la cadena, se invoca el
método listen para registrar a la
consola como único escuchador
Suma de Cuadrados Pares
var idx = 0;
var sqr = function (n) {
var sqrn = n * n;
if (sqrn % 2 === 0) console.log (sqrn);
idx++;
setTimeout(function () { sqr(n+1); }, 1000);
};
sqr(0);
La versión imperaCva de este problema es
considerablemente menos declaraCva que la
forma reacCva. Además se trata de una solución
con estado donde el estado no está encapsulado
sino mantenido por una variable externa idx.
Reac:vo
Clásico

@javiervelezreye 38
III. Evaluación
En el enfoque clásico se uClizan
variables para referir los elementos
(display & btns) y para mantener el
estado (count) así como estructuras de
control de ﬂujo para arCcular el proceso
de registro de escuchadores
Contador de Clicks
<button id="up" class="btn">Up</button>
<button id="down" class="btn">Down</button>
<span id="display"></span>
<script>
var count = 0;
var display = document.querySelector('#display');
var btns = document.querySelectorAll('.btn');
var register = function (idx) {
btns[idx].addEventListener ('click', function (e) {
if (e.currentTarget.id === 'up') count++;
if (e.currentTarget.id === 'down') count--;
display.innerHTML = count;
});
};
for (var idx=0; idx < btns.length; idx++)
register(idx);
</script>
Clásico
Up Down 7

@javiervelezreye 39
III. Evaluación
La versión reacCva resulta mucho más declaraCva y limpia.
Primero se crea una fuente adaptadora de eventos click
sobre el target .btn y después se deﬁne una cadena
formada por dos operaciones, la primera idenCﬁca el paso
de incremento que se debe aplicar a la suma y la segunda
realiza la suma. Aquí no existe contador explícito
Contador de Clicks
var source = fromTargetAll('.btn', 'click');
var stream = Stream (source)
.map (function (e) { return e.currentTarget.id === 'up' ? 1 : -1 })
.scan (function (a, e) { return a + e; }, 0)
.end ();
stream.listen (function (n) {
document.querySelector('#display').innerHTML = n;
});
Reac:vo
Up Down 7

@javiervelezreye 40
Preguntas
Eventos
Stream Composición
Reac:vidad
Javier Vélez Reyes
@javiervelezreye
Javier.velez.reyes@gmail.com

Arquitecturas Reactivas de Streams

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Destacado

Destacado (20)

Similar a Arquitecturas Reactivas de Streams

Similar a Arquitecturas Reactivas de Streams (20)

Último

Último (7)

Arquitecturas Reactivas de Streams