react-router：为什么browserHistory优先于hashHistory？

Question

我对React比较新;如果这是一个非常天真的问题，请道歉。

browserHistory有哪些技术优势使其优于hashHistory？例如，使用History API？

是否可以提高性能/效率

文档声明browserHistory是recommended，即使这是additional server config的代价，需要通过{{为不同的服务器硬编码或配置基本URL 3}}

hashHistory＆＃34;只是工作＆＃34;但是，无论从哪个基本URL提供文件。无需服务器配置。捆绑您的应用程序，从服务器上的任何URL /路径托管它，这很好。

如果文档在解释为什么它被推荐browserHistory时会更进一步，即使它涉及更多复杂性，也可能会更好。

Answer 1

在某些情况下 hashHistory 很好 - 除非您开始处理需要知道原始请求的完整URL的服务器端逻辑。

  

浏览器不会在任何HTTP请求中发送URL的#hash部分。

因此，当用户请求页面时，服务器端（即NodeJS）不知道URL中的#hash是什么。

一个很好的例子是用户试图加载需要登录的页面（通过oAuth等）。在用户进入单独的网站进行身份验证之前，您的应用程序服务器端会告诉身份验证供应商在成功登录后将用户重定向到哪个URL（通常是由于大多数网站执行此操作所请求的原始URL）。如果您使用 hashHistory - 服务器端只知道＃符号之前的位，并将用户重定向到您应用的主页，而不是子页面用户想要加载。

我希望这是有道理的。

Answer 2

浏览器历史优于hashHistory的一个原因是它更适合部署和生产。 hashHistory＆＃34; works＆＃34;通过在网址末尾添加一个唯一键并创建一个＆＃34;历史记录＆＃34;为此，通过使用这些键来跟踪您当前的会话。

如果没有＃，browserHistory看起来更干净，但是为了设置这个，你需要配置你的服务器，使它能够处理你想要提供它的URL。

希望有所帮助！

Answer 3

  

browserHistory的技术优势是什么，使其优于hashHistory？

它允许您拥有服务器端回退：

1. 允许访问的第一个页面使用HTML进行初始化（而不是必须使用Ajax获取所有数据），从而提供更好的性能
2. 表示网站即使when JS fails仍然有效（这对搜索引擎也更好）。

这需要以与客户端代码相同的方式编写服务器端代码来构建页面。没有它，使用历史API客观上更糟糕......但是，URL非常主观，更好，所以很多人在没有服务器端的情况下做到这一点。