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

Typesafe Links #698

Open
brillout opened this issue Mar 11, 2023 · 11 comments
Open

Typesafe Links #698

brillout opened this issue Mar 11, 2023 · 11 comments
Labels
enhancement ✨ New feature or request

Comments

@brillout
Copy link
Member

brillout commented Mar 11, 2023

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.
  • Research and report back how other frameworks do it (my design requires codegen but it would be nice to avoid codegen).
  • Sponsor Vike (massive increase in priority, and get an ETA).
@brillout brillout added the enhancement ✨ New feature or request label Mar 11, 2023
@samuelstroschein
Copy link
Contributor

Could a global type declaration for anchor tags <a> achieve typesafety instead of a custom link component?

@brillout
Copy link
Member Author

brillout commented Mar 18, 2023

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:

  • Routes is 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).

@samuelstroschein
Copy link
Contributor

Routes is completely UI framework agnostic and can be used by the user/framework's implementation.

That makes sense. Users are required to provide their own component.

@brillout
Copy link
Member Author

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).

@strlns
Copy link

strlns commented Mar 27, 2023

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.

@brillout
Copy link
Member Author

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.)

@strlns
Copy link

strlns commented Mar 27, 2023

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.

@quinnvaughn
Copy link

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.

@brillout
Copy link
Member Author

brillout commented Mar 8, 2024

Would this also apply to navigate?

Yes.

@micahjon
Copy link

micahjon commented Jul 7, 2024

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.

@brillout
Copy link
Member Author

brillout commented Jul 7, 2024

type-safe query parameters / hashes in the URL, similar to TanStack Router.

I agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ✨ New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants