1

在骨干网中，hashbang 已从代码中删除，标准回退到“#/path”，这对于爬行应该没问题（参见https://github.com/documentcloud/backbone/commit/10230e4d76e21f08a1dee1fe5d28994e2cf5f11d#commitcomment-477992）

但是如果一个 ie9 用户想要做一个 facebook 分享（复制粘贴 url），我仍然需要一个 _escaped_fragment_ 处理程序，在那里我可以做一个规范的 url 或重定向以干净的方式处理它，但是“#！” 后备仍然是必要的，对吧？

4

2 回答 2

2

问题在于服务器何时需要#!确定您的位置（几年前的 Twitter/Gawker）。如果您正确设置服务器 - 即始终返回您的主干应用程序并（并启动路由器）为您的应用程序中的任何 URL，它将为所有用户正确处理。

IE8/9 用户将看到散列的 url。理智的浏览器将显示正常的 URL。如果一个“正常”的浏览器加载一个散列 URL，主干路由器就会知道该做什么。IE8/9 也是如此。

只要您从服务器返回给定 URL 的正确视图状态（即在服务器端预渲染），Google 就不会像普通网站一样使用您的网站并愉快地对其进行索引。

这个问题#!和_escaped_fragment_旨在处理的问题真的不再重要了。

编辑

例子：

假设您在服务器上运行了一个 Backbone 应用程序，它位于http://myserver.com/myapp/. 这是您传递给 Backbone.history 对象的基础：

Backbone.history.start({pushState: true, root: '/myapp'});

这向路由器解释了所有路径下的所有路径/myapp/都由 Backbone 应用程序“拥有”。只要请求的任何以开头的路由/myapp/返回您的 Backbone 应用程序，它就会工作，无论浏览器如何。

因此，假设您的用户正在使用该应用程序并最终使用/myapp/awesome/thing/to/share. 对于 IE8/9 用户，他们的 URL 将是/myapp#awesome/thing/to/share.

当浏览器从服务器请求这个时，它只要求/myapp. 这将返回您的 Backbone 应用程序并启动历史对象/路由器。路由器看到有一个散列片段并说“哦，给用户awesome/thing/to/share”。任何请求此 URL 的浏览器都会发生这种情况。

当 IE8/9 用户请求/myapp/awesome/thing/to/share时，只要您的服务器返回相同的 Backbone 应用程序，路由器将再次看到路径为 /awesome/thing/to/share'，然后自动将 IE8/9 中的 URL 更改为/myapp#awesome/thing/to/share.

唯一需要做一些棘手的事情是如果您希望 Google/Facebook 能够抓取此页面。由于它们不运行 javascript，因此必须从您的服务器发送页面，就像 Backbone 在浏览器中编写它一样 - 或者对于 Facebook，在文档的部分中有<og:*>可用的标签。<head>

于 2013-01-16T19:25:05.113 回答
0

答案是（如果没有人提供替代方案）不，如果您有这些要求，这不是一个坏主意，请参阅与 tkone 的讨论

于 2013-02-05T16:56:35.030 回答