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
This is the default history you'll get if you don't specify a history at
27
-
all (i.e. `<Router>{/* your routes */}</Router>`). It uses the hash
28
-
(`#`) portion of the url creating routes that look like
29
-
`example.com/#/some/path`.
26
+
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`.
30
27
31
28
#### Should I use `createHashHistory`?
32
-
Hash history is the default because it works without any setup on your
33
-
server, and works in all evergreen browsers and IE8+. But, we don't
34
-
recommend using it in production, every web app should aspire
35
-
to use `createBrowserHistory`.
29
+
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`.
36
30
37
31
#### What is that `?_k=ckuvup` junk in the URL?
38
-
When a history transitions around your app with `pushState` or
39
-
`replaceState`, it can store "location state" on the new location that
40
-
doesn't show up in the URL, think of it a little bit like post data in
41
-
an HTML form.
42
-
43
-
The DOM API that hash history uses to transition around is simply
44
-
`window.location.hash = newHash`, with no place to store location state.
45
-
But, we want all histories to be able to use location state, so we shim
46
-
it by creating a unique key for each location and then store that state
47
-
in session storage. When the visitor clicks "back" and "forward" we now
48
-
have a mechanism to restore the location state.
32
+
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.
33
+
34
+
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.
49
35
50
36
### `createBrowserHistory`
51
-
Browser history is the recommended history for browser application with
52
-
React Router. It uses the [History](https://developer.mozilla.org/en-US/docs/Web/API/History)
53
-
API built into the browser to manipulate the url, creating real urls that
54
-
look like `example.com/some/path`.
37
+
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`.
55
38
56
39
#### Configuring Your Server
57
-
Your server must be ready to handle real urls. When the app first loads
58
-
at `/` it will probably work, but as the user navigates around and then
59
-
hits refresh at `/accounts/23` your web server will get a request to
60
-
`/accounts/23`. You will need it to handle that url and include your
61
-
JavaScript application in the response.
40
+
Your server must be ready to handle real URLs. When the app first loads at `/` it will probably work, but as the user navigates around and then hits refresh at `/accounts/23` your web server will get a request to `/accounts/23`. You will need it to handle that URL and include your JavaScript application in the response.
62
41
63
42
A quick example with express:
64
43
@@ -82,31 +61,22 @@ console.log("server started on port " + port)
82
61
```
83
62
84
63
#### IE8, IE9 Support
85
-
We feature detect to see if we can use the browser's native `History`
86
-
API, if not, any call to transition around the app will result in _a
87
-
full page reload_, which allows you to build your app and have a better
88
-
experience for newer browsers, but still support old ones.
64
+
We feature detect to see if we can use the browser's native `window.history` API. If not, any call to transition around the app will result in _a full page reload_, which allows you to build your app and have a better experience for newer browsers, but still support old ones.
89
65
90
-
You might wonder why we don't fall back to hash history; the problem is
91
-
that urls become non-deterministic. If a visitor on hash history shares
92
-
a url with a visitor on browser history, and then they share that back,
93
-
we end up with a terrible cartesian product of infinite potential
94
-
urls.
66
+
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.
95
67
96
68
### `createMemoryHistory`
97
-
Memory history doesn't manipulate or read from the address bar. This is
98
-
how we implement server rendering, its also useful for testing and other
99
-
rendering environments (like React Native).
69
+
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).
0 commit comments