example event javascript angularjs publish-subscribe

javascript - event - Angularjs pubsub vs $ broadcast



rootscope emit vs broadcast (2)

Estaba viendo el mismo problema. Particularmente, cómo permitir que los servicios transmitan y se suscriban a eventos sin acceder $ rootScope (malo por algunas razones). Utilicé la excelente implementación de js-signals desde aquí: http://millermedeiros.github.io/js-signals/ y lo envolví en un servicio angular.

github gist aquí: https://gist.github.com/anonymous/b552c7fafa77427e6d06

He estado leyendo sobre el evento en Angularjs y no estoy convencido de que usar $ broadcast sea una buena idea.

Blogs como este abogan por acostumbrarse a $ a pesar de que "se sentía como un exceso".

Mi confusión es que la implementación utiliza un recorrido en profundidad de los ámbitos y busca suscriptores, lo que hace que la velocidad de sus eventos dependa de la estructura de su árbol. Aquí hay un código de eso en angular:

// Insanity Warning: scope depth-first traversal // yes, this code is a bit crazy, but it works and we have tests to prove it! // this piece should be kept in sync with the traversal in $digest if (!(next = (current.$$childHead || (current !== target && current.$$nextSibling)))) { while(current !== target && !(next = current.$$nextSibling)) { current = current.$parent; } }

Además, parece que sería capaz de hackear la inyección de dependencia utilizando estos métodos.

La alternativa es simplemente un servicio que almacena en caché tipos de eventos y devoluciones de llamada, y los llama directamente. Esto requiere que limpie las suscripciones para evitar fugas.

Mi pregunta es, ¿hay algo que me falta acerca de la motivación para el paradigma $ broadcast / $ on? ¿O hay algún beneficio de usarlo en un pubsub más tradicional?

Avíseme si no estoy siendo lo suficientemente claro con mi pregunta, y gracias por su tiempo.


No creo que te estés perdiendo nada. Ha descrito con éxito los pros / contras de cada enfoque.

El enfoque $broadcast / $on no requiere que se cancele la suscripción, pero no es terriblemente eficiente ya que transmite a todos los ámbitos. También tiene una barrera de entrada muy baja. No necesita inyectar ningún servicio, no necesita crearlos. Se transmiten a todos, por lo que es un enfoque más simple.

El enfoque de pub / sub es mucho más directo. Solo los suscriptores reciben los eventos, por lo que no va a todos los ámbitos del sistema para que funcione. Sin embargo, es más complejo porque necesita escribir su servicio con controladores de devolución de llamada, y debe recordar darse de baja. El recordar cancelar la suscripción es bastante grande en mi opinión. Si no lo haces bien, obtienes pérdidas de memoria. Y no lo sabrá hasta que sea un problema en 3 meses.

Puedo ver por qué el enfoque integrado es $broadcast .