tawny atlas
Hi everyone,
I'm trying to implement a loader method on a route using react-router-dom 6.8.1 but when I access the request.url which is passed to it I'm not seeing the hash on the url. If the browser url is http://site/page?query=here#foo what I see on request.url is http://site/page?query=here.
Is this intentional or am I doing something wrong? Struggling to find mention of it anywhere.
robust cargo
Hi everyone,
I'm trying to implement a loader method on a route using react-rou...
As per the URL spec (I'll try to find a source in a minute), URL hashes are never sent to the server and are only used for browser-based purposes, like scrolling to an element by ID.
So no, you can't use URL hashes in your loaders. You have to use a URL segment, or a query param.
tawny atlas
Thanks @robust cargo seems a bit odd though given the loader is running in the browser not on a server.
robust cargo
https://www.rfc-editor.org/rfc/rfc2396#section-4
When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI.
Yeah, I didn't realize this was a React Router question. Let me look into it a bit closer.
Yeah, it's because the request object is a Fetch Request instance, and, as per the spec I quoted above, it's not technically part of the URI. So the Fetch Request implementation ignores/removes it entirely.
tawny atlas
Thanks again. Hmm I may have to rethink my strategy.
obtuse crypt
yeah, generally speaking hashes are for jumping to an anchor in an already rendered client side page. They shouldn't be used to change the content on the page via the loader
The request you get in a loader is intended to be effectively "here's the request you prevented from hitting your server with preventDefault()"