Cómo manejar la aplicación de UI State para una sola página con columna vertebral

Question

Tener conmigo mientras vengo de un fondo de desarrollo web tradicional, usando ASP.NET e incluso MVC del lado del servidor. Estoy intentando crear una aplicación de página única altamente interactiva usando Backbone.js para ayudar a organizar mi código JavaScript y crear la interfaz de usuario.

Tengo problemas con algunos conceptos o enfoques para construir los componentes de mi interfaz de usuario y decidir cómo manejar ciertos aspectos. Voy a utilizar esta captura de pantalla supuesta en exceso como base para mis preguntas y discusión.

Usemos una aplicación de "tareas pendientes" como ejemplo (por supuesto). La interfaz de usuario es bastante simple. Tengo los siguientes "componentes" ...

• Una lista de resultados que muestra el conjunto actual de tareas pendientes que coinciden con los criterios seleccionados actualmente
• Una lista de mis listas de tareas (proyecto personal, trabajo, blog)
• Una lista de filtros de fecha de vencimiento (hoy, mañana, esta semana, la próxima semana)
• Una lista de etiquetas (error, función, idea, seguimiento)
• Un cuadro de búsqueda

Funcionalidad deseada

• Actualice los resultados cada vez que cambie cualquiera de los criterios de búsqueda (elija una lista, elija Datos de Due, elija una o más etiquetas, ingrese el texto de búsqueda, etc.)
• El usuario puede editar, agregar y eliminar listas. (realmente no se muestra en este simulacro)
• El usuario puede editar, agregar y eliminar etiquetas. (realmente no se muestra en este simulacro)
• El usuario puede editar, agregar y eliminar elementos de tareas pendientes. (realmente no se muestra en este simulacro)

Modelos de datos

Hay varios modelos que identifiqué que están relacionados con "datos". Estos fueron fáciles de identificar.

• TODO (representa un solo elemento de tareas pendientes)
• Todocollection (representa una colección de elementos de tareas pendientes)
• Todolista (representa una sola lista de tareas pendientes)
• TodolistCollection (representa una colección de listas de tareas pendientes)
• Etiqueta (representa una sola etiqueta)
• TagCollection (representa una colección de etiquetas)

¿Cómo almacenar la interfaz de usuario?

Aquí es donde tengo problemas. Quiero mostrar qué artículos en mis menús (en el lado izquierdo) se seleccionan actualmente. Ciertamente puedo escuchar eventos y agregar una clase "seleccionada" a los elementos tal como se seleccionan, pero también tengo reglas, como "Solo se puede seleccionar una lista a la vez", pero "cualquier número de etiquetas" se puede seleccionar en un momento. Además, debido a que el menú de la lista de tareas y el menú Etiquetas son dinámicos, ya están asociados con los modelos TodolistCollection y TagCollection ya. Se representan de acuerdo con el estado de estos "modelos de datos".

Entonces, ¿cómo manejo la gestión de este estado de la interfaz de usuario para todas estas vistas diferentes con la troncal? Aprecio cualquier idea o sugerencia.

¡Gracias!

Answer 1

Tenía exactamente la pregunta que hiciste, y te haré saber el secreto: trampa.

Lo que tienes aquí son dos capas de aplicación diferentes y cierta confusión sobre ellas. La primera capa es la relación entre los objetos de tareas pendientes en su sistema. Estos, almacena en un modelo relacional de objetos tradicional, y los crea/recupera/actualiza/elimina como lo haría con cualquier otra aplicación RESTFUL.

La segunda capa es la relación entre su visualización de estos objetos y los objetos mismos. Hay algún estado que quieres preservar. Aquí está la visión importante: siempre que cada objeto obtenga, se publique o publique en el sistema que tenga una identificación única, la segunda capa puede ser completamente independiente de la primera.

La primera capa es una API reparadora para "un administrador de tareas pendientes". El segundo es algo único para esta presentación. Su relación con los datos en el primero es tenue. Así que esto es lo que hice: codicé ese estado de la capa de presentación en un objeto JSON y lo escribí en un campo de texto limpio de 8 bits en el perfil del usuario. Cada vez que el usuario cambia, lo hago.

Cuando la aplicación se carga, carga la mayor parte de los datos de la API REST y la información de la capa de presentación, descarta cualquiera en la capa de presentación que no tenga sentido, y luego inicia backbone.history e inicializa la presentación. Y el servidor no necesita saber ningún Detalles sobre cómo funciona el cliente. Mientras el cliente hable su jerga reparadora, puede guardar "cosas misceláneas a este cliente en particular le importa" a ese campo de texto sin afectar sus objetos o su relación.