Route information is lost on vite HMR #4103
-
|
Hello! This might not be a problem at all, and it might just be me using the tools in ways they weren't meant to. I've just recently migrated an app to tanstack router. I'm using file-based routing, but I'm importing all the components used for the routes (so for routeA a component is imported, instead of defining it in the same file). To keep all the routes info (fullPath, useSearch, etc), I created an object that contains all the routes, where I imported all the different routes, to have them centralized. So therefore, in a Link component, instead of doing The issue arises when I trigger HMR on a specific route. If I'm in a route, and I modify any component inside that route, then the info from that route is lost (Route.RouteA no longer contains fullPath and other useful metadata). I created a quick demo here on stackblitz. To reproduce: Go to any component, add a comment, and observe how the different routePaths switch to undefined depending on where the info is printed. Depending where you navigate from, you might have the fullPath defined, or not. What I don't get is why the only routes that stop working are those of the component that has been affected by HMR. My question is, are the routes being regenerated even if nothing has changed in the routes naming/hierarchy? Is the Route object only meant to be used inside the route file itself? And finally, should I just use string paths everywhere and that's it? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
Mmmm having to use route strings everywhere might be a deal-breaker for me. I've just noticed that in navigation options, the paths are correctly inferred as the final path, but for useSearch and useParams, the paths are the literal paths to the route file. For example, in my real app, I have a file route under this path Having some hooks typed as the file path string and others as the literal final url path is quite inconvenient. |
Beta Was this translation helpful? Give feedback.
-
|
i fixed the HMR issue, it will be released as soon as we merge the devinxi branch. however, please be aware that importing the routes and using them like you do might result in circular type dependencies that typescript might complain about. hence we recommend using string literals always. about the difference of when navigating, when using e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for the quick reply! Yeah, I did encounter circular dependency problems when I tried to implement code-based routes, to see if that solved the HMR problem. But with file-based paths, I had no problems at all. I'm not familiar with the internals of file-based routing, but doing it "my way" worked like a charm, except for the HMR of course. As for the naming difference, I understand 100% that it's technically required. However, it's not "pretty". That's why I prefer to have the routes mapped in an object, as that provides cleaner and more intuitive code for new devs in the project (in my humble opinion), rather than having random string paths everywhere. It'd be great if in the future the were a way to do natively what I'm trying to do: recovering the Route object to use it anywhere in the same way you can use it in the route components. Do you have any approximate idea of when that will be merged? I'm the one pushing the migration from react-router to tanstack-router in my team, so I'll be the one getting all the questions.... |
Beta Was this translation helpful? Give feedback.
-
|
we are very close on merging devinxi. hopefully no more than a few days |
Beta Was this translation helpful? Give feedback.
-
|
Hello! @schiller-manuel , any news on the devinxi progress? |
Beta Was this translation helpful? Give feedback.
-
|
it's still taking some time so I ported that fix on to the main branch |
Beta Was this translation helpful? Give feedback.
i fixed the HMR issue, it will be released as soon as we merge the devinxi branch.
however, please be aware that importing the routes and using them like you do might result in circular type dependencies that typescript might complain about. hence we recommend using string literals always.
about the difference of
fromfor navigation andfromforuseSearchetc:when navigating,
fromrepresents a path as it will be in the URL at runtime.when using e.g.
useSearch, you need to specify a route id for which you want to read the search params. with pathless routes, a path alone would not suffice to describe a route, hence the id is required.