当前 History 使用空的{}状态对象调用pushState 。 允许调用者设置状态对象至关重要。 如果可用，至少使用window.history.state将是一个明智的默认值。 History.navigate应该将stateObject作为附加参数。
tribalvibes
所有11条评论
恐怕我不同意——但请试着说服我否则。
History API 的重点是提供可添加书签、可共享的 URL，您可以导航回这些 URL。 如果您使用 API 附加历史对象，则您导航回的页面_与粘贴相同 URL 时看到的页面不同。 这似乎坏了......并且至少对于您在浏览器会话过程中在 JS 中存储任意状态的能力来说是多余的。
它闻起来像一个 API，浏览器实现者认为，“哎呀，如果你能……那不是很好吗……”，并且没有考虑真正的后果。
jashkenas
于 2011-12-02
我认为您正在对理想的应用程序行为以及历史事件的粒度做出假设，这些粒度比浏览器 API 提供的更严格。 具体来说，当使用 URI 调用时，没有理由应该由框架而不是应用程序来决定行为。 存在与 URI 标识的资源（和编码状态）正交的状态（由导航路径给出），并且表示以两者为条件，这似乎完全且显然是合法的。 显然，这个选择应该取决于个人应用程序。
除了那个抽象的论点，告诉我您将如何实现例如一个可添加书签的条目表单，该表单在使用 History API 导航离开（包括使用后退按钮）时提供保存/丢弃更改？
这是一两行更改。 如果您不想向History.navigate添加参数，也可以使用通过例如currentState属性或函数给出的状态。
tribalvibes
于 2011-12-04
告诉我您将如何实现例如可添加书签的条目表单
提供在导航离开时保存/放弃更改（包括
后退按钮）使用历史 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
jashkenas
于 2011-12-05
History API 专门处理与导航路径相关的应用程序状态，与 URI 不同。 即“我们是怎么到这里来的？” 也许它应该被称为 Hysterisis API。 当我点击鼠标上的后退按钮或在您的手机上向后滑动时，我们可能共享相同的 URI 并位于相同的“页面”上，但返回视图/页面/状态不同。 并且该返回操作可能会在不更改 URI 的情况下更改应用程序状态/历史记录。 并非所有导航转换都是 URI 转换。 因此，当我们共享一个 URI 时，它可能会导致呈现相同的资源或“页面”但不是相同的导航状态。
虽然我很欣赏你们的经验，但我认为这只是表明大多数开发人员还没有弄清楚如何按照创建者的意图使用 API。 这不是框架铺平它的好理由。
此外，您没有解决这个问题，这不是如何保留表单值，而是如何使用 push/popState API 来提示用户在他们点击后退按钮导航时保存更改（如果有）远离带有可添加书签的 URI 的表单。 请考虑解决这个问题。
tribalvibes
于 2011-12-06
总的来说，我对 Backbone 和 WebDev 很陌生，但我同意 tribalvibes。
我想基于 Facebook 的 Graph API 创建一个 Web 应用程序，并使用 Backbone 的导航功能允许用户返回不同的项目进行查看，类似于 Facebook 现在所做的。 但是，如果没有 pushState 中的 stateobject，用户必须从 API 重新加载 item，这显然成本很高。
可能是因为我不知道这个问题的常见模式是什么，但我认为为此拥有一个状态对象会非常有帮助。
nambrot
于 2011-12-25
根据 MDN 文档，状态对象被保存到磁盘。 我不明白这与保存到本地存储有什么不同。 我认为应该重新解决这个问题。 当您在历史 API 中拥有可用的状态对象时，使用本地存储或其他保存状态的方法似乎无关紧要。
chadthenderson
于 2014-01-21
正确，但相反：当您有本地存储、cookie 或任何其他_不_简单地绑定到当前 URL 的状态保存方法时，使用状态对象应该是无关紧要的。
jashkenas
于 2014-01-21
为什么不使用提供的工具更好？ 状态对象提供了一种直接的方法来保存和访问以前的状态。 不是每次用户到达页面时都筛选本地存储，使用 history.state 将允许不仅能够通过 url 路由调用视图的通用状态，还能够调用用户访问该视图的特定状态可能想回到。
chadthenderson
于 2014-01-21
在我看来，使用路由的简单应用程序应该简单地使用它们。 复制并粘贴网址以获得完整体验。 复杂的应用程序应该仅将路由用作应用程序一般区域或特定记录的简单入口点，然后使用能够更好地代表持久性类型的存储 API，无论是用户（服务器）、会话还是本地。
使用历史状态对象破坏了单页应用程序可以使用 url 作为潜在永久书签的简单方式的优点。
lukesargeant
于 2014-01-22
与其他框架相比，Backbone 一直非常灵活且不那么固执己见。 我不明白为什么这与本机 window.history.pushState 不同。 我知道有些人不会喜欢它。 但是，使用与否的决定应留给最终用户。
所以请重新考虑一下。
rafayepes
于 2014-02-13
@rafayepes我完全同意你的论点。 我喜欢 Backbone 及其简单性，但是这个 API 更改在代码中引入了一系列问题和变通方法，此时应用程序应该存储 url 和状态之间的一对一关系。 与 History API 交互的原生方式会容易得多。
jakwuh
于 2016-06-20
相关问题
etler
·
13评论
omenking
·
10评论
rubiii
·
12评论
miguelpayet
·
9评论
PavelKoroteev
·
10评论
最有用的评论
History API 专门处理与导航路径相关的应用程序状态，与 URI 不同。 即“我们是怎么到这里来的？” 也许它应该被称为 Hysterisis API。 当我点击鼠标上的后退按钮或在您的手机上向后滑动时，我们可能共享相同的 URI 并位于相同的“页面”上，但返回视图/页面/状态不同。 并且该返回操作可能会在不更改 URI 的情况下更改应用程序状态/历史记录。 并非所有导航转换都是 URI 转换。 因此，当我们共享一个 URI 时，它可能会导致呈现相同的资源或“页面”但不是相同的导航状态。
虽然我很欣赏你们的经验，但我认为这只是表明大多数开发人员还没有弄清楚如何按照创建者的意图使用 API。 这不是框架铺平它的好理由。
此外，您没有解决这个问题，这不是如何保留表单值，而是如何使用 push/popState API 来提示用户在他们点击后退按钮导航时保存更改（如果有）远离带有可添加书签的 URI 的表单。 请考虑解决这个问题。