最近一个SPA的玩具项目中在用react-router,有个问题一直在困扰我。我按照官方的文档,使用browserHistory,然后生成的客户端路由都是不带#的。这样在一个子级路由中刷新页面,就是请求这个子级路由,我后端就得能识别这个子级路由。。这就有些蛋疼,和我以前用过的#/XXX这样的客户端路由有些不同。
不应该啊,作者不可能没考虑到这个问题啊,肯定是我哪里用的不对。于是乎,我又去看了下文档。
找到这篇文档 Histories,终于算是解决了我的疑惑。
react-router提供了三种方式来实现路由,并没有默认的路由,需要在声明路由的时候,显式指定所使用的路由。
//v1.x
<Router/>
//v2.0.0
// hash history
import { hashHistory } from 'react-router'
<Router history={hashHistory} />
- browserHistory
- hashHistory
- createMemoryHistory
官方推荐的是browserHistory,它是使用浏览器内置的 History API 实现的。同时,后端也需要特殊配置,来处理这些可能发送到后端的路由,不光是因为用户可能手动刷新页面,还有另外一个更重要的原因。在不支持 History 特性的旧式浏览器中,react-router就会直接重新加载页面(显然后端必须识别这些路由)。
文档中有一句也提到了为什么推荐使用browser history,而不是hash history。要知道,react router以前是默认使用hash history的。
You might wonder why we don't fall back to hash history; the problem is that URLs become non-deterministic. If a visitor on hash history shares a URL with a visitor on browser history, and then they share that back, we end up with a terrible cartesian product of infinite potential URLs.
意思就是怕 hash history 和 browser history 的混用在分享url时引起混乱。
我有点不太明白,一个app应该只会采用一种方式,不会混用啊。
先留个坑,待我再查查。
在stackoverflow上提了个问题,总算解决了疑惑。
文档中的意思是在运行时切换 browser history 和 hash history,而不是我之前理解的只有一种方式实现。那在分享url的时候,自然是会引起混乱的。
网友评论