vikejs
Typesafe Links
Description
I've a design in mind to make this work:
// Note the typo (it should be `product` instead of `produt`).
// TypeScript complains that '/produt/42' isn't matching '/product/${string}' | '/' | '/some-other-route'
<Link href="/produt/42" />
Help make it happen
- React with 👍 (to increase its priority).
- Comment and elaborate on how important this is to you.
- Sponsor Vike (massive increase in priority, and get an ETA).
Could a global type declaration for anchor tags <a> achieve typesafety instead of a custom link component?
I stand to be corrected, but I believe that isn't possible.
The idea is to have VPS code-gen type Routes = '/product/${string}' | '/' | '/some-other-route' while:
Routesis completely UI framework agnostic and can be used by the user/framework's<Link>implementation.- The code-gen will be completely seamless (although Yarn users will have to add a line to their
tsconfig.json). But I've to check whether the trick I've in mind actually works (I'm fairly confident it will).
Routes is completely UI framework agnostic and can be used by the user/framework's <Link> implementation.
That makes sense. Users are required to provide their own <Link> component.
From Discord:
It would be very nice if it were possible to auto-generate types for routes out of the box, to be able to do something like
<Link href={routes.Product} parameters={[paramA, paramB]}, with type-safety for all parameters and the route itself.
Yea I thought about this but, so far, I'm against this. Because it would require the user to give each and every route a name, which is pesky. And the ability to change the route of a page without having to update every <Link> is clearly useful, but not that useful (instead you can let TypeScript tell you what links you have to update which is an acceptable DX, I think).
From Discord:
It would be very nice if it were possible to auto-generate types for routes out of the box, to be able to do something like
<Link href={routes.Product} parameters={[paramA, paramB]}, with type-safety for all parameters and the route itself.Yea I thought about this but, so far, I'm against this. Because it would require the user to give each and every route a name, which is pesky. And the ability to change the route of a page without having to update every
<Link>is clearly useful, but not that useful (instead you can let TypeScript tell you what links you have to update which is an acceptable DX, I think).
Yes TS template strings are clearly less cluttered. This is better, didn't even think about that feature. Now I'm curious how file-based routing works with i18n. Is this also a part of the idea? Haven't used i18n with VPS so far a at all.
Currenlty, i18n is being implemented programmatically, which provides a lot of flexibility, see https://vite-plugin-ssr.com/i18n.
And, yes, for typesafe links a declarative i18n interface will be needed. (Not only for providing typesafe i18n links, but also for a simpler interface that works for the vast majority of users.)
Makes senses, thank you for your reply.
Programmatic i18n leaves most flexibility for routes (e.g. subdomain vs pathname prefix) and people can still share functions, components or e.g. React hooks to work with the API.
Would this also apply to navigate?
remix-routes does this as $path so you'd just by default kill two birds with one stone, as you just call it with that function.
Very much looking forward to using this!
It’d be awesome if in addition to type-safe pathnames, there was support (or at least a recommendation) for how to set and consume type-safe query parameters / hashes in the URL, similar to TanStack Router.
type-safe query parameters / hashes in the URL, similar to TanStack Router.
I agree.