Flujo de datos: Son datos que se van modificando cada cierto tiempo, y que puede tener interés observar en tiempo real.
+Flujo de datos: Son datos que se van modificando cada cierto tiempo, y que puede tener interés observar en tiempo real. A diferencia de los procesos por lotes, donde los datos se recopilan y procesan en bloques, el data streaming permite la ingestión y procesamiento continuo de datos a medida que estos se generan.
Observable: Un componente que puede ser observado, y que se encargará de informar cuando ese flujo de datos se modifique.
Observador: Es el elemento que observa esas modificaciones. Cuando el dato se modifica, se notifica al componente que lo está utilizando. Normalmente este observer necesita suscribirse cuando quiere empezar a recibir datos, y desuscribirse cuando ya no le interesan más esos datos.
Dispatchers: En cada framework de programación reactiva se llaman de una forma distinta, pero básicamente son un conjunto de hilos donde se van a ejecutar las operaciones, y unas reglas que optimizan su uso para ser lo más eficientes posibles.
-Operadores: Existen montones de operadores que nos permiten modificar y combinar flujos de datos, y conocerlos todos es muy complicado. Dependen de las librerías.
+Operadores: Son funciones que se aplican a streams de datos haciendo uso de la programación funcional. Implementan soluciones a problemas comunes en el procesamiento de streams como agregar, filtrar, mapear. Existen montones de operadores que nos permiten modificar y combinar flujos de datos, y conocerlos todos es muy complicado. Dependen de las librerías.
Para manejar estas situaciones en la programación reactiva se han establecido los siguientes mecanismos: Los suscriptores pueden indicar el número de datos que quieren o pueden procesar, de manera que el notificador nunca les enviará más de n cantidad de elementos. Los notificadores pueden aplicar diferentes operaciones como buffers o descartar algunos datos, para evitar saturar a los suscriptores lentos.
+Backpressure es una solución que implementa el modelo Pull o el patrón de diseño Iterador. Así, hoy día el patrón la programación reactiva implementa dos patrones de diseño : Observer e Iterador
+Lograr los comportamientos que se logran de forma fácil en el paradigma reactivo, resultan muy complicados y con el uso de artefactos complicados en otros paradigmas de programación.
@@ -370,6 +372,20 @@
+ En las primeras aplicaciones de GUI, la interfaz se actualizaba solo después de una acción del usuario,
+ como hacer clic en un botón. El núcleo de la aplicación era un bucle de eventos que esperaba sincrónicamente la
+ entrada del usuario, lo que hacía que la aplicación se colgara si no había interacción.
+
+
+ La solución es desacoplar el manejo de eventos de la actualización de la GUI, utilizando una cola de eventos
+ y un procesamiento paralelo. En este patrón productor-consumidor, un hilo maneja la entrada del usuario y coloca
+ eventos en la cola, mientras otro hilo consume estos eventos y actualiza la GUI.
+
+
@@ -470,6 +486,15 @@
Es un paradigma de programación que combina los principios + de la programación funcional con el manejo de datos que cambian a lo largo del tiempo de manera + continua. En lugar de trabajar con valores discretos emitidos a lo largo del tiempo, como en la + programación reactiva tradicional, la FRP se enfoca en representar y manipular valores que pueden + variar continuamente. Este enfoque permite describir comportamientos dinámicos y sistemas interactivos + de forma declarativa, facilitando el desarrollo de aplicaciones como animaciones, simulaciones y + gráficos interactivos. +
+Fue definida en 1997 por Conal Elliott y Paul Hudak. De acuerdo con una presentación que Elliott dio en el año 2015, titulada "The essence and @@ -500,6 +525,50 @@
+ of: Crea un stream a partir de una lista de elementos. + +
++ from: Convierte varios tipos de datos (arrays, promesas, iterables) en streams. +
++ interval: Emite números secuenciales a intervalos de tiempo específicos. +
+ ++ timer: Emite un valor después de un tiempo determinado. +
+ +merge: Combina múltiples streams emitiendo todos los valores a medida que ocurren.
+concat: Emite todos los valores de un stream y luego continúa con el siguiente.
+combineLatest: Combina múltiples streams emitiendo el último valor de cada uno cada vez que uno de los streams emite.
+zip: Combina valores de múltiples streams en forma de tuplas, emitiendo cada vez que cada stream ha emitido un valor.
+ +map: Aplica una función a cada valor emitido por el stream.
+scan: Acumula valores emitidos utilizando una función acumuladora, similar a reduce en arreglos.
buffer: Agrupa los valores emitidos en arrays.
+ +filter: Emite solo los valores que cumplen con una condición específica.
+debounceTime: Emite un valor solo si ha pasado una cierta cantidad de tiempo desde la última emisión.
+distinctUntilChanged: Emite valores solo si son diferentes del valor anterior.
+ +share: Convierte un stream en un stream multicast compartido entre suscriptores.
+publish: Convierte un stream en un connectable observable que puede ser controlado cuándo empezar a emitir.
+refCount: Convierte un connectable observable en un observable regular que se suscribe y se desuscribe automáticamente basado en la cantidad de suscriptores.
+@@ -950,6 +1019,27 @@
De manera general, la programación reactiva se implementa cuando una aplicación maneje un gran flujo de datos o tenga muchas fuentes de datos y que requiera de alguna manera la propagación de cambio en datos modulos y eventos., sin la programación reactiva estas aplicaciones pueden tener problemas relacionados a la sincronización de los datos y como se muestran en la interfaz grafica. Es comun usar la programación reactiva a la par con la programación orientada a objetos en casos donde la programación asincróna se vuelve dificil de entender y mantener. Es importante mencionar la concurrencia, tema en el cual partes de un programa son ejecutadas con cierta regularidad en desorden o en un orden parcial, estos se pueden comunicar entre ellos mientras se estan ejecutando, con la programación reactiva se mejora la concurrencia de las aplicaciones creando modelos asíncrono, no bloqueantes.
+ Testing de Software + +Mocks y Stubs Reactivos: En lugar de utilizar mocks tradicionales que imitan comportamientos estáticos, + se pueden emplear mocks reactivos que emulen flujos de eventos dinámicos. Esto permite simular condiciones reales + y complejas de manera más cercana.
+ +Testing de Streams y Flujos de Datos: Dado que la FRP se centra en la manipulación de flujos de datos continuos, + es útil para probar cómo los programas reaccionan a cambios en estos flujos. Los frameworks y herramientas diseñados para FRP + facilitan la creación y manipulación de estos flujos durante el testing.
+ +Propiedades y Leyes de Comportamiento: La FRP promueve el diseño de programas en términos de propiedades y leyes de + comportamiento, en lugar de pruebas unitarias tradicionales. Esto facilita la especificación y verificación de comportamientos + complejos a lo largo del tiempo.
+ +Testing de Interacciones Complejas: En aplicaciones donde múltiples eventos y estados deben coordinarse de manera precisa, + la FRP proporciona herramientas para modelar y verificar estas interacciones de manera declarativa y concisa.
+ +Simulación de Entornos Dinámicos: Al simular entornos dinámicos y eventos impredecibles, la FRP puede ayudar a asegurar que + los programas reaccionen de manera correcta y predecible ante situaciones reales.
+ + Algunos casos de uso moderno