HEX
Server: Apache/2.4.41 (Ubuntu)
System: Linux wordpress-ubuntu-s-2vcpu-4gb-fra1-01 5.4.0-169-generic #187-Ubuntu SMP Thu Nov 23 14:52:28 UTC 2023 x86_64
User: root (0)
PHP: 7.4.33
Disabled: pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,
Upload Files
File: /var/www/zaklada/html/node_modules/history/docs/HashHistoryCaveats.md
## Caveats of Using Hash History

Using `window.location.hash` is a common trick that is used to mimic the HTML5 history API in older browsers. It works for most use cases and provides good compatibility across a wide range of browsers. However, in order to preserve state across browser sessions we need a place to store some state.

HTML5 gives us the `pushState` method and the `popstate` event, but in older browsers the only thing we have is the URL. So, when using hash history, you'll see an extra item in your query string that looks something like `_k=123abc`. This is a key that `history` uses to look up persistent state data in `window.sessionStorage` between page loads. If you prefer to use a different query parameter, or to opt-out of this behavior entirely, use the `queryKey` configuration option.

```js
import createHistory from 'history/lib/createHashHistory'

// Use _key instead of _k.
let history = createHistory({
  queryKey: '_key'
})

// Opt-out of persistent state, not recommended.
let history = createHistory({
  queryKey: false
})
```

One other thing to keep in mind when using hash history is that you cannot also use `window.location.hash` as it was originally intended, to link an anchor point within your HTML document.