backbone.js - significado - backbone translate
¿Por qué se considera una mala práctica llamar a trigger: verdadero en la función de navegación de backbone.js? (4)
He leído en varios lugares que llamar a Backbone.history.navigate es una mala práctica.
Por ejemplo, Addy Osmani sais en su libro "Developing Backbone.js Applications"
También es posible que Router.navigate () active la ruta junto con la actualización del fragmento de URL pasando la opción trigger: true. Nota: este uso no se recomienda ...
http://addyosmani.github.io/backbone-fundamentals/#backbone.history
O Derick Bailey en su blog incluso dice:
No debe ejecutar el controlador de la ruta desde su aplicación la mayor parte del tiempo.
Pero realmente no entiendo el razonamiento detrás de eso y cuál sería la mejor solución.
En mi opinión, no es realmente malo llamar a la función de navegación con la opción trigger: true. La función de ruta podría al momento de la llamada verificar siempre si los datos considerados ya están cargados y mostrar estos datos cargados en lugar de hacer todo el trabajo de nuevo ...
Depende de tu contexto.
Si ha hecho algo en su vista actual que podría afectar la vista a la que está a punto de navegar, por ejemplo, crear para eliminar un registro de cliente, entonces establecer el activador en verdadero es lo correcto.
Piénsalo. Si elimina un registro de cliente, ¿no desea actualizar la lista de clientes para reflejar esa eliminación?
En mi opinión, se considera una mala práctica porque debería imaginar una aplicación Backbone no como una aplicación Ruby On Rails, sino más bien como una aplicación de escritorio.
Cuando digo RoR, solo estoy diciendo un marco que admite el enrutamiento en el sentido de que una ruta te lleva a una llamada específica al controlador para ejecutar una acción específica (imagina una operación CRUD).
Backbone.history es solo un marcador para el usuario, por lo que puede, por ejemplo, guardar una url específica y volver a ejecutarla más tarde. En este caso, encontrará la misma situación que dejó antes.
Cuando tu dices:
En mi opinión, no es realmente malo llamar a la función de navegación con la opción trigger: true. La función de ruta podría al momento de la llamada verificar siempre si los datos considerados ya están cargados y mostrar estos datos cargados en lugar de hacer todo el trabajo de nuevo ...
Eso para mí suena maloliente. Si está activando una ruta y está revisando los datos para ver si la tiene, significa que ya los tenía, por lo que debe cambiar su vista según corresponda sin volver a cargar todo el DOM con los mismos datos.
Dicho trigger:true es que tenemos razón para usarlo? En mi opinión, es posible usarlo si está intercambiando completamente una vista.
Digamos que tengo una aplicación con dos pestañas, una me permite crear un único recurso y la otra me permite ver la lista de recursos creados. En las segundas pestañas, en realidad estás cargando una Colección para que los datos sean diferentes entre los dos. En este caso usaría trigger:true .
Dicho esto, he estado usando Backbone durante 2 semanas, así que soy bastante nuevo en este mundo, pero a mí me parece razonable desalentar el uso de esta opción.
Tengo que estar en desacuerdo con la respuesta de @ Stephen aquí. Y la razón principal es porque el uso de router.navigate({trigger : true}) le da al enrutador la responsabilidad de manejar el estado de la aplicación. Solo debe reflejar el estado de la aplicación, no controlarla.
Además, no es responsabilidad de View el cambiar el hash de la ventana, ¡este es el único trabajo del enrutador! ¡No te lo quites! Una buena modularidad y separación de preocupaciones hace que la aplicación sea escalable y mantenible.
Reenviar a una persona a una nueva sección dentro de su aplicación
Backbone es un marco impulsado por eventos , usa eventos para comunicarse. No hay necesidad de llamar a router.navigate({ trigger : true }) ya que la funcionalidad no debe estar en el enrutador. Aquí hay un ejemplo de cómo uso el enrutador y creo que promueve una buena modularidad y separación de preocupaciones.
var Router = Backbone.Router.extend({
initialize: function(app) {
this.app = app;
},
routes: {
''videoLibrary'' : function() { this.app.videoLibrary(); }
}
});
var Application = _.extend({}, Backbone.Events, {
initialize: function() {
this.router = new Router( this );
this.listenTo( Backbone, ''video:uploaded'', function() {
this.router.navigate(''/videoLibrary'');
this.videoLibrary();
});
},
videoLibrary: function() {
//do useful stuff
}
});
var uploadView = Backbone.View.extend({
//...
uploadVideo: function() {
$.ajax({
//...
success: function() { Backbone.trigger(''video:uploaded''); }
});
}
});
Su vista no necesita o no quiere saber qué hacer cuando el usuario termine de cargar, esta es responsabilidad de otra persona. En este ejemplo, el enrutador es solo un punto de entrada para la funcionalidad de la aplicación, un evento generado por el uploadView es otro. El enrutador siempre refleja el estado de la aplicación a través de los cambios de hash y el historial, pero no implementa ninguna funcionalidad.
Testabilidad
Al separar las preocupaciones, está mejorando la capacidad de prueba de su aplicación. Es fácil tener un espía en Backbone.trigger y asegurarse de que la vista funcione correctamente. Es menos fácil burlarse de un enrutador.
Gestión de módulos
Además, si utiliza alguna gestión de módulos como AMD o CommonJS, tendrá que pasar por la instancia del enrutador en todas partes de la aplicación para llamarla. Por lo tanto, tener un acoplamiento cercano en su aplicación y esto no es algo que desee.
Parece que hay cierta confusión acerca de qué Router#navigate hace exactamente, creo.
Sin ninguna opción configurada, actualizará la URL al fragmento provisto. Por ejemplo, router.navigate(''todo/4/edit'') actualizará la URL a #todo/4 Y creará una entrada en el historial del navegador para esa URL. No se ejecutan manejadores de ruta .
Sin embargo, al establecer trigger:true se actualizará la URL, pero también se ejecutará el controlador que se especificó para esa ruta (en el ejemplo de Addy llamará a la función editTodo los enrutadores) y se creará una entrada en el historial del navegador.
Al pasar replace:true la URL se actualizará, no se llamará a ningún controlador, pero NO creará una entrada en el historial del navegador .
Entonces, lo que creo que la respuesta es:
La razón por la cual se desaconseja el uso de trigger:true es simple, navegar desde el estado de la aplicación al estado de la aplicación al estado de la aplicación requiere la mayor parte del tiempo que se ejecute código diferente que cuando se navega a un estado de aplicación específico directamente.
Digamos que tiene los estados A, B y C en su aplicación. Pero el estado B se basa en el estado A y el estado C se basa en B. En ese caso, cuando navegas de B a C solo será necesario ejecutar una parte específica del código, mientras que al tocar directamente el estado C probablemente ejecutarás alguna comprobación y preparación del estado :
- ¿Han sido cargados esos datos? Si no, cárgalo.
- es el usuario conectado? Si no es redirigido
etc.
Tomemos un ejemplo: State A ( #list ) muestra una lista de canciones. El estado B ( #login ) trata sobre la autenticación del usuario y el estado C ( #list/edit ) permite la edición de la lista de canciones.
Entonces, cuando el usuario aterriza en el estado A, la lista de canciones se carga y almacena en una colección. Hace clic en un botón de inicio de sesión y se le redirige a un formulario de inicio de sesión. Se autentica con éxito y se le redirige a la lista de canciones, pero esta vez con los botones eliminar al lado de las canciones.
Marca el último estado ( #list/edit ).
Ahora, ¿qué debe suceder cuando el usuario hace clic en el marcador unos días después? La aplicación necesita cargar las canciones, necesita verificar que el usuario está (aún) conectado y reaccionar en consecuencia, cosas que en el flujo de transición del estado ya se habían hecho en los otros estados.
Ahora para una nota mía:
Nunca recomendaría el enfoque anterior en una aplicación real como en el ejemplo. Debería verificar si la colección está cargada al pasar de B a C y no solo asumir que ya está. Del mismo modo, debe verificar si el usuario realmente está conectado. Es solo un ejemplo.
IMO, el enrutador es realmente un tipo especial de visualización (piénselo, muestra el estado de la aplicación y traduce la información del usuario al estado / eventos de la aplicación) y siempre debe tratarse como tal. Nunca debe confiar en que el enrutador haga la transición entre estados, sino que permita que el enrutador refleje las transiciones de estado.