如何在单页应用程序中使用#-URL?

发布于 2024-12-09 10:17:42 字数 803 浏览 1 评论 0原文

这篇文章提出了一个非常令人信服的论点,因为 URL 是它们的寿命很长(它们会被添加书签并被传递),它们应该是有意义的,因此使用哈希进行实际路由(确定页面上显示的数据和/或应用程序的状态)是不合适的。然而,当我尝试在单页应用程序中实际执行此操作时,我遇到了一个问题:如何呈现链接以便所有浏览器都可以使用该应用程序?在我看来,有三个选项:

  1. 所有 href 都有一个 #/ 前缀。这在 HTML4 浏览器中效果很好。在 HTML5 浏览器中,我可以添加一个 Sammy 路由来重定向到无哈希版本,这也很有效。浏览器在链接未访问时将其标记为已访问或在链接已访问时不将其标记为已访问可能会出现问题。另一个问题是它是……错误的。任何通过右键单击链接并选择“复制链接 URL”来共享链接的人都会发送一个有效但混乱的 URL。
  2. 没有 href 具有 #/ 前缀。据我所知,HTML4浏览器将无法拦截这些链接点击,这意味着每次点击都会导致页面刷新。尽管应用程序可能仍然可以运行,但由于我可以使用 Sammy 路由在页面加载时将无哈希版本重写为哈希版本,因此页面加载将杀死单页面应用程序的性能。
  3. 我动态确定是否添加前缀 #/ 。这意味着我的所有链接都必须具有动态标记,这使得应用程序变得非常复杂。

This article makes a pretty convincing argument that because URLs are long-lived (they get bookmarked and passed around), they should be meaningful, and that using the hash for real routing (determining what data is shown on the page and/or the state of the application) is thus improper. When I try to actually do that in my single-page application, though, I run up against a problem: how do I render my links so that all browsers can use the application? As I see it, there are three options:

  1. all hrefs have a #/ prefix. This works great in HTML4 browsers. In HTML5 browsers, I can add a Sammy route that redirects to the hash-less version, which also works great. There might be a problem with browsers marking links as visited when they're not or not marking them visited when they are. The other problem is that it's... wrong. Anyone who shares a link by right-clicking it and selecting "Copy Link URL" will be sending a working but kludgy URL around.
  2. no hrefs have a #/ prefix. As far as I can tell, HTML4 browsers will have no way of intercepting these link clicks, which means that every one will cause a page refresh. Though the application would probably still function, since I could use Sammy routes to rewrite the hashless versions to hashy ones on page load, the page loads would kill the performance of the single-page application.
  3. I dynamically determine whether to prefix with #/ or not. This means that all of my links have to have dynamic markup and dramatically complicates the application.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

捶死心动 2024-12-16 10:17:42

URL 的 hash 值永远不会导致页面重新加载。 HTML4 及之前的版本中没有。哈希值一直是内部链接,因此可以完美使用(例如看看 twitter)。当然,当你刷新页面时,你会重新加载页面。但这是显而易见的。

使用 JavaScript,您实际上可以读取此哈希值(另请参阅此问题/答案:如何使用 JavaScript 检查 URL 中的#hash?)使用 window.location.hash

使用较新的浏览器,您还可以检测哈希更改,如果用户确实这样做,这很有用更改 URL:On - window.location.hash - 更改?

但是当您,作为网站,更改您不需要阅读此内容的 URL,因为您刚刚更改了它,所以您已经知道了。

这样,使用哈希值,人们可以交换 URL,并且您实际上可以读取他们正在请求的 URL,因此它应该可以完美地工作。

The hash value of a URL never caused and entire re-load of page. Not in HTML4 and before that. A hash value has always been an internal link, and therefore it can be used perfectly (take a look at twitter for example). Of course, when you refresh the page, you will reload the page. But that is obvious.

With JavaScript you can actually read this hash value (see also this question/answer: How can you check for a #hash in a URL using JavaScript?) using window.location.hash

Using a more recent browser, you can also detect a hash change, which is useful if users actually change the URL: On - window.location.hash - Change?

But when you, as the website, change the URL you don't need read this, you already know because you just changed it.

This way, using hashes, people can exchange the URLs, and you can actually read which URL they are requesting, and therefore it should work perfectly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文