Backbone: History.navigate debería permitir la configuración del objeto de estado

Me temo que no estoy de acuerdo, pero intente persuadirme de lo contrario.

El objetivo de la API de historial es proporcionar URL que se pueden marcar y compartir, a las que puede volver a navegar. Si adjunta un objeto de historial con la API, la página a la que regresa _no_ es la misma que la página que vería si pegara la URL idéntica. Esto parece roto ... y al menos redundante con su capacidad para almacenar estados arbitrarios en JS durante el curso de una sesión de navegador.

Huele como una API en la que los implementadores del navegador pensaron, "caramba, no sería genial si pudieras ...", y no consideraron las consecuencias reales.

Creo que está haciendo suposiciones sobre el comportamiento deseable de la aplicación y también sobre la granularidad de los eventos del historial que son más restrictivos de lo que proporciona la API del navegador. Específicamente, no hay ninguna razón por la que deba depender del marco y no de la aplicación para dictar el comportamiento cuando se invoca con un URI. Parece perfecta y obviamente legítimo que exista un estado (dado por la ruta de navegación) que sea ortogonal al recurso (y al estado codificado) identificado por el URI, y que la presentación esté condicionada a ambos. Claramente, esa elección debe depender de la aplicación individual.

Aparte de ese argumento abstracto, dígame, ¿cómo implementaría, por ejemplo, un formulario de entrada que se pueda marcar como favorito que ofrezca guardar / descartar cambios cuando se navegue fuera de (incluso con el botón Atrás) usando la API de historial?

Este es un cambio de una o dos líneas. Si no desea agregar un parámetro a History.navigate , también se puede usar el estado dado a través de, por ejemplo, un atributo o función currentState .

dime cómo implementaría, por ejemplo, un formulario de entrada que se pueda marcar como favorito
que ofrece guardar / descartar cambios cuando se navega fuera de (incluido
con el botón Atrás) usando la API de historial?

Simplemente almacenaría los cambios de formulario en un lugar diferente y más seguro: en la sesión, en el servidor, en el almacenamiento local ...

Tenía curiosidad sobre lo que pensaba la gente de este puesto, así que pregunté:

https://twitter.com/jashkenas/status/142736117895151616

Y aquí están algunas de las respuestas:

https://twitter.com/juandopazo/status/142737949178601472

https://twitter.com/yaypie/status/142737982879842304

https://twitter.com/fortes/status/142742305877659648

https://twitter.com/dyakovlev/status/142743995020349441

https://twitter.com/bassistance/status/142882410982420481

La API de historial se ocupa específicamente del estado de la aplicación vinculado a la ruta de navegación, distinto del URI. Es decir, "¿Cómo llegamos aquí?" Quizás debería llamarse Hysterisis API. Es posible que compartamos el mismo URI y estemos en la misma 'página' pero no en la misma vista / página / estado de retorno cuando presiono el botón Atrás en el mouse o deslizo hacia atrás en su móvil. Y esa acción de retroceso puede cambiar el estado / historial de la aplicación sin cambiar el URI. No todas las transiciones de navegación son transiciones de URI. Entonces, cuando compartimos un URI, puede llevar a presentar el mismo recurso o 'página' pero no el mismo estado de navegación.

Si bien aprecio la experiencia de su rebaño, creo que solo demuestra que la mayoría de los desarrolladores aún no han descubierto cómo usar la API según lo previsto por los creadores. Esa no es una buena razón para que el marco lo pavimente.

Además, no abordó la pregunta, que no era cómo conservar los valores del formulario, sino más bien cómo usar la API push / popState para solicitar al usuario que guarde los cambios, si los hay, cuando presionan el botón Atrás para navegar. fuera del formulario con el URI que se puede marcar como favorito. Considere abordar eso.

Soy muy nuevo en Backbone y WebDev en general, sin embargo, estoy de acuerdo con tribalvibes.

Quiero crear una aplicación web basada en la API Graph de Facebook y usar la función de navegación de Backbone para permitir que el usuario regrese a diferentes elementos para ver, similar a lo que hace Facebook en este momento. Sin embargo, sin el objeto de estado en pushState, el usuario tiene que volver a cargar el elemento desde la API, lo que obviamente es costoso.

Probablemente se deba a que no sé cuál es el patrón común para este problema, pero creo que tener un objeto de estado para esto sería muy útil.

Según la documentación de MDN, el objeto de estado se guarda en el disco. No entiendo en qué se diferencia de guardar en el almacenamiento local. Creo que esto debería corregirse. El uso de almacenamiento local u otro método para guardar el estado parece extraño cuando tiene el objeto de estado disponible en la API del historial.

Correcto, pero en contra: el uso del objeto de estado debería ser extraño cuando tiene almacenamiento local, cookies o cualquier otro método para guardar el estado que _no_ simplemente esté vinculado a la URL actual.

¿Por qué no sería mejor utilizar la herramienta que se proporciona? El objeto de estado proporciona un método sencillo para guardar y acceder a estados anteriores. En lugar de examinar el almacenamiento local cada vez que un usuario llega a una página, tener history.state disponible permitiría la capacidad de recordar no solo el estado genérico de la vista a través de la ruta de la URL, sino también el estado específico de esa vista que un usuario podría querer volver a.

En mi opinión, las aplicaciones simples que usan rutas deberían usarlas simplemente. Copie y pegue la URL para disfrutar de la experiencia completa. Las aplicaciones complejas deben usar rutas solo como simples puntos de entrada a áreas generales de la aplicación, o registros particulares, y luego usar apis de almacenamiento que representen mejor el tipo de persistencia, ya sea de usuario (servidor), sesión o local.

El uso del objeto de estado de historial anula lo bueno de la forma simple en que las aplicaciones de una sola página pueden usar URL como marcadores potencialmente permanentes.

Backbone siempre ha sido muy flexible y menos obstinado que otros marcos. No entiendo por qué esto es diferente con el window.history.pushState nativo. Entiendo que a algunas personas no les gustará. Sin embargo, la decisión de usarlo o no debe dejarse al usuario final.

Así que, por favor, reconsidere esto.

@rafayepes Estoy totalmente de acuerdo con tu argumento. Me encanta Backbone y su simplicidad, pero este cambio de API introduce un montón de problemas y soluciones en el código, cuando la aplicación debería almacenar una relación 1 a 1 entre la URL y el estado. La forma nativa de interactuar con History API sería mucho más fácil.