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 .