¿Cuál es la ventaja de core.async en clojurescript?

Question

Todo el mundo está hablando de cuán grande es core.async, y cómo mejorará el manejo de eventos en clojurescript. He estado siguiendo el tutorial de ClojureScript 101 , y no veo ninguna ventaja clara en estos ejemplos de código. ¿Qué me estoy perdiendo?

¿Por qué el uso de core.async es mejor aquí?

(defn listen [el type]
  (let [out (chan)]
    (events/listen el type
      (fn [e] (put! out e)))
    out))

(defn dosomethingasync
  [e]
  (js/console.log "async: " e))

(let [clicks (listen (dom/getElement "search1") "click")]
  (go (while true (dosomethingasync (<! clicks)))))

contra

(defn dosomethingcallback
   [e]
   (js/console.log "callback: " e))

(events/listen (dom/getElement "search2") "click" dosomethingcallback)

Answer 1

Gran pregunta

Creo que tu primer paso para entender la ventaja sería Timothy Baldridge Video

Y debajo de mi intento:

Creo que las diferencias se aclararán si cambiamos un poco su código.

En primer lugar, tratar de resaltar la frase "En todos los buenos programas llega un momento en que los componentes o subsistemas deben dejar de comunicarse directamente entre sí" extraídos de la presentación de core.async publicada en el blog clojure . Creo que podemos separar el canal de eventos de entrada del let fn:

(def clicks (listen (dom/getElement "search1") "click"))

(go
  (while true
    (dosomethingasync (<! clicks))))

(put! clicks "this channel can be written from differents parts of your code")

En segundo lugar, con core.async podemos escribir llamadas asíncronas como escribiremos llamadas síncronas (código secuencial). Un ejemplo de esta situación requiere más de un canal:

(def clicks (listen (dom/getElement "search1") "click"))

(def keys-pressed (listen (dom/getElement "search1") "keypress"))

(def to-out (chan))

(go
  (while true
    (let [click-recieved (<! clicks)]
      (dosomethingasync click-recieved)
      (>! to-out "click recieved!")
      (let [other-input-waited (<! keys-pressed)]
        (dosomethingwithkey other-input-waited)
        (>! to-out "keypressed recieved!")
        )
      )
    ))

Y, por último, creo que no está utilizando correctamente el significado de la función de devolución de llamada. Cuando hablamos de una función de devolución de llamada, creo que nos estamos refiriendo a una función que, además de sus propios parámetros, recibe una función de "devolución de llamada". Al final de la ejecución de la función, llamamos a la función de devolución de llamada para devolver el flujo de ejecución al punto original. Cambiando su función de "devolución de llamada" aparece como sigue:

(defn dosomethingcallback
   [e call-back-fn]
   (js/console.log "callback: " e)
   (call-back-fn))

Y si intentamos emitir algo similar al mismo comportamiento logrado con el código anterior del ejemplo core.async:

(defn do-key
   [call-back-fn e]
   (.log js/console "before  callback key" )
   (call-back-fn e))

(defn do-click
   [call-back-fn e]
   (.log js/console "before callback click")
   (call-back-fn e))

(defn key-callback-fn [e]
  (.log js/console (str "doing some work with this key: " e))
  )

(defn click-callback-fn [e]
  (.log js/console (str "doing some work with this click" e))
  (events/listen (dom/getElement "search2") "keypress" (partial do-key key-callback-fn)))


  (events/listen (dom/getElement "search2") "click" (partial do-click click-callback-fn))