Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[✨] Type Safety for useNavigate Function #62

Closed
barel-mishal opened this issue May 16, 2023 · 1 comment
Closed

[✨] Type Safety for useNavigate Function #62

barel-mishal opened this issue May 16, 2023 · 1 comment
Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation

Comments

@barel-mishal
Copy link

Is your feature request related to a problem?

Hello Qwik community,

I've been using Qwik in my project and I'm finding it very useful, especially the useNavigate function. It allows me to efficiently navigate through my site, rendering only the parts that change.

However, I've noticed that the current implementation does not support type checking for the routes. As a TypeScript user, I find type checking to be a crucial part of my development process, as it catches potential errors early and improves the overall developer experience.

Describe the solution you'd like

I believe that having type-safe routes could be a significant improvement to the framework. For example, a possible implementation could involve defining a type that includes all possible routes in the application. Then, the useNavigate function could accept this type, enforcing type safety at the component level and ensuring that only valid routes can be passed in.

Describe alternatives you've considered

Route Enumeration: One other possibility is to define an enumeration (enum) of all your routes. This would allow you to use the enum as the type for the useNavigate function, providing compile-time checks for the route names. The downside is that it could be a bit cumbersome to maintain as your application grows and the number of routes increases.

Additional context

I wanted to ask if there's any ongoing work related to this or if there's interest in the community for this kind of feature? And, of course, I'm interested in contributing to this effort if it aligns with the goals of the framework.

Thank you for your time and looking forward to hearing your thoughts on this.

Best regards,
Barel Mishal

@gioboa
Copy link
Member

gioboa commented Oct 14, 2024

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.

@gioboa gioboa transferred this issue from QwikDev/qwik Oct 14, 2024
@github-project-automation github-project-automation bot moved this to In Progress (STAGE 2) in Qwik Evolution Oct 14, 2024
@github-actions github-actions bot added [STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation labels Oct 14, 2024
@QwikDev QwikDev locked and limited conversation to collaborators Oct 14, 2024
@gioboa gioboa converted this issue into discussion #153 Oct 14, 2024
@github-project-automation github-project-automation bot moved this from In Progress (STAGE 2) to Released as Stable (STAGE 5) in Qwik Evolution Oct 14, 2024
@shairez shairez removed this from Qwik Evolution Oct 15, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation
Projects
None yet
Development

No branches or pull requests

2 participants