2

On every react-router v6 documentation page which mentions HashRouter there is a short warning text stating that this kind of routing is not recommended. There is no explanation why.

Are there any major disadvantages? Does it break any api somehow?

jligeza
  • 4,544
  • 6
  • 23
  • 31

2 Answers2

2

Short answer.... some devs think hash routing produces "ugly" URLs... but no, really, hash routing serves a purpose where perhaps the server environment isn't setup to handle current HTML or otherwise needs to handle all page requests at a static URL.

This is about as much explanation as the docs provide.

HashRouter

<HashRouter> is for use in web browsers when the URL should not (or cannot) be sent to the server for some reason. This may happen in some shared hosting scenarios where you do not have full control over the server. In these situations, <HashRouter> makes it possible to store the current location in the hash portion of the current URL, so it is never sent to the server.

It's basically, "Only use hash routing if that's what you need and you know what you are doing." I think it's generally the case that if you don't really know what you are doing or need that you really just need the BrowserRouter.

Are there any major disadvantages? Does it break any api somehow?

I wouldn't say there are major disadvantages to using the HashRouter, it just serves a different purpose, like the NativeRouter on native mobile devices, or the MemoryRouter in node environments. I don't know if you are asking if it breaks any specific APIs using the HashRouter, but I'm inclined to say no, it still works with redux, fetch/axios, etc... and just about anything else I can think of I've used along with hash routing.

Drew Reese
  • 165,259
  • 14
  • 153
  • 181
  • 1
    How is it serving different purpose compared to `BrowserRouter`? Looks like it duplicates its functionality when it comes to routing in SPAs, as both of them can be used interchangeably. – jligeza Oct 26 '22 at 09:33
  • @jligeza Are you asking about this from the React app's perspective? If so, then yeah, routing and navigation is routing and navigation, that's why it doesn't have any "major disadvantages" or break apis, etc. Where they differ is in their use cases, i.e. where one needs to be used instead of the other. For example, if you deploy your app to Github, they don't support HTML5 so you can't use a `BrowserRouter` there. In other words, which you need to use depends on external (*to the app*) constraints by the server environment where the app is deployed. Does this make sense? – Drew Reese Oct 26 '22 at 15:51
  • 1
    Okay, so in the end it is "ugly" url and no extra server configuration required vs. "pretty" url with requirement of extra server configuration. – jligeza Oct 26 '22 at 17:24
1

Short answer: If your site is static, use whatever, it does not matter. But if you have a backend, using hash routing is recommended aproach, and not just for react.

Explanation: When hash is used, only your frontend application gets the request, no calls are made to backend. This is important for production enviroments, where you have some backened and/or some reverse proxy(like NGINX etc.), API Gateway etc. Without hash, request will need to be handled by them first, and if no endpoint is found, request is sent to frontend. This creates unnecessary calls, which leads to performance issues, unhandled paths, etc.. And in modern cloud enviroments, this means more money.

MarkoDM
  • 69
  • 1
  • 4
  • Just to add. You can use without hash, and handle all as needed, you will not make a mistake. Somethimes is better, somethimes not. That needs to be evaluetad on project basis, setup and needs. – MarkoDM Nov 01 '22 at 08:29