Using hash history instead of browser history?

[chanand]

On previous versions we were able to pass a hash history to the connectRoutes function, like:

const history = createHashHistory()

export const {reducer, middleware, enhancer} = connectRoutes(
  history,
  routesMap,
  options
)

It seems like now, with history handled internally, there is no way to use hash history anymore, is that correct and intended?

[faceyspacey]

It's intended. Since ur bringing it up I'm not sure if it's correct :). If that's a problem I think the best solution is to add a createHistory option which takes a factory. That way people can use hash history or forks. But we have to actually call the factory internally now.

[faceyspacey]

Thanks for pointing this out.

There is now a createHistory option which you can pass the hash history to or your own fork/implementation etc. Eg:

import createHashHistory from 'history/createHashHistory'

connectRoutes(routesMap, { createHistory: createHashHistory })

Otherwise, for anyone reading this, if you're not passing your own createHistory factory, RFR will automatically pick the memory or browser history automatically for you based on the environment it detects. I.e. on the server or React Native it will pick createMemoryHistory and if in the browser it will pick createBrowserHistory :)

[faceyspacey]

Also, just fyi, it's only currently on the @rudy tag on NPM. so do yarn upgrade redux-first-router@rudy

[faceyspacey]

@chanand out of curiosity why are you choosing to use memory history? Are there any reasons outside of fallbacks to use hash history? Do you dynamically choose hash history for certain browsers? What logic do you use to make that determination?

It seems as far as SSR, it would pose some additional challenges. Basically in that case you have to determine the would-be path based on the hash and pass that to createMemoryHistory.

Also, the hash history doesn't work when pressing the back/next buttons in firefox without reloads.

I'm trying to determine if some automatic fallback to hash history in some cases might be of use to us. I'm currently thinking of just falling back to memoryHistory. I'm not a fan of forced reloads. My current thinking is that there's more value in just keeping the app running smoothly than letting a small percentage of users have URLs to hang on to. But perhaps it makes sense to fallback to hash history instead of memory history in some cases.

[chanand]

@faceyspacey I'm using the hash history because I'm deploying a single page app (with no SSR) while I have no control on the hosting server.

[schmidsi]

We're using hashHistory because we deploy to ipfs. So we have no control over the root, but also, serverside rendering is not even an option.

[deepfriedbrain]

Is there any example or documentation on using hashHistory?

My application doesn't have any use for SSR. It interacts with a Java-based server side application through REST APIs. The content on the client side is very dynamic resulting in thousands of unique URLs. I do not need to generate a new request for each behind a user login. hashHistory is a better fit than regular browserHistory for my use case.

I'm trying to use the @latest npm version.