Pregunta Angularjs pubsub vs $ broadcast


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

Blogs como este uno abogar por acostumbrarse a $ a pesar de que "parecía exagerado".

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.


32
2018-02-07 21:59


origen


Respuestas:


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

los $broadcast/$on El enfoque no requiere la cancelación de la suscripción, pero no es muy eficiente, ya que se 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.


18
2018-02-07 22:34



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 envolvió en un servicio angular.

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


2
2018-03-05 20:11