原文: [A little bit of history](https://medium.com/@pshrmn/a-little-bit-of-history-f245306f48dd)
If you wish to understand React Router, you must first study history. More specifically, the [history](https://github.com/ReactTraining/history) package, which provides the core functionality for React Router. It enables projects to easily add location based navigation on the client-side, which is essential for single page applications.
If you are using React Router, it can automatically create history objects for you, so you may never have to actually interact with history directly. Still, it is important to understand the differences between each type of history so that you can determine which one is right for your project.
No matter which type of history you create, you will end up with an object that has nearly the same properties and methods.
> 不论你创建了哪种类型的history，你都将得到一个具有几乎相同属性和方法的对象。
#### Location 位置
The most important property of a history object is the location. The location object reflects “where” your application currently is. It contains a number of properties that are derived from a URL. These are `pathname`, `search`[1], and `hash`.
> history 对象最重要的属性是location。location对象反映了你的应用程序当前所在的位置。它包含了从URL派生过来的若干属性。即`pathname`,`search`[1] ,和`hash`。
Additionally, each location has a unique `key` property associated with it. This key can be used to identify and store data specific to a location.
When a history object is created, it will need an initial location. How this is determined is different for each type of history. For example, the browser history will parse the current URL.
> 当一个 history 对象被创建，它就会需要一个初始的 location。在各种类型的 history 中，如何确定这个初始位置是不同的。例如，`browser history`会将当前的URL转换未初始 location。
#### One location to rule them all?
While there is only one current location that we can access, the history object keeps track of an array of locations. The ability to add locations and move throughout the location array is what makes history “history”. If history only knew about the current location, it would be more aptly named “present”.
> 虽然我们只能访问一个当前位置，但是 history 对象会跟踪一组 location 。能在 location 数组中完成添加和移动的能力让 history 成为真正的 “history”。如果 history 只知道当前的 location，那么它被叫成 “present” 可能会更合适一点。
In addition to an array of locations, the history also maintains an index value, which refers to the position of current location in the array.
For the memory history, these are explicitly defined. For both the browser and hash histories, the array and index is controlled by the browser and cannot be directly accessed [2].
> 对与 memory history ，这些是明确定义的额。对于 browser 和 hash history，location 数组和 index 索引值都是被浏览器控制并且不可直接访问的[2]。
#### Navigation 导航
An object with a location property isn’t particularly exciting. Where a history object starts to become interesting is with the navigation methods. Navigation methods allow you to change the current location.
The `push` method allows you to go to a new location. This will add a new location to the array after the current location. When this happens, any “future” locations (ones that exist in the array after the current location because of use of the back button) will be dropped.
The `replace` method is similar to `push`, but instead of adding a new location, it will replace the location at the current index. “Future” locations will not be dropped.
For example, if you are on one page and click a link that navigates to a second page, that second page might redirect to a third page. If the redirect uses `push`, clicking the back button from the third will bring you back to the second page (which potentially would redirect you back to the third page again). Instead, by using `replace`, going back from the third page will take you to the first.
> 例如，如果你在一个页面上点击了一个 link 导航到第二个页面上，第二个页面可能重定向到第三个页面。如果重定向使用了 `push` ，在第三个页面点击后退按钮将会带你回到第二个页面（第二个页面可能会再次将你重定向到第三个页面上）。相反，使用 `replace` 从第三页将带你回到第一页。
```
history.replace({ pathname: '/go-here-instead' })
```
#### Go, go, go
Finally, there are three related methods: `goBack`, `goForward`, and `go`.
> 最后，有三个相关的方法：`goBack` ，`goForward` ，and `go`。
`goBack` goes back one page. This essentially decrements the index in the locations array by one.
> `goBack` 回退一页。它实质上将 location 数组上的 index 减 1。
```
history.goBack()
```
`goForward` is the opposite of `goBack`, going forward one page. It will only work when there are “future” locations to go to, which happens when the user has clicked the back button.
`go` is a more powerful combination of `goBack` and `goForward`. Negative numbers passed to the method will be used to go backwards in the array, and positive numbers will be used to go forward.
History uses the [observer pattern](https://en.wikipedia.org/wiki/Observer_pattern) to allow outside code to be notified when the location changes.
> history 使用[`观察者模式（observer pattern）`](https://en.wikipedia.org/wiki/Observer_pattern) 来允许外部代码在 location 改变时接收通知。
Each history object has a `listen` method, which takes a function as its argument. That function will be added to an array of listener functions that the history stores. Any time the location changes (whether this is by your code calling one of the history methods or because a user clicked a browser button), the history object will call all of its listener functions. This allows you to setup code that will update whenever the location changes.
> 每种 history 对象都有一个 `listen` 方法，接收一个 function 作为参数。这个 function 将被添加到一个 history 存储的监听函数数组中。一旦 location 变动（不论是你的代码调用了一个 history 方法还是一个用户点击了浏览器按钮），history 对象将会调用所有的监听函数。这允许你编写一些在 location 变化时更新的代码。
A React Router’s router component will subscribe to its history object so that it can re-render whenever the location changes.
> React Router 的路由组件会订阅他的 history 对象，这样无论合适 location 发生了变化，它都能重新渲染。
#### Linking things together
Each history type also has a `createHref` method that can take a location object and output a URL.
> 每种类型的 history 都有一个 `createHref`方法，接收一个 location 对象，输出一个 URL。
Internally, history can navigate using location objects. However, any code that is unaware of the history package, such as anchor elements (`<a>`), does not know what location objects are. In order to generate HTML that will still properly navigate without knowledge of history, we must be able to generate real URLs.
> 在内部，history 可以用 location 对象导航。但是，任何不接触 history 包的代码，例如锚元素（`<a>`）,都不知道 location 对象是什么。为了生成在不了解 history 的情况下仍然能够正确导航的 HTML，我们必须生成真实的 URL。
That covers the essential history API. There are a couple more properties and methods, but the above should be enough to have a solid understanding of how to work with a history object.
> 这覆盖了必要的 history API。还有一些属性和方法，但是上面这些应该足够让你充分了解如何使用 history 对象。
### With our powers combined
There are some differences between the history types that you will need to consider when deciding which is best suited for your project. Between the three of them, any use case should be covered.
> 在决定哪种类型最适合你的项目时，有一些 history 类型之间的差异你需要考虑。在这三者之间，应该覆盖任何用例。
#### In the Browser
Browser and hash histories are both intended to be used in a browser. They interact with the [history](https://developer.mozilla.org/en-US/docs/Web/API/History) and [location](https://developer.mozilla.org/en-US/docs/Web/API/Location) web APIs so that the current location is the same as the one displayed in your browser’s address bar.
> Browser 和 hash history 都是在浏览器中使用的。它们与 [history](https://developer.mozilla.org/en-US/docs/Web/API/History) 和 [location](https://developer.mozilla.org/en-US/docs/Web/API/Location) web API交互，所以 current location 与浏览器地址栏中显示的是一样的。
```
const browserHistory = createBrowserHistory()
const hashHistory = createHashHistory()
```
The biggest difference between the two is how they create a location from a URL. The browser history uses the full URL [3], while the hash history only uses the portion of the URL located after the first hash symbol.
> 这两者最大的不同是它们如何从一个 URL 创建 location。browser history 将会使用完整 URL[3]，然而 hash history 只会用 URL 中位于第一个 hash 符号（#）之后的部分。
For servers that can respond to dynamic requests, the requested file does not actually have to exist. Instead, the server will examine the requested URL and decide what HTML to respond with.
However, a static file server can only return the files that exist on the disk. The most dynamic thing that a static server can do is to return the `index.html` file from a directory when the URL only specifies the directory.
**Update 4/25/18**: I wrote a small article about [Single-Page Applications and the Server](https://medium.com/@pshrmn/single-page-applications-and-the-server-32a23d67936) that should help clarify the different ways a single-page application can be hosted.
> **Update 4/25/18**: 我写了一篇小文关于[Single-Page Applications and the Server](https://medium.com/@pshrmn/single-page-applications-and-the-server-32a23d67936)，应该能够帮助阐明单页面应用程序能够托管的不同方法。
Given the limitations imposed by a static file server, the simplest solution [4] for serving your application is to only have one “real” location on your server to fetch your HTML from. Of course, only having one location means only having one URL for your application, which would defeat the purpose of using history. To get around this limitation, the hash history uses the hash section of the URL to set and read locations.
> 考虑到静态文件服务器施加的限制，为你的应用程序提供服务的最简单的解决方案[4]就是在服务器上只有一个真实的 location 来获取 HTML。当然，只有一个位置意味着你的应用程序只有一个 URL，这破坏了 history 的目的。为了解决这个限制，hash history 使用 URL 的 hash 部分来设置和读取 location。
```
// If example.com uses a static file server, these URLs would
// both fetch html from /my-site/index.html
http://www.example.com/my-site#/one
http://www.example.com/my-site#/two
// However, with a hash history, an application's location will be
// different for each URL because the location is derived from
// the hash section of the URL
{ pathname: '/one' }
{ pathname: '/two' }
```
While the hash history works well, it can be considered a bit of a hack because of its reliance on the storing all of the path information in the hash of a URL. Therefore, it should only be considered when your website does not have a dynamic server to server your HTML.
> 虽然 hash history 工作得很好，但是由于它依赖与将所有 location 信息保存在 URL 的 hash 中，因此可以认为这种方法有一点点 hack。所以当你的网站没有动态服务器来服务你的 HTML 时可以考虑这种方法。
#### Memory: The Catch-all History
The best thing about memory location is that you can use it anywhere that you can run JavaScript.
> 关于 memory history 的最好的事情是你能在任何可以运行 JavaScript 的地方使用它。
A simple example is that you can use it in unit tests run via Node. That allows you to test code that relies on a history object without having to actually test with a browser.
> 一个简单的例子是你可以在 Node 中运行的单元测试中使用它。这允许你测试一些依赖 history 对象的代码而不必真的用一个浏览器来测试。
More importantly, you can also use a memory history in mobile apps. A memory history is used by `react-router-native` to enable location based navigation in `react-native` apps.
> 更重要的是，你也可以在移动端 app 中使用它。memory history 被`react-router-native` 用于允许在`react-native`app中使用基于 location 的导航。
If you really wanted, you could even use a memory history in the browser (although you would be losing the integration with the address bar).
The biggest difference between the memory history and the browser and hash histories is that it maintains its own in-memory array of locations. When creating a memory history you can pass information to setup the initial state. This state would be an array of locations and the index of the “current” location in that array [5]. This is different from the browser and hash histories, which rely on the browser to already be storing the array of locations.
While you can roll your own history equivalent code, there are a lot of little gotchas in how browsers handle navigation that can cause a headache. Instead, it is probably easier to rely on history to think about these things for you.
> 虽然你可以创造出自己的 history 等效的代码，但是又很多关于浏览器如何处理导航的小问题会让人头痛。相反，利用 history 对象来思考这些事情可能会更简单。
No matter which history type you end up choosing you will end up with a simple to implement, but powerful way to perform navigation and location-based rendering in your application.
> 不论你最后选用了哪一种 history 类型，你都将得到一个简单易用，但是在应用程序中处理导航和基于位置的渲染的强大方法。
### Notes
[1] The `search` property is a string instead of a parsed object. This is because there are different search string parsing packages that handle some cases slightly differently. Instead of imposing one way to parse search strings, history leaves it up to you to decide how to parse the string. If you are looking for a way to parse search strings, some popular options are [qs](https://www.npmjs.com/package/qs), [query-string](https://www.npmjs.com/package/query-string), [querystring](https://www.npmjs.com/package/querystring), and the native [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams).
[2] This restriction is out of security. The browser’s history’s location array contains more than just the locations that have been visited within your application. Allowing access to this list would leak information about a user’s browsing history that websites should not be allowed access to.
[3] By default, the browser history creates location objects whose `pathname` is the URL’s full pathname. However, you can specify a basename for a history, in which case a portion of the full pathname will be effectively ignored.
```
const history = createBrowserHistory({ basename: '/path' })
// given the url: http://www.example.com/path/here
// the history object will create the location
{ pathname: '/here', ... }
```
[4] Theoretically you could serve the same HTML file from every valid URL in your application. If all of your URLs are static, this *could* work, but it would create lots of redundant files. If any of your URLs use parameters to match a large number of possible values, this is infeasible.
[5] If you do not provide a memory history with initial locations and index, it will fallback to default values:
```
entries = [{ pathname: '/' }]
index = 0
```
This might be good enough for most applications, but being able to pre-populate the history can be very useful for things like session restoration.
原文: [A little bit of history](https://medium.com/@pshrmn/a-little-bit-of-history-f245306f48dd)
If you wish to understand React Router, you must first study history. More specifically, the [history](https://github.com/ReactTraining/history) package, which provides the core functionality for React Router. It enables projects to easily add location based navigation on the client-side, which is essential for single page applications.
If you are using React Router, it can automatically create history objects for you, so you may never have to actually interact with history directly. Still, it is important to understand the differences between each type of history so that you can determine which one is right for your project.
No matter which type of history you create, you will end up with an object that has nearly the same properties and methods.
> 不论你创建了哪种类型的history，你都将得到一个具有几乎相同属性和方法的对象。
#### Location 位置
The most important property of a history object is the location. The location object reflects “where” your application currently is. It contains a number of properties that are derived from a URL. These are `pathname`, `search`[1], and `hash`.
> history 对象最重要的属性是location。location对象反映了你的应用程序当前所在的位置。它包含了从URL派生过来的若干属性。即`pathname`,`search`[1] ,和`hash`。
Additionally, each location has a unique `key` property associated with it. This key can be used to identify and store data specific to a location.
When a history object is created, it will need an initial location. How this is determined is different for each type of history. For example, the browser history will parse the current URL.
> 当一个 history 对象被创建，它就会需要一个初始的 location。在各种类型的 history 中，如何确定这个初始位置是不同的。例如，`browser history`会将当前的URL转换未初始 location。
#### One location to rule them all?
While there is only one current location that we can access, the history object keeps track of an array of locations. The ability to add locations and move throughout the location array is what makes history “history”. If history only knew about the current location, it would be more aptly named “present”.
> 虽然我们只能访问一个当前位置，但是 history 对象会跟踪一组 location 。能在 location 数组中完成添加和移动的能力让 history 成为真正的 “history”。如果 history 只知道当前的 location，那么它被叫成 “present” 可能会更合适一点。
In addition to an array of locations, the history also maintains an index value, which refers to the position of current location in the array.
For the memory history, these are explicitly defined. For both the browser and hash histories, the array and index is controlled by the browser and cannot be directly accessed [2].
> 对与 memory history ，这些是明确定义的额。对于 browser 和 hash history，location 数组和 index 索引值都是被浏览器控制并且不可直接访问的[2]。
#### Navigation 导航
An object with a location property isn’t particularly exciting. Where a history object starts to become interesting is with the navigation methods. Navigation methods allow you to change the current location.
The `push` method allows you to go to a new location. This will add a new location to the array after the current location. When this happens, any “future” locations (ones that exist in the array after the current location because of use of the back button) will be dropped.
The `replace` method is similar to `push`, but instead of adding a new location, it will replace the location at the current index. “Future” locations will not be dropped.
For example, if you are on one page and click a link that navigates to a second page, that second page might redirect to a third page. If the redirect uses `push`, clicking the back button from the third will bring you back to the second page (which potentially would redirect you back to the third page again). Instead, by using `replace`, going back from the third page will take you to the first.
> 例如，如果你在一个页面上点击了一个 link 导航到第二个页面上，第二个页面可能重定向到第三个页面。如果重定向使用了 `push` ，在第三个页面点击后退按钮将会带你回到第二个页面（第二个页面可能会再次将你重定向到第三个页面上）。相反，使用 `replace` 从第三页将带你回到第一页。
```
history.replace({ pathname: '/go-here-instead' })
```
#### Go, go, go
Finally, there are three related methods: `goBack`, `goForward`, and `go`.
> 最后，有三个相关的方法：`goBack` ，`goForward` ，and `go`。
`goBack` goes back one page. This essentially decrements the index in the locations array by one.
> `goBack` 回退一页。它实质上将 location 数组上的 index 减 1。
```
history.goBack()
```
`goForward` is the opposite of `goBack`, going forward one page. It will only work when there are “future” locations to go to, which happens when the user has clicked the back button.
`go` is a more powerful combination of `goBack` and `goForward`. Negative numbers passed to the method will be used to go backwards in the array, and positive numbers will be used to go forward.
History uses the [observer pattern](https://en.wikipedia.org/wiki/Observer_pattern) to allow outside code to be notified when the location changes.
> history 使用[`观察者模式（observer pattern）`](https://en.wikipedia.org/wiki/Observer_pattern) 来允许外部代码在 location 改变时接收通知。
Each history object has a `listen` method, which takes a function as its argument. That function will be added to an array of listener functions that the history stores. Any time the location changes (whether this is by your code calling one of the history methods or because a user clicked a browser button), the history object will call all of its listener functions. This allows you to setup code that will update whenever the location changes.
> 每种 history 对象都有一个 `listen` 方法，接收一个 function 作为参数。这个 function 将被添加到一个 history 存储的监听函数数组中。一旦 location 变动（不论是你的代码调用了一个 history 方法还是一个用户点击了浏览器按钮），history 对象将会调用所有的监听函数。这允许你编写一些在 location 变化时更新的代码。
A React Router’s router component will subscribe to its history object so that it can re-render whenever the location changes.
> React Router 的路由组件会订阅他的 history 对象，这样无论合适 location 发生了变化，它都能重新渲染。
#### Linking things together
Each history type also has a `createHref` method that can take a location object and output a URL.
> 每种类型的 history 都有一个 `createHref`方法，接收一个 location 对象，输出一个 URL。
Internally, history can navigate using location objects. However, any code that is unaware of the history package, such as anchor elements (`<a>`), does not know what location objects are. In order to generate HTML that will still properly navigate without knowledge of history, we must be able to generate real URLs.
> 在内部，history 可以用 location 对象导航。但是，任何不接触 history 包的代码，例如锚元素（`<a>`）,都不知道 location 对象是什么。为了生成在不了解 history 的情况下仍然能够正确导航的 HTML，我们必须生成真实的 URL。
That covers the essential history API. There are a couple more properties and methods, but the above should be enough to have a solid understanding of how to work with a history object.
> 这覆盖了必要的 history API。还有一些属性和方法，但是上面这些应该足够让你充分了解如何使用 history 对象。
### With our powers combined
There are some differences between the history types that you will need to consider when deciding which is best suited for your project. Between the three of them, any use case should be covered.
> 在决定哪种类型最适合你的项目时，有一些 history 类型之间的差异你需要考虑。在这三者之间，应该覆盖任何用例。
#### In the Browser
Browser and hash histories are both intended to be used in a browser. They interact with the [history](https://developer.mozilla.org/en-US/docs/Web/API/History) and [location](https://developer.mozilla.org/en-US/docs/Web/API/Location) web APIs so that the current location is the same as the one displayed in your browser’s address bar.
> Browser 和 hash history 都是在浏览器中使用的。它们与 [history](https://developer.mozilla.org/en-US/docs/Web/API/History) 和 [location](https://developer.mozilla.org/en-US/docs/Web/API/Location) web API交互，所以 current location 与浏览器地址栏中显示的是一样的。
```
const browserHistory = createBrowserHistory()
const hashHistory = createHashHistory()
```
The biggest difference between the two is how they create a location from a URL. The browser history uses the full URL [3], while the hash history only uses the portion of the URL located after the first hash symbol.
> 这两者最大的不同是它们如何从一个 URL 创建 location。browser history 将会使用完整 URL[3]，然而 hash history 只会用 URL 中位于第一个 hash 符号（#）之后的部分。
For servers that can respond to dynamic requests, the requested file does not actually have to exist. Instead, the server will examine the requested URL and decide what HTML to respond with.
However, a static file server can only return the files that exist on the disk. The most dynamic thing that a static server can do is to return the `index.html` file from a directory when the URL only specifies the directory.
**Update 4/25/18**: I wrote a small article about [Single-Page Applications and the Server](https://medium.com/@pshrmn/single-page-applications-and-the-server-32a23d67936) that should help clarify the different ways a single-page application can be hosted.
> **Update 4/25/18**: 我写了一篇小文关于[Single-Page Applications and the Server](https://medium.com/@pshrmn/single-page-applications-and-the-server-32a23d67936)，应该能够帮助阐明单页面应用程序能够托管的不同方法。
Given the limitations imposed by a static file server, the simplest solution [4] for serving your application is to only have one “real” location on your server to fetch your HTML from. Of course, only having one location means only having one URL for your application, which would defeat the purpose of using history. To get around this limitation, the hash history uses the hash section of the URL to set and read locations.
> 考虑到静态文件服务器施加的限制，为你的应用程序提供服务的最简单的解决方案[4]就是在服务器上只有一个真实的 location 来获取 HTML。当然，只有一个位置意味着你的应用程序只有一个 URL，这破坏了 history 的目的。为了解决这个限制，hash history 使用 URL 的 hash 部分来设置和读取 location。
```
// If example.com uses a static file server, these URLs would
// both fetch html from /my-site/index.html
http://www.example.com/my-site#/one
http://www.example.com/my-site#/two
// However, with a hash history, an application's location will be
// different for each URL because the location is derived from
// the hash section of the URL
{ pathname: '/one' }
{ pathname: '/two' }
```
While the hash history works well, it can be considered a bit of a hack because of its reliance on the storing all of the path information in the hash of a URL. Therefore, it should only be considered when your website does not have a dynamic server to server your HTML.
> 虽然 hash history 工作得很好，但是由于它依赖与将所有 location 信息保存在 URL 的 hash 中，因此可以认为这种方法有一点点 hack。所以当你的网站没有动态服务器来服务你的 HTML 时可以考虑这种方法。
#### Memory: The Catch-all History
The best thing about memory location is that you can use it anywhere that you can run JavaScript.
> 关于 memory history 的最好的事情是你能在任何可以运行 JavaScript 的地方使用它。
A simple example is that you can use it in unit tests run via Node. That allows you to test code that relies on a history object without having to actually test with a browser.
> 一个简单的例子是你可以在 Node 中运行的单元测试中使用它。这允许你测试一些依赖 history 对象的代码而不必真的用一个浏览器来测试。
More importantly, you can also use a memory history in mobile apps. A memory history is used by `react-router-native` to enable location based navigation in `react-native` apps.
> 更重要的是，你也可以在移动端 app 中使用它。memory history 被`react-router-native` 用于允许在`react-native`app中使用基于 location 的导航。
If you really wanted, you could even use a memory history in the browser (although you would be losing the integration with the address bar).
The biggest difference between the memory history and the browser and hash histories is that it maintains its own in-memory array of locations. When creating a memory history you can pass information to setup the initial state. This state would be an array of locations and the index of the “current” location in that array [5]. This is different from the browser and hash histories, which rely on the browser to already be storing the array of locations.
While you can roll your own history equivalent code, there are a lot of little gotchas in how browsers handle navigation that can cause a headache. Instead, it is probably easier to rely on history to think about these things for you.
> 虽然你可以创造出自己的 history 等效的代码，但是又很多关于浏览器如何处理导航的小问题会让人头痛。相反，利用 history 对象来思考这些事情可能会更简单。
No matter which history type you end up choosing you will end up with a simple to implement, but powerful way to perform navigation and location-based rendering in your application.
> 不论你最后选用了哪一种 history 类型，你都将得到一个简单易用，但是在应用程序中处理导航和基于位置的渲染的强大方法。
### Notes
[1] The `search` property is a string instead of a parsed object. This is because there are different search string parsing packages that handle some cases slightly differently. Instead of imposing one way to parse search strings, history leaves it up to you to decide how to parse the string. If you are looking for a way to parse search strings, some popular options are [qs](https://www.npmjs.com/package/qs), [query-string](https://www.npmjs.com/package/query-string), [querystring](https://www.npmjs.com/package/querystring), and the native [URLSearchParams](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams).
[2] This restriction is out of security. The browser’s history’s location array contains more than just the locations that have been visited within your application. Allowing access to this list would leak information about a user’s browsing history that websites should not be allowed access to.
[3] By default, the browser history creates location objects whose `pathname` is the URL’s full pathname. However, you can specify a basename for a history, in which case a portion of the full pathname will be effectively ignored.
```
const history = createBrowserHistory({ basename: '/path' })
// given the url: http://www.example.com/path/here
// the history object will create the location
{ pathname: '/here', ... }
```
[4] Theoretically you could serve the same HTML file from every valid URL in your application. If all of your URLs are static, this *could* work, but it would create lots of redundant files. If any of your URLs use parameters to match a large number of possible values, this is infeasible.
[5] If you do not provide a memory history with initial locations and index, it will fallback to default values:
```
entries = [{ pathname: '/' }]
index = 0
```
This might be good enough for most applications, but being able to pre-populate the history can be very useful for things like session restoration.
