Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lensbart opened this issue Feb 5, 2024 · 3 comments · May be fixed by #11282
Open

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

lensbart opened this issue Feb 5, 2024 · 3 comments · May be fixed by #11282
Labels

Comments

@lensbart
Copy link

lensbart commented Feb 5, 2024

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

@lensbart lensbart added the docs label Feb 5, 2024
@brophdawg11
Copy link
Contributor

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

@lensbart
Copy link
Author

lensbart commented Feb 13, 2024

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

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

@brophdawg11
Copy link
Contributor

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

@lensbart lensbart linked a pull request Feb 16, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants