-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
feat: Add literal parsers #453
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: That's a good idea, thanks!
I would only suggest using a name that maps directly with TypeScript: literals (see comment).
packages/nuqs/src/parsers.ts
Outdated
const asConst = query as unknown as Literal | ||
if (validValues.includes(asConst)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I meant by having to extend the existing numeric parsers: using number literals here won't work as the array [1, 2, 3] never contains the value "2", it has to be parsed first.
We could hack our way out by detecting if the first element of the validValues is a number, then pass it through parseFloat
, which handles all cases for numeric literals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be enough to provide 2 functions, that looks too much like a hack to me? parseAsStringLiteral
and parseAsNumberLiteral
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a good plan indeed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please take a look at this.
By the way, I can't think of any other uses for literals in query than String and Number. So a generic attempt would not really achieve much. You can always create your own parser for special use-cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only other allowed literal type is boolean, and we already have a parser for that one, so this is perfect, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last little change on the docs and it looks great.
README.md
Outdated
|
||
const [side, setSide] = useQueryState( | ||
'side', | ||
parseAsNumberLiteral(diceSides) // pass a readonly list of allowed values | ||
.withDefault('red') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: Update the doc to include a valid default value, like 4: https://xkcd.com/221/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I must have overlooked that.
packages/nuqs/src/parsers.ts
Outdated
const asConst = query as unknown as Literal | ||
if (validValues.includes(asConst)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only other allowed literal type is boolean, and we already have a parser for that one, so this is perfect, thanks!
🎉 This PR is included in version 1.15.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Hello, while testing with the package I noticed that there is no support for as const string arrays.
Since I am one of those people who don't like enums, these are better for me to use.
I thought this parser might be interesting for everyone.
I have also extended the documentation and adapted outdated documentation for parseAsStringEnum.