Backbone: History.navigate devrait permettre la définition de l'objet d'état

J'ai peur de ne pas être d'accord - mais s'il vous plaît essayez de me persuader du contraire.

Le but de l'API History est de fournir des URL pouvant être mises en signet et partageables, vers lesquelles vous pouvez revenir. Si vous attachez un objet d'historique avec l'API, la page vers laquelle vous revenez _n'est pas_ la même que la page que vous verriez si vous colliez l'URL identique. Cela semble cassé ... et à tout le moins redondant avec votre capacité à stocker un état arbitraire dans JS au cours d'une session de navigateur.

Cela sent comme une API où les implémenteurs du navigateur pensaient : « ça ne serait pas génial si vous pouviez... », et n'ont pas considéré les conséquences réelles.

Je pense que vous faites des hypothèses sur le comportement souhaitable de l'application et également sur la granularité des événements de l'historique qui sont plus restrictives que ce que fournit l'API du navigateur. Plus précisément, il n'y a aucune raison qu'il appartienne au framework et non à l'application de dicter le comportement lorsqu'il est invoqué avec un URI. Il semble parfaitement et évidemment légitime qu'il existe un état (donné par le chemin de navigation) qui soit orthogonal à la ressource (et état codé) identifié par l'URI, et que la présentation soit conditionnée aux deux. De toute évidence, ce choix devrait appartenir à l'application individuelle.

Mis à part cet argument abstrait, dites-moi comment implémenterez-vous, par exemple, un formulaire d'entrée pouvant être mis en signet qui propose d'enregistrer/d'ignorer les modifications lorsque vous vous éloignez de (y compris avec le bouton de retour) à l'aide de l'API History ?

Il s'agit d'un changement d'une ou deux lignes. Si vous ne souhaitez pas ajouter de paramètre à History.navigate vous pouvez également utiliser l'état donné via, par exemple, un attribut ou une fonction currentState .

dites-moi comment implémenterez-vous par exemple un formulaire de saisie de signet
qui propose d'enregistrer/supprimer les modifications lorsque vous vous éloignez de (y compris
avec le bouton retour) en utilisant l'API History ?

Je stockerais simplement les modifications de formulaire dans un endroit différent et plus sûr : dans la session, dans le serveur, dans le stockage local...

J'étais curieux de savoir ce que les gens pensaient de ce poste, alors j'ai demandé :

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

Et voici quelques réponses :

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

L'API History traite spécifiquement de l'état de l'application lié au chemin de navigation, distinct de l'URI. C'est-à-dire « Comment sommes-nous arrivés ici ? » Peut-être que cela devrait s'appeler l'API Hysterisis. Nous pouvons partager le même URI et être sur la même « page », mais pas la même vue/page/état de retour lorsque j'appuie sur le bouton de retour de la souris ou que je glisse en arrière sur votre mobile. Et cette action de retour peut changer l'état/l'historique de l'application sans changer l'URI. Toutes les transitions de navigation ne sont pas des transitions URI. Ainsi, lorsque nous partageons un URI, cela peut conduire à présenter la même ressource ou « page », mais pas le même état de navigation.

Bien que j'apprécie l'expérience de votre troupeau, je pense que cela montre simplement que la plupart des développeurs n'ont pas encore compris comment utiliser l'API comme prévu par les créateurs. Ce n'est pas une bonne raison pour que le cadre le pave.

De plus, vous n'avez pas abordé la question, qui n'était pas de savoir comment conserver les valeurs du formulaire, mais plutôt comment utiliser l'API push/popState pour inviter l'utilisateur à enregistrer les modifications, le cas échéant, lorsqu'il appuie sur le bouton de retour pour naviguer loin du formulaire avec l'URI pouvant être mis en signet. S'il vous plaît envisager d'aborder cela.

Je suis très nouveau sur Backbone et WebDev en général, cependant je suis d'accord avec tribalvibes.

Je souhaite créer une application Web basée sur l'API Graph de Facebook et utiliser la fonction de navigation de Backbone pour permettre à l'utilisateur de revenir à différents éléments à afficher, de la même manière que Facebook le fait actuellement. Cependant, sans le stateobject dans pushState, l'utilisateur doit recharger l'élément depuis l'API, ce qui est évidemment coûteux.

C'est probablement parce que je ne sais pas quel est le modèle commun de ce problème, mais je pense qu'avoir un objet d'état pour cela serait très utile.

Selon la documentation MDN, l'objet d'état est enregistré sur le disque. Je ne comprends pas en quoi cela diffère de l'enregistrement sur un stockage local. Je pense que cela devrait être réexaminé. L'utilisation du stockage local ou d'une autre méthode d'enregistrement de l'état semble superflue lorsque vous disposez de l'objet d'état dans l'API d'historique.

Exact, mais contra : l'utilisation de l'objet d'état devrait être superflue lorsque vous disposez d'un stockage local, de cookies ou de toute autre méthode d'enregistrement d'état qui n'est _pas_ simplement liée à l'URL actuelle.

Pourquoi ne serait-il pas préférable d'utiliser l'outil fourni ? L'objet d'état fournit une méthode simple d'enregistrement et d'accès aux états précédents. Plutôt que de passer au crible le stockage local chaque fois qu'un utilisateur arrive sur une page, avoir history.state disponible permettrait de rappeler non seulement l'état générique de la vue via la route url, mais aussi l'état spécifique de cette vue qu'un utilisateur voudra peut-être y retourner.

À mon avis, les applications simples qui utilisent des itinéraires devraient les utiliser simplement. Copiez et collez l'URL pour l'expérience complète. Les applications complexes doivent utiliser les routes uniquement comme de simples points d'entrée vers des zones générales de l'application ou des enregistrements particuliers, puis utiliser des API de stockage qui représentent mieux le type de persistance, qu'il s'agisse d'un utilisateur (serveur), d'une session ou local.

L'utilisation de l'objet d'état de l'historique va à l'encontre de ce qui est génial avec la manière simple dont les applications d'une seule page peuvent utiliser les URL comme signets potentiellement permanents.

Backbone a toujours été très flexible et moins opiniâtre que les autres frameworks. Je ne comprends pas pourquoi c'est différent avec le natif window.history.pushState. Je comprends que certaines personnes n'aimeront pas ça. Cependant, la décision de l'utiliser ou non doit être laissée à l'utilisateur final.

Alors s'il vous plaît, repensez-le.

@rafayepes Je suis entièrement d'accord avec votre argument. J'adore Backbone et sa simplicité, mais cette modification de l'API introduit un tas de problèmes et de solutions de contournement dans le code, lorsque l'application doit stocker une relation 1 à 1 entre l'URL et l'état. La manière native d'interagir avec l'API History serait beaucoup plus facile.