Why?
The explanation I have heard is that memory history is supposed to be used server-side, or during testing where you have full control over the environment so can modify the URL however you want before calling into history.
Clientside, you're a lot more constrained in your deployment so basename is provided as a helper.
Wrong.
"server-side" must not be mentally separated from "client-side".
Javascript is isomorphic, React is, and if this library chooses not to then it's out of my preferences.
@halt-hammerzeit Pull requests. Use them.
@halt-hammerzeit The explanation given by @KaySackey is exactly right. When using memory history, you have complete control over what the URL is. In the browser, you don't. It's not a question of "mentally separating" server-side vs. client. Memory history isn't even supposed to be used on the server. Instead, it's used for testing, native, vr, and other scenarios where you're not constrained by the browser. In these situations, you have full control over what the URL is, so basename is totally superfluous.
Memory history isn't even supposed to be used on the server.
Then what does this library provide for server-side usage?
Nothing?
Then it's not worthy.
Instead, it's used for testing
Yeah, go test that basenamed client side browser history code you people
history is a JavaScript library that lets you easily manage session history anywhere JavaScript runs.
Whaaaaat?
Realy?
Oh, I get it, that's a bug in your README.
Fear not, I'M MAKING A PR.
YEAH, LIKE A GOOD CONTRIBUTOR.
@ryancole Yo, man, check this out: https://github.com/mjackson/history/pull/410
Happy now?
@halt-hammerzeit Sorry, but this behavior is super childish. You're blocked.
When using memory history, you have complete control over what the URL is. In
This is only true if you're using the history directly, but not if you pass it to a library that allows you to pass any history object. E.g. a very common use for the history api is react-router. In an isomorphic app you would use browserHistory client-side, and memoryHistory serverside. This works as long as you don't use a basename, but as soon as you want a basename you run into issues. Most prominently, the <link> component uses the history object to create urls. This means that if you use a browserHistory (with basename) clientside you'll get different urls than on the server (because there is no basename). I might be missing something obvious, but it seems that currently it simply isn't possible to use a basename in an isomorphic app since memoryHistory lacks support for it.
I also like to add that this is specifically an issue when using react-router-redux: without redux you can use the StaticRouter which has its own basename support.
Most helpful comment
This is only true if you're using the history directly, but not if you pass it to a library that allows you to pass any history object. E.g. a very common use for the
historyapi isreact-router. In an isomorphic app you would usebrowserHistoryclient-side, andmemoryHistoryserverside. This works as long as you don't use a basename, but as soon as you want a basename you run into issues. Most prominently, the<link>component uses the history object to create urls. This means that if you use abrowserHistory(with basename) clientside you'll get different urls than on the server (because there is no basename). I might be missing something obvious, but it seems that currently it simply isn't possible to use a basename in an isomorphic app sincememoryHistorylacks support for it.