Luego de tanto luchar pudimos encontrar el arreglo de esta problema que tantos usuarios de este sitio presentan. Si deseas aportar alguna información puedes dejar tu comentario.
Solución:
¿En qué se diferencia la programación reactiva de la programación impulsada por eventos?
La programación impulsada por eventos gira en torno a los llamados eventos, que son cosas abstractas que los programas “disparan” cuando sucede algo. Otros lugares en su código “escuchan” los eventos y responden con lo que necesitan hacer cuando ocurre ese evento. Por ejemplo, un evento podría ser “el usuario presionó este botón” o “la impresora terminó de imprimir su documento”.
La programación reactiva se ocupa de datos. En última instancia, este es un caso especial de programación impulsada por eventos. El evento: los datos cambiaron. El controlador de eventos: cambie algunos datos más (si corresponde). Este concepto generalmente se aclara cuando piensa en una hoja de cálculo. Si pones cell1 = cell2 + cell3 esto establece implícitamente dos controladores de eventos en los eventos de cambio de datos de cell2 y cell3 actualizar cell1datos de. cell1Los datos de ‘no tienen tal controlador de eventos, porque ninguna celda depende de su valor.
TL; DR;
Wikipedia dice que hay varias formas de escribir código reactivo, como imperativo, OORP y funcional. Quiero saber si el control de eventos es solo otra forma de escribir código reactivo.
La idea de la programación impulsada por eventos es ortogonal a la idea de imperativo frente a OO frente a funcional.
- Programación imperitiva: se enfoca en cambiar el estado de tu programa para lograr lo que deseas. La mayoría de las computadoras son imperativas (a diferencia de la programación declarativa), mientras que los lenguajes de nivel superior a veces son declarativos. La programación declarativa, por el contrario, se ocupa de escribir código que especifica QUÉ quieres que haga en lugar de CÓMO quieres que lo haga.
- Oobjeto OProgramación orientada: se ocupa de los denominados objetos o bolsas de datos con métodos asociados. Se diferencia de la programación funcional porque los métodos pueden acceder a los datos asociados con los objetos.
- Programación funcional: se ocupa de funciones reutilizables o procedimientos que toman entradas y salidas. Esto difiere de la programación OO porque las funciones tradicionalmente no tienen la capacidad de asociar datos con una función distinta a las entradas y salidas.
Programación dirigida por eventos: estructura su programa para tratar (“manejar”) algo más que sucede en su programa (un “evento”). En otras palabras, estructura su código lógicamente así
When Event1 happens
do A and B
When Event2 happens
do B and C
Pero hay muchas formas de escribir este código y, de hecho, muchas formas de escribir el código imperativamente, muchas formas de escribirlo funcionalmente, etc. Sin embargo, aquí hay algunos ejemplos.
Imperativamente (con un bucle de eventos):
while(true)
// some other code that you need to do...
if Event1 then
do A
do B
if Event2 then
do B
do C
Orientado a objetos (con hilo de fondo):
// event queue
events = new EventQueue()
handler = new EventHandler()
// creates background thread
Thread.DoInBackground(handler.listenForEvents(events))
// ... other code ...
// fire an event!
events.enqueue(new Event1())
// other file
class EventHandler
Func listenForEvents(events)
while(true)
while events.count > 0
newEvent = event.dequeue()
this.handleEvent(newEvent)
Thread.Sleep(Time.Seconds(1))
Func handleEvent(event)
if event is Event1
this.A()
this.B()
if event is Event2
this.B()
this.C()
Func A()
// do stuff
return
Func B()
// do stuff
return
Func C()
// do stuff
return
Funcional (con soporte de idiomas para eventos)
on Event(1) do Event1Handler()
on Event(2) do Event2Handler()
Func Event1Handler()
do A()
do B()
Func Event2Handler()
do B()
do C()
Func A()
// do stuff
return
Func B()
// do stuff
return
Func C()
// do stuff
return
// ... some other code ...
// fire! ... some languages support features like this, and others have
// libraries with APIs that look a lot like this.
fire Event(1)
¿Cómo se relaciona la programación reactiva con Promesas?
Las promesas son una abstracción del flujo de ejecución del programa que se puede resumir de la siguiente manera:
- Persona que pregunta: Siempre que termine de hacer lo que está haciendo, ¿me devolvería la llamada?
- Respondedor: Claro, yo promesa
No hay nada realmente especial aquí, excepto que es otra forma de pensar en el orden en que se ejecuta su código. Por ejemplo, las promesas son útiles cuando realiza una llamada a una máquina remota. Con promesas, puedes decir “llámame cuando regreses de esta llamada remota”. Cualquiera que sea la biblioteca que use entonces promesas para devolverle la llamada cuando reciba algo de la máquina remota. A menudo, esto es útil porque le permite hacer otra cosa mientras tanto sin esperar a que vuelva la llamada.
Punch line: hay muchos estilos diferentes de código, pero no juegan un papel muy importante en el patrón de programación reactiva y dirigida por eventos. Que yo sepa, puede realizar programación basada en eventos y / o reactiva en la mayoría de los lenguajes.
¿Cómo se relaciona la programación reactiva con Promesas? Creo que la promesa es una alternativa al infierno impulsado por eventos y devoluciones de llamada.
En la práctica, los dos están relacionados, me gusta llamar a Promises un fármaco de entrada a la programación funcional reactiva.
+----------------------+--------+-------------+
| | Sync | Async |
+----------------------+--------+-------------+
| Single value or null | Option | Promise |
| Multiple values | List | EventStream |
+----------------------+--------+-------------+
Las promesas se pueden considerar como EventStreams con un elemento, o puede pensar en EventStreams como múltiples promesas a lo largo del tiempo.
Las promesas se pueden encadenar, lo que se acerca a la programación reactiva:
getUser() // return promise
.then((userId) =>
return fetch("/users/"+userId)
)
.then((user) =>
alert("Fetched user: " + user.name)
)
Lo mismo con bacon.js:
const userStream = userIdStream // EventStream of userIds
.flatMapLatest((userId) =>
return Bacon.fromPromise(fetch("/users/"+userId))
)
const userNameStream = userStream.map((user) => user.name)
userNameStream.onValue((user) =>
alert("Fetched user: " + user.name)
)
Ambos fragmentos de código hacen lo mismo, pero hay una gran diferencia en el pensamiento: con las promesas, estás pensando en manejar una sola acción con pasos asíncronos de una manera clara: el pensamiento es imperativo, estás haciendo las cosas paso a paso. Con FRP, dices “un flujo de nombres de usuario se crea a partir del flujo de userIds aplicando estos dos pasos de transformación “. Cuando tenga un flujo de nombres de usuario, sin importar su procedencia, y diga” siempre que haya un nuevo nombre de usuario, muéstrelo al usuario “.
El estilo de codificación FRP lo guiará para modelar su problema como un flujo de valores (es decir, valores que cambian con el tiempo) y las relaciones entre estos valores. Si ya conoce Promises, la curva de aprendizaje inicial será un poco más fácil, pero el beneficio principal se obtiene solo cuando comienza a pensar y modelar el problema de manera diferente: es posible (si no muy útil) hacer programación imperativa con bibliotecas FRP.
La diferencia está principalmente relacionada con cómo tú “configuras” (o declaras) la convención de las cosas: lo que le sucede a algo cuando sucede algo diferente.
En la programación reactiva, declarar a reacción a un cambio. No tiene que prever esta reacción necesaria a ese cambio por adelantado, puede agregar: declarar – esta reacción en cualquier momento después. Por lo tanto, podría considerarse una estrategia de “atracción” o “vigilancia”.
Por lo tanto, en programación reactiva, usted conectar para / mirar datos que sabes que existe. Los datos son cruciales aquí.
Ejemplo: un usuario hizo clic en un elemento de la página -> actualizar el contador de cuántos clics hizo el usuario.
Ejemplo de aplicación de calculadora: la pantalla de la calculadora está vinculada a todos los botones y reacciona con cualquier cambio (clics en los botones) con su propio cambio en la pantalla. Los botones no saben que sus clics pueden ser utilizados por otras partes.
En la programación impulsada por eventos, desencadenar un evento en cierto situación en el código escrito imperativo. Debe ser explícito por adelantado aquí, porque el evento debe activarse primero para ser recibido más tarde, porque básicamente usted empujar el evento en la parte del código de “cambio que está sucediendo”. Por tanto, es una estrategia de “empuje”.
Por lo tanto, en la programación impulsada por eventos, usted empujar un evento en un cierta situación ese quizás sería recibido por algunas otras partes del código. La situación es importante aquí, los datos no importan.
Ejemplo: alguien ha visitado la página de contacto -> desencadena un evento (que podría no ser recibido al final por ningún oyente, que es el caso típico de muchos módulos y bibliotecas).
Ejemplo de aplicación de calculadora: la pantalla de la calculadora es solo un oyente y los botones activan eventos. Botones necesitar saber que existen en un contexto determinado (pero, gracias al patrón de escucha de eventos, no es necesario saber qué es exactamente ese contexto) y, por lo tanto, se requieren para desencadenar un evento.
Entonces, en la mayoría, son solo convenciones diferentes. Mira este sencillo ejemplo. El ejemplo del enfoque imperativo:
event: perform some operation on a, e.g. a += value, and trigger the event
listener: counter++
Y el ejemplo del enfoque declarativo reactivo:
counter: whenever an operation on a occurs, react with this: counter++
En el último ejemplo, no es necesario activar nada, simplemente “conecta” con un reacción a cualquier cosa que pueda suceder.
Puede decir, entonces, que la reacción está destinada a a en el enfoque reactivo, mientras que en el enfoque imperativo impulsado por eventos, empuja un evento que puede ser recibido más tarde por un oyente, y dado que este tipo de enfoque no está relacionado de ninguna manera con los datos, puede cambiar esto: a += value a cualquier otra cosa más tarde, incluso quitando a completamente. El enfoque impulsado por eventos no tiene nada que ver esencialmente con los datos.
Entonces, como puede ver, la programación reactiva está orientada a los datos (el cambio en los datos reacciona con la activación de otro código), mientras que la programación impulsada por eventos está orientada a los procesos (no importa si los datos cambian y qué, si los hay, simplemente activa un evento que sería recibido por algunas otras partes del código). En el último caso, debe saber que se requiere esta “información” a las otras partes del código, y luego debe prever que el evento debe activarse. En el primer caso, no tienes que hacer eso, puedes hacerlo en cualquier momento, o no hacerlo en absoluto, no se requieren eventos de activación, pero el truco aquí es que debe haber “algo” a lo que puedas conectarte. su declaración de reacción, tipo de observadores que le permiten reaccionar a los cambios observados.
Al final de todo puedes encontrar las observaciones de otros sys admins, tú incluso puedes dejar el tuyo si dominas el tema.