前端工程采用 SPA 模式 hashHistory , 在集成到生产环境中的时候，使用browserHistory ：

var his;
if (isDev) {
  //SPA
  his = hashHistory
} else {
  his = browserHistory
}

let routes =
  <Route path="/">
    <IndexRedirect to="index"/>
    <Route path="index" component={PageHome}/>
    <Route path="article_list" component={PageArticleList}/>
    <Route path="category_list" component={PageCategoryList}/>
    <Route path="tag_list" component={PageTagList}/>
  </Route>

let router = <Router routes={routes} history={his}/>
ReactDOM.render(router, document.getElementById('App'))

Histories

需要依赖： ReactRouter.min.js

Histories

React Router 是建立在 history 之上的。
简而言之，一个 history 知道如何去监听浏览器地址栏的变化，
并解析这个 URL 转化为 location 对象，
然后 router 使用它匹配到路由，最后正确地渲染对应的组件。

常用的 history 有三种形式，
但是你也可以使用 React Router 实现自定义的 history。

• browserHistory
• hashHistory
• createMemoryHistory

你可以从 React Router 中引入它们：

// JavaScript 模块导入（译者注：ES6 形式）
import { browserHistory } from 'react-router'

然后将它们传递给<Router>:

render(
  <Router history={browserHistory} routes={routes} />,
  document.getElementById('app')
)

browserHistory

Browser history 是使用 React Router 的应用推荐的 history。它使用浏览器中的 History API 用于处理 URL，创建一个像example.com/some/path这样真实的 URL 。

服务器配置

服务器需要做好处理 URL 的准备。处理应用启动最初的 / 这样的请求应该没问题，但当用户来回跳转并在 /accounts/123 刷新时，服务器就会收到来自 /accounts/123 的请求，这时你需要处理这个 URL 并在响应中包含 JavaScript 应用代码。

一个 express 的应用可能看起来像这样的：

const express = require('express')
const path = require('path')
const port = process.env.PORT || 8080
const app = express()

// 通常用于加载静态资源
app.use(express.static(__dirname + '/public'))

// 在你应用 JavaScript 文件中包含了一个 script 标签
// 的 index.html 中处理任何一个 route
app.get('*', function (request, response){
  response.sendFile(path.resolve(__dirname, 'public', 'index.html'))
})

app.listen(port)
console.log("server started on port " + port)

如果你的服务器是 nginx，请使用 try_files 指令：

server {
  ...
  location / {
    try_files $uri /index.html
  }
}

当在服务器上找不到其他文件时，这可以让 nginx 服务器提供静态文件服务并指向index.html 文件。

对于Apache服务器也有类似的方式，创建一个.htaccess文件在你的文件根目录下：

RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]

IE8, IE9 支持情况

如果我们能使用浏览器自带的 window.history API，那么我们的特性就可以被浏览器所检测到。如果不能，那么任何调用跳转的应用就会导致 全页面刷新，它允许在构建应用和更新浏览器时会有一个更好的用户体验，但仍然支持的是旧版的。

你可能会想为什么我们不后退到 hash history，问题是这些 URL 是不确定的。如果一个访客在 hash history 和 browser history 上共享一个 URL，然后他们也共享同一个后退功能，最后我们会以产生笛卡尔积数量级的、无限多的 URL 而崩溃。

hashHistory

Hash history 使用 URL 中的 hash（#）部分去创建形如 example.com/#/some/path 的路由。

我应该使用 createHashHistory吗？

Hash history 不需要服务器任何配置就可以运行，如果你刚刚入门，那就使用它吧。但是我们不推荐在实际线上环境中用到它，因为每一个 web 应用都应该渴望使用 browserHistory。

像这样 ?_k=ckuvup 没用的在 URL 中是什么？

当一个 history 通过应用程序的 push 或 replace 跳转时，它可以在新的 location 中存储 “location state” 而不显示在 URL 中，这就像是在一个 HTML 中 post 的表单数据。

在 DOM API 中，这些 hash history 通过 window.location.hash = newHash 很简单地被用于跳转，且不用存储它们的location state。但我们想全部的 history 都能够使用location state，因此我们要为每一个 location 创建一个唯一的 key，并把它们的状态存储在 session storage 中。当访客点击“后退”和“前进”时，我们就会有一个机制去恢复这些 location state。

createMemoryHistory

Memory history 不会在地址栏被操作或读取。这就解释了我们是如何实现服务器渲染的。同时它也非常适合测试和其他的渲染环境（像 React Native ）。

和另外两种history的一点不同是你必须创建它，这种方式便于测试。

const history = createMemoryHistory(location)

实现示例

import React from 'react'
import { render } from 'react-dom'
import { browserHistory, Router, Route, IndexRoute } from 'react-router'

import App from '../components/App'
import Home from '../components/Home'
import About from '../components/About'
import Features from '../components/Features'

render(
  <Router history={browserHistory}>
    <Route path='/' component={App}>
      <IndexRoute component={Home} />
      <Route path='about' component={About} />
      <Route path='features' component={Features} />
    </Route>
  </Router>,
  document.getElementById('app')
)