Backbone: History.navigateは、状態オブジェクトの設定を許可する必要があります

同意できないのではないかと思いますが、そうでない場合は説得してください。

History APIのポイントは、ブックマーク可能で共有可能なURLを提供し、そこに戻ることができるようにすることです。 APIを使用して履歴オブジェクトを添付する場合、戻るページは、同じURLに貼り付けた場合に表示されるページと同じではありません。 これは壊れているようです...そして、ブラウザセッションの過程でJSに任意の状態を保存する機能と少なくとも冗長です。

これは、ブラウザの実装者が「できればいいのではないか...」と考え、実際の結果を考慮しなかったAPIのようなにおいがします。

あなたは、望ましいアプリの動作と、ブラウザーAPIが提供するものよりも制限的な履歴イベントの粒度について想定していると思います。 具体的には、URIで呼び出されたときの動作を指示するのはアプリではなく、フレームワークに任されるべきである理由はありません。 URIによって識別されるリソース（およびエンコードされた状態）に直交する状態（ナビゲーションパスによって与えられる）があり、プレゼンテーションが両方を条件としていることは、完全かつ明らかに正当であるように思われます。 明らかに、その選択は個々のアプリ次第である必要があります。

その抽象的な議論とは別に、たとえば、History APIを使用して（戻るボタンを含む）離れた場所に移動したときに変更を保存/破棄することを提供するブックマーク可能な入力フォームをどのように実装しますか？

これは1行または2行の変更です。 History.navigateにパラメーターを追加したくない場合は、たとえばcurrentState属性または関数を介して指定された状態を使用するようにすることもできます。

たとえばブックマーク可能なエントリーフォームをどのように実装しますか？
から離れた場所に移動したときに変更を保存/破棄することを提案します（
戻るボタンを使用）History APIを使用しますか？

フォームの変更を別のより安全な場所に保存するだけです。セッション、サーバー、ローカルストレージ...

私は人々がこの立場についてどう思っているか知りたいと思ったので、私は尋ねました：

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

そして、ここにいくつかの返信がありました：

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は、URIとは異なり、ナビゲーションパスに関連付けられたアプリの状態を具体的に処理します。 つまり、「どうやってここにたどり着いたの？」 多分それはヒステリシスAPIと呼ばれるべきです。 私たちは同じURIを共有し、同じ「ページ」にいる可能性がありますが、マウスの戻るボタンを押すか、モバイルでスワイプして戻ると、同じリターンビュー/ページ/状態ではありません。 そして、そのバックアクションは、URIを変更せずにアプリの状態/履歴を変更する可能性があります。 すべてのナビゲーション遷移がURI遷移であるわけではありません。 したがって、URIを共有すると、同じリソースまたは「ページ」が表示される可能性がありますが、同じナビゲーション状態は表示されません。

あなたの群れの経験に感謝しますが、ほとんどの開発者が作成者の意図したとおりにAPIを使用する方法をまだ理解していないことを示していると思います。 これは、フレームワークがそれを舗装する正当な理由ではありません。

また、フォームの値を保持する方法ではなく、push / popState APIを使用して、ユーザーが[戻る]ボタンを押してナビゲーションしたときに変更を保存するようにユーザーに求める方法であるという質問には対処しませんでした。ブックマーク可能なURIを持つフォームから離れます。 それに対処することを検討してください。

私は一般的にBackboneとWebDevに非常に慣れていませんが、部族の雰囲気には同意します。

FacebookのGraphAPIに基づいてWebアプリケーションを作成し、Backboneのナビゲート機能を使用して、Facebookが現在行っているのと同じように、ユーザーが別のアイテムに戻って表示できるようにしたい。 ただし、pushStateにstateobjectがないと、ユーザーはAPIからアイテムをリロードする必要があり、これは明らかにコストがかかります。

この問題の一般的なパターンが何であるかわからないためかもしれませんが、このための状態オブジェクトがあると非常に役立つと思います。

MDNドキュメントに従って、状態オブジェクトはディスクに保存されます。 それがローカルストレージに保存するのとどう違うのかわかりません。 私はこれを再検討する必要があると思います。 履歴APIで状態オブジェクトを使用できる場合、ローカルストレージまたは状態を保存する別の方法を使用することは無関係に思えます。

正解ですが、反対です。ローカルストレージ、Cookie、または現在のURLに単純に関連付けられていない状態を保存するその他の方法がある場合、状態オブジェクトの使用は無関係である必要があります。

提供されているツールを利用したほうがよいのはなぜですか？ 状態オブジェクトは、以前の状態を保存してアクセスするための簡単な方法を提供します。 ユーザーがページにアクセスするたびにローカルストレージを選別するのではなく、history.stateを使用できるようにすると、URLルートを介してビューの一般的な状態だけでなく、ユーザーがそのビューの特定の状態を呼び出すことができます。に戻りたいと思うかもしれません。

私の見解では、ルートを使用する単純なアプリは、ルートを単純に使用する必要があります。 完全なエクスペリエンスのためにURLをコピーして貼り付けます。 複雑なアプリは、アプリケーションの一般的な領域または特定のレコードへの単純なエントリポイントとしてのみルートを使用し、ユーザー（サーバー）、セッション、ローカルなど、永続性のタイプをより適切に表すストレージAPIを使用する必要があります。

履歴状態オブジェクトを使用すると、シングルページアプリがURLを永続的なブックマークとして使用できる簡単な方法の優れた点が無効になります。

バックボーンは常に非常に柔軟性があり、他のフレームワークよりも意見が少ないです。 これがネイティブのwindow.history.pushStateと異なる理由がわかりません。 気に入らない人もいると思います。 ただし、それを使用するかどうかの決定は、最終ユーザーに任されるべきです。

考え直してください。

@rafayepes私はあなたの議論に完全に同意します。 私はBackboneとそのシンプルさが大好きですが、このAPIの変更により、アプリがURLと状態の1対1の関係を保存する必要がある場合に、コードに多くの問題と回避策が導入されます。 HistoryAPIと対話するネイティブの方法ははるかに簡単です。