- From: Tim Perry <notifications@github.com>
- Date: Wed, 21 Aug 2024 05:13:56 -0700
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/779/2301904144@github.com>
> Having said that, is there evidence on Stack Overflow or in popular JS libraries that this is a shortcoming people have to work around? I've run into this problem myself, in multiple projects and libraries, in both Node & browsers. Right now I'm building developer tools, where URLs are taken as string input, parsed, and manipulated by component, and preserving the raw formatting where possible is useful. Not being able to differentiate between `/?` and `/` and the end of a URL is quite inconvenient! I'm still using Node's `url.parse` in some places in part because it does _not_ have this behaviour and that's important. Of course this state does exist within the URL parser (the [URL's internal query and fragment states](https://url.spec.whatwg.org/#concept-url-query) in the spec do store empty & null differently) but it's just not currently exposed the same way in `search` & `hash` (in both cases, both null and empty are exposed as `''`). Totally understand that changing the existing API is impractical. Either of the options proposed here so far would work well in scenarios like mine: * `hasSearch` and `hasHash` booleans to distinguish no-delimiter vs delimiter-but-empty-value (or `has{Search,Hash}Delimiter`, if we want to be even more explicit) * `query` & `fragment` fields that do always include the delimiter as it was originally parsed, so they're set even if the value itself is empty * The latter is definitely more convenient as a user (`fullPath = url.pathname + url.query + url.fragment` would effectively reproduce the original relative url components - which it does not do today!) but both are workable, and the confusion of two very similar fields with almost always identical values might not be worthwhile. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/779#issuecomment-2301904144 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/url/issues/779/2301904144@github.com>
Received on Wednesday, 21 August 2024 12:14:00 UTC