[Types]: Narrow types of `hash` and `search` returned by `useLocation`

[lensbart]

Describe what's incorrect/missing in the documentation

Hello,

The documentation comment for useLocation().hash states:

A URL fragment identifier, beginning with a #.

If this is a strict rule, it would be convenient if these values could be typed as '' | `#${string}` instead of string. This is especially useful if hash is passed along to another function that impose a stricter input type, and will allow us to avoid an if/else clause or having to type cast.

Likewise, the documentation comment for useLocation().search states:

A URL search string, beginning with a ?.

So this value could be typed as '' | `?${string}` instead of string. (Alternatively, '' | `?${string}=${string}` or '' | `?${string}=${string}` | `?${string}=${string}&${string}=${string}` would be valid too. However, this would probably add unnecessary confusion because it doesn’t suggest that the string can contain multiple &${string}=${string} segments).

I’m willing to submit a PR

[brophdawg11]

Yeah I think that makes sense - want to push up a PR?

[lensbart]

Sure thing! What kind of type do you have in mind for search?

• '' | `?${string}`
• '' | `?${string}=${string}`
• '' | `?${string}=${string}` | `?${string}=${string}&${string}=${string}`
• ...?

[brophdawg11]

I would just do the first one to keep it simple. Query strings don't require = signs so we don't want to enforce that via 2/3

[brophdawg11]

After chatting with the team I think we're going to pass on this because it feels like a bit of overkill (i.e., the current string types don't appear to be causing headaches for too many developers) and it also it diverges from the types on window.location and would break the idea that our Location is loose superset of window.location. Please feel free to open a Proposal Discussion and if it gets enough community support we may reconsider.