tutorial - En Backbone.js, ¿por qué los cambios silenciosos desencadenan cambios eventuales?
backbone vs react (2)
Cuando paso {"silent":true}
mientras establezco un atributo en un modelo Backbone, ¿por qué eso no suprime el evento change:attribute
? ¿Cuál es la ventaja de activar ese evento la próxima vez que se cambie un atributo?
Actualizar
Backbone 0.9.10 cambió el comportamiento de pasar { "silent": true }
. Desde el registro de cambios:
Pasar
{silent:true}
en el cambio ya no retrasará los eventos individuales "change: attr", sino que se silenciarán por completo.
Busque el registro de cambios here
En backbone 0.9.2, la función set
ejecuta la validación antes de actualizar cualquier cambio.
// Run validation.
if (!this._validate(attrs, options)) return false;
En caso de que se pase la opción {silent: true}
, el código de validación no se ejecutará.
if (options.silent || !this.validate) return true;
Eso significa que model.set({value: 100}, {silent: true});
puede establecer el valor "no válido" en el modelo, por lo que los atributos se actualizan, pero los eventos de cambio no se activan.
Es útil, luego desea actualizar algún campo e impedir la validación de modo completo, de modo que si el modelo aún no se ha completado, el cambio aún se propagó a los atributos. Pero normalmente también quiere que la vista muestre el cambio, por lo que debe llamar manualmente a model.change()
o model.trigger(''change:value'', model, value)
.
Esto también me ha confundido por algún tiempo.
La razón es que {silent: true} no significa "Haz todo de la manera normal, pero simplemente no desencadenas el evento".
De varios comentarios y respuestas de @jashkenas, lo que parece significar es "simplemente cambiar el valor del atributo (y agregarlo al hash ''changedAttributes''), pero diferir todas las demás actividades relacionadas con el cambio hasta más adelante".
"silencioso" no previene el evento de change
para esas / esas propiedades, simplemente pone en cola el "anuncio" hasta que se active el siguiente evento de change
.
Entonces, probablemente sea mejor nombrar algo como defer
.
Informacion relevante:
https://github.com/documentcloud/backbone/pull/850
el punto de un cambio "silencioso" es que no se considera un cambio desde el punto de vista de los modelos. Más tarde, cuando el cambio realmente ocurre, obtienes la diferencia total a la vez.
https://github.com/documentcloud/backbone/issues/870
Porque el punto de los cambios silenciosos es que se le permite interactuar con el estado interno de su modelo, temporalmente, sin realmente hacer un cambio. Más tarde, cuando el atributo realmente cambia, la validación se ejecuta y se emiten los eventos. No tendría sentido emitir un evento de error al hacer un cambio silencioso.
Actualización 4/7/2013
Nota: No he probado esto para confirmar el comportamiento, esto solo se basa en mi lectura de las notas de la versión ...
A partir de Backbone 0.9.10, el comportamiento descrito anteriormente ha cambiado. En esa versión (y más reciente), silent:true
suprime el change:attr
eventos change:attr
completo, no solo los retrasa.