¿Cómo se usa la programación reactiva funcional para aplicaciones web?

El “póster secundario” de FRP en la programación web parece completarse automáticamente:

http://jsfiddle.net/36b20tkp/

var $input = $('#textInput'), $results = $('#results'); // Only get the value from each key up var keyups = Rx.Observable.fromEvent($input, 'keyup') .map(function (e) { return e.target.value; }) .filter(function (text) { return text.length > 2; }); // Now debounce the input for 500ms var debounced = keyups.debounce(500 /* ms */ ); // Now get only distinct values, so we eliminate the arrows and other control characters var distinct = debounced.distinctUntilChanged(); // Get suggestions, automatically cancelling old requests var suggestions = distinct.flatMapLatest(searchWikipedia); // Render suggestions.forEach( function (data) { $results.empty() .append($.map(data[1], function (value) { return $('
  • ').text(value); })); }, function (error) { $results.empty() .append($('
  • ')) .text('Error:' + error); } );
  • El motivo es que muestra la orquestación de los eventos de la interfaz de usuario y las solicitudes asíncronas del servidor. Escuché que FRP también es bueno con la animación; Como probablemente pueda imaginar, los eventos de IU, las solicitudes asíncronas y la animación se utilizan ampliamente en los clientes de aplicaciones web. FRP también es útil en el lado del servidor, donde los flujos son conexiones de clientes con datos que provienen de ellos y se les envían en tiempo real.

    La principal diferencia entre el ejemplo anterior y cualquier solución simple que se te ocurra sin FRP es que:

    • Será correcto: cancelará automáticamente las solicitudes antiguas que podrían haber viajado durante más tiempo, evitando el error donde una respuesta tardía podría reemplazar los resultados actuales (ya que el usuario ha seguido escribiendo y ya tiene una palabra más larga). La cancelación de la suscripción a eventos también es automática, por lo que no debe preocuparse por las pérdidas de memoria al olvidarse de cancelar la suscripción de los controladores de eventos (aunque este ejemplo no lo necesita).
    • No afectará a su servidor: no enviará una solicitud por pulsación de tecla, pero esperará a que el usuario disminuya la velocidad. Esto se llama rebote: de EE, donde la pieza conductora de metal en un botón rebotará físicamente un poco antes de hacer contacto total.
    • Aún será más fácil de entender que un montón de devoluciones de llamada, incluso si usa promesas. Aparentemente, FRP promete qué listas y matrices tienen valores escalares.

    Aquí hay un video que habla sobre cómo se usa RxJS para la aplicación web de Netflix y Cortana de Microsoft: Bart De Smet, Jafar Hussain, Matthew Podwysocki: Pragmatic Rx (Canal 9)

    FRP debe considerarse como no diferente a un bucle. En un bucle, hay una cantidad de cosas que pueden suceder y para las cuales se deben probar. Puede imaginar que está programando un juego o una aplicación comercial.

    En un juego, las cosas que suceden a menudo están relacionadas con el paso del tiempo. Por ejemplo, si tu personaje baja de una plataforma, la velocidad funcionará para acelerar su descenso hasta que aterrice en una plataforma más baja. Si bien la gravedad no desencadena ningún evento, su fuerza se siente y se tiene en cuenta en cada cuadro (estamos hablando de cuadros por segundo).

    En una aplicación comercial, las cosas que suceden generalmente no están relacionadas con el paso del tiempo. En cambio, están relacionados con lo que está haciendo el usuario. ¿Dónde está el cursor en la pantalla? ¿El usuario está escribiendo? ¿Qué teclas está presionando? ¿Ha hecho clic en un botón? La actividad del usuario es la fuente de donde fluyen los eventos interesantes.

    En ambas situaciones, un juego o una aplicación, están sucediendo cosas que deben ser monitoreadas y manejadas. Todo esto podría suceder en el contexto de nuestro ciclo principal donde constantemente estamos probando condiciones para identificar lo que está sucediendo. Normalmente llamaremos a ciertas funciones en respuesta a esos acontecimientos. En lugar de limitarnos a programar dentro de un ciclo, puede ser útil invertir el ciclo y pasar mensajes a un contexto separado. Dentro de ese contexto llamamos a estos mensajes eventos, nos suscribimos a ellos y los manejamos cuando llegan. El bucle todavía existe, estamos justo afuera de él.

    La programación reactiva no está muy lejos de la programación ordinaria basada en eventos. La principal diferencia es que tratamos los eventos (o más bien los valores directamente relacionados con ellos) como ciudadanos de primera clase. Estos valores se emiten a medida que ocurren eventos o a medida que avanza el tiempo. Llamamos a estos valores emitidos una señal. A medida que se emite la señal, enrutamos su valor por otros canales (de nuestro propio diseño) generalmente transformando (mapeando) o filtrando los valores de alguna manera. Esencialmente, estamos canalizando valores a lo largo de una red de mangueras contra incendios y utilizando esas mangueras como canales de comunicación y reaccionando a lo que está saliendo. De vuelta en la fuente original, todavía tenemos un bucle y todavía estamos probando ciertas condiciones. Nada de eso ha cambiado ni un ápice. Todo lo que ha cambiado es que hemos invertido la estructura de control. Hemos cruzado un enrutador con un bucle de eventos.

    No hay nada sobre FRP que uno no pueda hacer en un ciclo típico; lo que cambia es el estilo por el cual se hace. No hay nada sobre esto que sea específico de la web. La web es solo una plataforma como el escritorio. Ambas situaciones pueden aprovechar FRP. El contexto web es irrelevante. Lo relevante son las necesidades de su programa. ¿Qué cosas interesantes están pasando que necesitan ser manejadas? ¿Cómo quieres manejarlos? Probablemente no escribirás tu propio bucle, pero podrías. Probablemente comenzaría manejando eventos. Si decide que tiene sentido, puede comenzar a enrutar esos eventos y transformarlos para definir nuevos tipos de eventos. En última instancia, está componiendo una aplicación a partir de eventos.

    FRP proporciona un mecanismo por el cual los eventos se pueden componer en otros tipos de eventos. Eso es todo. Lo que lo hace funcional es su enfoque en el mapeo, el filtrado y la cartografía para construir redes de eventos a partir de eventos como objetos de datos. Ofrece un estilo por el cual tanto los juegos como las aplicaciones se pueden construir en la web o en otro lugar. Lo único significativo de los juegos es que el tiempo es de primera clase y un temporizador actúa como una fuente desde la cual el paso del tiempo fluye a través del programa como una serie de eventos. En una aplicación comercial, la fuente de tiempo se omitirá porque no es relevante para ese modelo de programación.

    React.js está ligeramente inspirado en FRP.

    Facebook lo está usando por todas partes.