Migration Story and Appreciation Thread

[benweier]

I want to say congrats and thank you to @tannerlinsley and the TSR contributors for shipping an amazing library. I love me some SPAs and client-side rendering so seeing a new tool come out in such a great 1.0 state is really refreshing.

This past weekend I decided to see what it was all about, thinking that TSR would be "good" but "not quite a React Router replacement.. yet". I was very wrong. In 2 days I was able to migrate my whole app (approx 12k-14k LOC, about 13 unique routes), including some "interesting" integration details... with minor patches to a couple things I got wrong on the first pass in the following 2 days.

Once I worked out the new patterns with TSR it all seemed to fall into place. Although there's a few rough edges left - TS is painfully slow sometimes, and RouteApi could do with a few improvements - the end result is quite amazing. Compared to my React Router version it:

• Maintained virtually the same bundle size
• Increased type safety through the roof, no more manually constructing template literal URLs
• Killed WebStorm type-checking multiple times due to the depth of some types until I realised my mistake
• Noticeably improved runtime performance (this was mostly because of my original choice to lazy load RR's loader functions but not lazy in TSR)
• Feels like a much more natural fit using TanStack Query in route loaders
• Made me consider swapping React Hook Form for TanStack Form.. but not yet

Thank you thank you thank you. I can't wait to see where this goes next!

[tannerlinsley]

Wow, thank you so much for sharing this :)

• I will personally look into the type performance again (it's a constant battle)
• I already have some ideas slated for v2 to improve the story around RouteApi. I'll share when we get a little closer to get your feedback!
• I would love for you to take a peek at the file-based route generation, especially with regards to the experimental auto code-splitting features I've been working on. Your perspective would be very helpful! https://tanstack.com/router/v1/docs/api/router-cli#unstable_codesplitting

Thanks again, this was great!

[benweier]

I started with non-CLI and didn't find it too bad, even with manually nesting addChildren. This may be partly the cause of TS performance issues since I noticed the CLI-gen types are slightly different to the manual approach.

declare module '@tanstack/react-router' {
-  interface Register {
-    router: typeof router
-  }
+  interface FileRoutesByPath {
+    '/': {
+      preLoaderRoute: typeof IndexRouteImport
+      parentRoute: typeof rootRoute
+    }
+    /* ... */
+  }
}

Parsing those route IDs through typeof router is probably quite expensive, made even worse when TS has to re-parse the whole thing as you're working on the router.

So I took a few hours to switch to the file-based generation and was very impressed. Then I used auto codesplitting and was blown away. This is absolutely phenomenal! It does seem to be better for TS performance overall, and it's really nice that I still have fine-grain control over when to auto split, use lazyRouteComponent/lazyFn directly, or not at all.

Interestingly enough, the code splitting pattern is very similar to how I had structured my app with React Router so the implementation felt eerily familiar.

[antonio-ivanovski]

Hello @benweier, I have been struggling with the performance as described in: #1091

file-based routes didn't help me as they did for you.

Can you please share some tips that helped you get better performance? What TS are you running? Do you have some performance metrics?

[benweier]

@ToTeTo I initially had some reasonably strict type-checking rules as part of my eslint config, I'm opinionated in that way so it wasn't all TS's fault... That was where performance was hit the hardest because the TS engine was working overtime. Removing the TS rules in the eslint config addressed most of my performance issues, and I now use tsc --noEmit in conjunction with eslint.

Using the Vite plugin to generate the route tree also wasn't doing any favours because changes to routes would regenerate the router declaration often and cause heavy spikes in processing. I now tend to avoid running vite dev while I'm updating routes and instead prefer to use vite build once when I'm done. Small route tweaks tend to be fine with vite dev though. Checking/autocompleting the routes and params in Link/useNavigate/getRouteApi aren't great but they are noticeably better.