Backbone: History.navigate sollte das Setzen von Zustandsobjekten ermöglichen

Ich befürchte, dass ich anderer Meinung bin - aber versuchen Sie bitte, mich vom Gegenteil zu überzeugen.

Der Sinn der History API besteht darin, lesezeichenfähige, gemeinsam nutzbare URLs bereitzustellen, zu denen Sie zurück navigieren können. Wenn Sie ein Verlaufsobjekt mit der API anhängen, ist die Seite, zu der Sie zurück navigieren, _nicht_ dieselbe wie die Seite, die Sie sehen würden, wenn Sie die identische URL einfügen. Dies scheint kaputt zu sein ... und zumindest überflüssig mit Ihrer Fähigkeit, während einer Browsersitzung einen beliebigen Zustand in JS zu speichern.

Es riecht wie eine API, bei der die Browser-Implementierer dachten: "Meine Güte, wäre es nicht schön, wenn Sie könnten...", und die wirklichen Konsequenzen nicht berücksichtigt haben.

Ich denke, Sie treffen Annahmen über das wünschenswerte App-Verhalten und auch die Granularität von Verlaufsereignissen, die restriktiver sind als das, was die Browser-API bietet. Insbesondere gibt es keinen Grund, warum es am Framework und nicht an der App liegen sollte, das Verhalten beim Aufrufen mit einem URI zu diktieren. Es scheint vollkommen und offensichtlich legitim zu sein, dass es einen Zustand (vom Navigationspfad gegeben) gibt, der orthogonal zu der durch den URI identifizierten Ressource (und dem codierten Zustand) ist, und dass die Präsentation von beiden abhängig ist. Diese Wahl sollte natürlich der einzelnen App überlassen werden.

Abgesehen von diesem abstrakten Argument, sagen Sie mir, wie würden Sie beispielsweise ein mit Lesezeichen versehenes Eingabeformular implementieren, das das Speichern/Verwerfen von Änderungen anbietet, wenn Sie mit der History-API (einschließlich der Zurück-Schaltfläche) weg navigieren?

Dies ist ein ein- oder zweizeiliger Wechsel. Wenn Sie History.navigate keinen Parameter hinzufügen möchten, können Sie auch den Status verwenden, der zB über ein currentState Attribut oder eine Funktion angegeben wird.

Sag mir, wie würdest du zum Beispiel ein bookmarkables Eingabeformular implementieren
die anbietet, Änderungen zu speichern/zu verwerfen, wenn Sie weg navigieren (einschließlich
mit der Zurück-Schaltfläche) mit der History-API?

Ich würde die Formularänderungen einfach an einem anderen und sichereren Ort speichern: In der Session, im Server, im localstorage...

Ich war neugierig, was die Leute von dieser Position halten, also fragte ich:

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

Und hier waren einige der Antworten:

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

History API befasst sich speziell mit dem App-Status, der an den Navigationspfad gebunden ist, im Gegensatz zum URI. Dh "Wie sind wir hierher gekommen?" Vielleicht sollte es Hysterisis API heißen. Wir teilen möglicherweise dieselbe URI und befinden uns auf derselben 'Seite', aber nicht auf derselben Ansicht/Seite/Status, wenn ich die Zurück-Taste auf der Maus drücke oder auf deinem Handy zurückwische. Und diese Zurück-Aktion kann den App-Status/-Verlauf ändern, ohne den URI zu ändern. Nicht alle Nav-Übergänge sind URI-Übergänge. Wenn wir also einen URI teilen, kann dies dazu führen, dass dieselbe Ressource oder „Seite“ angezeigt wird, aber nicht derselbe Navigationsstatus.

Ich schätze die Erfahrung Ihrer Herde zwar, aber ich denke, es zeigt nur, dass die meisten Entwickler noch nicht herausgefunden haben, wie sie die API wie von den Entwicklern beabsichtigt verwenden. Das ist kein guter Grund für das Framework, es zu ebnen.

Außerdem haben Sie sich nicht mit der Frage befasst, die nicht darin bestand, die Formularwerte beizubehalten, sondern wie Sie die push/popState-API verwenden, um den Benutzer aufzufordern, die Änderungen, falls vorhanden, zu speichern, wenn er die Zurück-Schaltfläche zum Navigieren drückt mit dem bookmarkable URI vom Formular weg. Bitte erwägen Sie, darauf einzugehen.

Ich bin sehr neu bei Backbone und WebDev im Allgemeinen, aber ich stimme Tribalvibes zu.

Ich möchte eine Webanwendung erstellen, die auf der Graph-API von Facebook basiert und die Navigationsfunktion von Backbone verwenden, um es dem Benutzer zu ermöglichen, zu verschiedenen Elementen zurückzukehren, die er anzeigen kann, ähnlich wie es Facebook derzeit tut. Ohne das stateobject in pushState muss der Benutzer das Item jedoch von der API neu laden, was natürlich kostspielig ist.

Es liegt wahrscheinlich daran, dass ich nicht weiß, was das allgemeine Muster für dieses Problem ist, aber ich denke, ein Zustandsobjekt dafür zu haben, wäre sehr hilfreich.

Gemäß der MDN-Dokumentation wird das Zustandsobjekt auf der Festplatte gespeichert. Ich verstehe nicht, wie das anders ist, als im lokalen Speicher zu speichern. Ich denke, das sollte nachgeholt werden. Die Verwendung des lokalen Speichers oder einer anderen Methode zum Speichern des Zustands erscheint überflüssig, wenn Ihnen das Zustandsobjekt in der Verlaufs-API zur Verfügung steht.

Richtig, aber Contra: Die Verwendung des State-Objekts sollte überflüssig sein, wenn Sie lokalen Speicher, Cookies oder eine andere Methode zum Speichern von Zuständen haben, die _nicht_ einfach an die aktuelle URL gebunden ist.

Warum wäre es nicht besser, das mitgelieferte Tool zu verwenden? Das Zustandsobjekt bietet eine einfache Methode zum Speichern und Zugreifen auf vorherige Zustände. Anstatt jedes Mal, wenn ein Benutzer auf einer Seite ankommt, den lokalen Speicher zu durchsuchen, würde die Verfügbarkeit von history.state es ermöglichen, nicht nur den allgemeinen Status der Ansicht über die URL-Route abzurufen, sondern auch den spezifischen Status dieser Ansicht, den ein Benutzer vielleicht wiederkommen möchte.

Aus meiner Sicht sollten einfache Apps, die Routen verwenden, diese einfach verwenden. Kopieren Sie die URL und fügen Sie sie ein, um die vollständige Erfahrung zu erhalten. Komplexe Apps sollten Routen nur als einfache Einstiegspunkte zu allgemeinen Bereichen der Anwendung oder zu bestimmten Datensätzen verwenden und dann Speicher-APIs verwenden, die den Persistenztyp besser darstellen, sei es Benutzer (Server), Sitzung oder Lokal.

Die Verwendung des Verlaufszustandsobjekts macht das Tolle an der einfachen Art und Weise zunichte, wie Single-Page-Apps URLs als potenziell dauerhafte Lesezeichen verwenden können.

Backbone war schon immer sehr flexibel und weniger eigensinnig als andere Frameworks. Ich verstehe nicht, warum das beim nativen window.history.pushState anders ist. Ich verstehe, dass es manchen Leuten nicht gefallen wird. Die Entscheidung, es zu verwenden oder nicht, sollte jedoch dem Endbenutzer überlassen werden.

Also bitte nochmal überdenken.

@rafayepes Ich stimme deinem Argument voll und ganz zu. Ich liebe Backbone und seine Einfachheit, aber diese API-Änderung führt zu einer Reihe von Problemen und Problemumgehungen im Code, wenn die App eine 1-zu-1-Beziehung zwischen URL und Zustand speichern soll. Die native Interaktion mit der History API wäre viel einfacher.