You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While route components get `this.props.history` and the `History` mixin
4
-
provides `this.history`, many apps want to be able to navigate outside
5
-
of their components.
6
-
7
-
Its pretty simple, just hang on to your history object:
8
-
9
-
You can have a module in your app somewhere that exports your history
10
-
object.
3
+
While route components get `this.props.router`, and `Router` puts on context `this.context.router` to navigate around, many apps want to be able to navigate outside of their components. They can do that with the history the app gives to `Router`.
This is the default history you'll get if you don't specify a history at all (i.e. `<Router>{/* your routes */}</Router>`). It uses the hash (`#`) portion of the URL creating routes that look like `example.com/#/some/path`.
32
+
### `hashHistory`
33
+
Hash history uses the hash (`#`) portion of the URL, creating routes that look like `example.com/#/some/path`.
38
34
39
-
#### Should I use `createHashHistory`?
40
-
Hash history is the default because it works without any setup on your server, and works in all evergreen browsers and IE8+. But, we don't recommend using it in production, every web app should aspire to use `createBrowserHistory`.
35
+
#### Should I use `hashHistory`?
36
+
Hash history works without configuring your server, so if you're just getting started, go ahead and use it. But, we don't recommend using it in production, every web app should aspire to use `browserHistory`.
41
37
42
38
#### What is that `?_k=ckuvup` junk in the URL?
43
-
When a history transitions around your app with `pushState` or `replaceState`, it can store "location state" on the new location that doesn't show up in the URL, think of it a little bit like post data in an HTML form.
39
+
When a history transitions around your app with `push` or `replace`, it can store "location state" that doesn't show up in the URL on the new location, think of it a little bit like post data in an HTML form.
44
40
45
41
The DOM API that hash history uses to transition around is simply `window.location.hash = newHash`, with no place to store location state. But, we want all histories to be able to use location state, so we shim it by creating a unique key for each location and then store that state in session storage. When the visitor clicks "back" and "forward" we now have a mechanism to restore the location state.
46
42
47
-
You can disable that feature (more [here](http://rackt.org/history/stable/HashHistoryCaveats.html)):
48
-
```js
49
-
// Opt-out of persistent state, not recommended.
50
-
let history =createHashHistory({
51
-
queryKey:false
52
-
});
53
-
```
54
-
55
-
### `createBrowserHistory`
43
+
### `browserHistory`
56
44
Browser history is the recommended history for browser application with React Router. It uses the [History](https://developer.mozilla.org/en-US/docs/Web/API/History) API built into the browser to manipulate the URL, creating real URLs that look like `example.com/some/path`.
57
45
58
46
#### Configuring Your Server
@@ -100,6 +88,12 @@ You might wonder why we don't fall back to hash history; the problem is that URL
100
88
### `createMemoryHistory`
101
89
Memory history doesn't manipulate or read from the address bar. This is how we implement server rendering. It's also useful for testing and other rendering environments (like React Native).
102
90
91
+
Its a bit different than the other two histories because you have to
92
+
create one, it is this way to facilitate testing:
93
+
94
+
```js
95
+
consthistory=createMemoryHistory(location)
96
+
```
103
97
104
98
## Example implementation
105
99
@@ -109,15 +103,15 @@ app, the client entry point would look like:
0 commit comments