aspnetcore
aspnetcore copied to clipboard
dotnet
Blazor - Allow hashed routing
Hello there.
I have just been reading this in-depth guide.
In the section Client Routing the article states:
One caveat with routing is that it uses normal URLs and there is no hashed mode. That is, a
@page"/counter" will be accessible at the /counter URL and there is no option to use #/counter. While this is something desirable in most cases, it means that the server hosting the Blazor app should be configured to redirect all URLs that don’t match a static file to the index.html file, which will then bootstrap the application in the browser and will ultimately perform the navigation.
I have recently created a Angular app that required hashed routes, as it was purely client-side, the server was a MVC controller and I did not want my client making requests to the server... only for the server to redirect to index.html... plus I found that the server had trouble deciding between component and API routes.
I think hashed routes are a very important feature, and for my previous project they where a necessity.
Hope this is added in future.
I suppose we don't have to worry about base path with hash navigation, which is a plus.
Any chances this will be implemented? For example: I make apps which should be opened in iframe, so there is only way to use hash navigation.
Also, I suppose, hash navigation is the only option for hybrid mobile apps (cordova/capacitor).
I would also like to have the option to configure hash navigation. I'm deploying my Blazor WebAssembly to a server I don't have any control over, so I can't configure a catch all route to the index.html.
I'm trying to use Blazor WASM inside a Chrome extension and I can't reroute all requests to index.html. Hash routing would be helpful.
I'm migrating an old Asp.Net Web Forms site to Blazor. It's littered with hash routings for scrolling in-page. Changing href="#install" to "thispage#install" doesn't work. Implementing hash routing before net6 would be really welcome.
We ran into this same issue hosting a static Blazor SPA on a CDN. All status code have to redirect back to index.html. Seems strange since hashed routing is pretty standard at this point for SPAs.
There are numerous reasons for needing the ability to use hash routing. Is there a solid reason why this isn't implemented? Honestly, kind of expected Blazor to support this out of the box.
We'd like to host blazor wasm apps on GitHub Pages (not at the root) and it looks like the lack of hash based routing makes that difficult.
@rajsite I would recommend using the default routing, and only use hash routing if you can't avoid it. I guess we can't use hash routing atm anyway. You can deploy Blazor WASM to GitHub Pages without hash routing: https://swimburger.net/blog/dotnet/how-to-deploy-aspnet-blazor-webassembly-to-github-pages
@rajsite I would recommend using the default routing, and only use hash routing if you can't avoid it. I guess we can't use hash routing atm anyway. You can deploy Blazor WASM to GitHub Pages without hash routing: https://swimburger.net/blog/dotnet/how-to-deploy-aspnet-blazor-webassembly-to-github-pages
There are some useful workarounds in there, more-so if the blazor application is the only one on the pages site at root (which is not our scenario). Even if we did have a single blazor app at root, serving the 404 as the application is not ideal (like the blog hints at). All to say lack of hash based routing makes using GitHub Pages difficult (need workarounds and undesired trade-offs).
I think this is a necessity too. Modern browsers know about the #, other SPA frameworks use it and it gives SPA developers more capacity to avoid unnecessary round trips to the server.
I also hit an issue where the documented redirection URL from Azure AD authentication breaks when a Blazor WASM only SPA is hosted from a static website (Such as Azure storage static website) While I've a workaround, if a # could be configured in the redirect URL and Blazor handled #'s, then that would solve that problem too.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
What's the progress? I'm planning to deploy my website to ipfs, need to have this feature.
