¿Existe una regla práctica para decidir cuándo usar trigger o triggerMethod en Backbone.Marionette?

Estoy jugando un poco con Backbone.js y Backbone.Marionette y me gustaría saber cuál es la diferencia entre trigger y triggerMethod .

En particular, ¿hay alguna regla práctica para decidir cuándo utilizar el primero o el segundo?

En mi mente, los events, por ejemplo, son útiles para comunicarme entre un elemento DOM y su vista.

triggerMethod se usa en Marionette para actualizar en cascada diferentes componentes, por ejemplo, un layout llama al método show para sus hijos (los niños responden a onShow ). Entonces, para mí es lo mismo que llamar un método directo sobre eso. ¿Es esto cierto?

¿Qué hay del trigger ?

Gracias de antemano.

2 Solutions collect form web for “¿Existe una regla práctica para decidir cuándo usar trigger o triggerMethod en Backbone.Marionette?”

No hay una gran diferencia, y simplemente depende de lo que quieras hacer …

Obviamente, si solo quieres desencadenar un evento, usarás el trigger . Pero al utilizar el trigger , también crea una implementación de método de trigger "casera": trigger el evento y luego tiene un oyente que llamará a la function que desee.

Entonces, ¿qué pasa con triggerMethod ? Como se mencionó anteriormente, activará un evento y llamará a un método. Entonces, si su único objective es llamar al método en primer lugar, no necesariamente es necesario usar el triggerMethod .

Entonces, ¿por qué uno usaría triggerMethod en absoluto? Porque le da "ganchos" para agregar funcionalidad con los detectores de events. En mi libro sobre Marionette , por ejemplo, hay una llamada a triggerMethod en https://github.com/davidsulc/marionette-gentle-introduction/blob/master/assets/js/apps/contacts/edit/edit_controller.js#L24 para mostrar posts de error en un formulario. Lo mismo podría lograrse simplemente llamando

 view.onFormDataInvalid(contact.validationError); 

Pero como se mencionó anteriormente, triggerMethod nos da un "gancho" para un uso posterior. Por ejemplo, digamos que quiero agregar el logging de errores de usuario: simplemente puedo agregar un oyente a mi vista:

 initialize: function(){ this.on("form:data:invalid", function(validationError){ // log error here } } 

Esta funcionalidad adicional se puede agregar sin afectar el rest del código, porque hemos utilizado triggerMethod lugar de una llamada directa al método. Además, será más fácil realizar la testing más tarde (testings pequeñas, con punto único de falla):

  • testing que el evento "form: data: invalid" se active cuando un usuario ingrese información incorrecta
  • testing que cuando se desencadena el evento "form: data: invalid", se registra el error
  • etc.

trigger(name)

  • Parte de Backbone.js
  • Desencadena evento utilizando el nombre pasado

triggerMethod(name)

  • Parte de Marionnete.js
  • Todo lo que trigger(name) hace
  • También llama a methods que usan una convención de nomenclatura pnetworkingefinida.

    p.ej. triggerMethod('foo') llamará a onFoo()

    p.ej. triggerMethod('foo:bar') llamará a onFooBar()

  • Backbone.Radio: ¿cuál es la ventaja de los commands y requestes sobre events
  • Marionette.js ItemView: vista de elementos secundarios en la región
  • Routing.navigate vs document.location.hash
  • Marionette.js CollectionView, solo renderiza models específicos
  • Cambiar plantilla Marionette ItemView dinámicamente
  • Hacer un model global para backbone.marionette
  • Cómo agregar una opción de eliminación personalizada para las filas de la cuadrícula
  • Encuadernación a artículoVer el cambio Eventos
  • Integrando iCanHaz y Marionette
  • Cómo mostrar el icono de acción de edición cuando se pasa el mouse sobre un text en particular
  • Marionette - Relaciones entre la aplicación y el module
  • Vista de colección de marionetas, recuperar colección no desencadena events
  • Llama a una función en otra Marioneta.ItemView
  • Javascript tiene muchos buenos JS marco (como Node.js AngularJS Vue.js React.js) es el mejor lenguaje de script.