Enfoque Backbone.js para administrar las selecciones de estado/manejo de UI en la IU

Question

Mi pregunta se refiere a esta muestra de IU.

Tiene problemas con el enfoque de la gestión del estado "seleccionado" de varios componentes de vista de interfaz de usuario. Por ejemplo, tengo menús arriba, desde los cuales el usuario hace varias selecciones. Estas selecciones deberían causar actualizaciones en los menús (elementos HL seleccionados) y también provocar actualizaciones en los resultados, que se basarían en las selecciones realizadas. Además, los menús tienen diferentes tipos de reglas. Por ejemplo, solo puede tener una "lista" seleccionada a la vez, pero puede tener varias "etiquetas" seleccionadas.

Un enfoque en el que estaba pensando era crear un modelo de Backbone que tenga el estado de la "selección" de UI. Por ejemplo, podría tener un modelo SearchCriteria que contenga esta información. Entonces, cuando un usuario hace elecciones en la interfaz de usuario, podría actualizar este modelo. Podría hacer que los diversos componentes de vista escuchen los cambios en este modelo (así como los cambios en los modelos de datos primarios). Luego, las vistas actualizarían su estado visual al actualizar qué elementos se muestran como seleccionados.

Un elemento con el que estoy luchando en este enfoque es quién debería ser responsable de actualizar el estado seleccionado de un artículo. Por ejemplo, en la lista de etiquetas, que podría tener las siguientes piezas definidas ...

• Tag (modelo para representar una etiqueta)
• TagCollection (colección para representar una colección de etiquetas)
• TagMenuView (vista que representa el menú de etiquetas disponibles para seleccionar)
• TagMenuItemView (vista que representa un solo elemento en el menú)

¿Debo ...

• Configure un detector de eventos en TagMenuItemView para hacer clic, y luego intente manejar 1) actualizar el modelo de SearchCriteria, y 2) actualizar el estado visual del menú, p. artículos seleccionados?
• ¿O debería tener la vista de nivel superior (el TagMenuView) para detectar eventos como que el usuario seleccione una etiqueta y realizar el trabajo allí?
• Además, el menú de etiquetas en este ejemplo permite que se seleccionen varios elementos, pero el menú de listas solo permite seleccionar una lista a la vez. ¿Dónde se aplicaría esta regla de "IU" (¿o se trata realmente de una regla de negocios relacionada con una búsqueda?). Por ejemplo, si escuché eventos de clics en cada elemento de menú de la lista individual, ciertamente podría actualizar el estado visual de ese elemento, pero también debo asegurarme de que la vista de menú de nivel superior deseleccione cualquier otra lista seleccionada. Entonces, ¿sería mejor administrar el estado "UI" de algo así como el menú de la lista de tareas en la vista que representaría ese menú completo (un ToDoListMenuView) en lugar de en cada vista de elemento de menú individual?

Lo siento por tantas preguntas. Solo me está costando pasar a este modelo de desarrollo.

Answer 1

Estás a punto de obtener una respuesta similar a la que usaría.

Si usted aprecia que list, search, y duetags son filtros de búsqueda en una gran colección de tareas pendientes, que son el 90% del camino hacia la iluminación.De hecho, aparte de search, ¡todos esos son solo "tipos de etiquetas"! (A menos que tengas 10.000 elementos pendientes, no hay motivos de rendimiento o relacionados con la memoria para tener listas de listas de tareas pendientes; "Trabajo", "Proyecto n.º 1" y "Personal" son solo etiquetas especializadas por las que filtre los elementos fuera de su vista, mostrando solo los relacionados con una esfera de su vida u otra).

Cree el modelo de SearchCriteria. (No está buscando técnicamente, está filtrando: excluye de su vista las cosas que no coinciden con sus criterios de búsqueda). Este modelo tendrá muchos atributos sobre el estado de su cliente. Sus criterios de búsqueda dependen casi por completo de los datos presentes en el cliente (ya que la búsqueda se aplica solo a una ToDoList a la vez), por lo que está relacionada completamente con el SearchCriteria, no con el objeto ToDo.

Todas las vistas se unen para cambiar/agregar/eliminar eventos en SearchCriteria. Cuando el usuario hace clic en cualquiera de las vistas (lista, vista, etiqueta), ese mensaje se reenvía a SearchCriteria. Realiza los cambios internos apropiados, lo que a su vez activa las vistas para que se vuelvan a renderizar. Uno de los destinatarios del evento en ToDoListView principal, que durante su procesamiento verifica los criterios de búsqueda. Algo así como:

ToDoListView = Backbone.View.extend({ 
... 
render: function() { 
    var self = this, 
    toDraw = this.collection.filter(
     function(c) { return this.searchCriteria.passes(c); }); 
    $(this.el).html(''); 
    _.each(toDraw, function(c) { 
     (new ToDoItemView({model: c, parent: self})).render(); }); 
} 

que pueden ser un poco personalmente idiomática, pasando el objeto padre y dejar que el elemento insertarse en objeto DOM de los padres. Podrías pasar algo: el elemento al que se agregará. Alternativamente, el render puede devolver un objeto DOM y el ListView podría agregarse. Esa es una cuestión de gusto. He hecho ambas cosas.

Usted tiene que cavar un poco en la biblioteca principal de la red troncal, guión bajo, para asimilar la maravilla esencial del uso de _.each().

Además, a menudo he contenido una aplicación Backbone completa en una función anónima autoejecutable y dejando "searchCriteria" como una variable accesible para todos los objetos dentro del alcance de la SEAF, por lo que no sería this.searchCriteria, pero solo searchCriteria.

También puede escribir SearchCriteria para que llame a la sincronización, escribiendo el estado del evento en el servidor, que luego puede guardar como un objeto JSON sin formato; Lo bueno de la sincronización es que si lo que envías y lo que recibes es igual, no se desencadenan eventos, por lo que no obtienes un efecto de doble procesamiento, y lo bueno de usar JSON es que es apropiado para el cliente, pero no contiene nada de lo que se preocupen las relaciones de ToDo del servidor.

Además, puede especificar reglas de comportamiento específicas del lado del cliente. Por ejemplo: cuando cambia las listas de tareas pendientes, puede aplicar los criterios de búsqueda de texto o, como alternativa, puede decidir que el cambio de listas borre el campo de criterios de búsqueda de texto; al hacerlo se desencadenará un evento que hará que "TextSearchView" borre su casilla de entrada (tendrá que escribir ese controlador de eventos, pero será obvio que pretendía hacer eso). Puede inventar cualquier regla que desee, como "cambiar listas borra todas las selecciones", pero eso no parece sensato. Me puedo imaginar fácilmente tratando de resolver los errores en mi lista de "proyectos" y en mi vida personal. Pero borrar el cuadro de búsqueda parecía más ... sensato, si sabes a qué me refiero.