could you please make a quick video to elaborate more on the usage of server in vite, to explain the "server" file a bit more, perhaps share you view on possible use cases as well. and props to you sir, one the best content on youtube 🙏, thanks a lot for sharing your knowledge.
Would be great to see how this ties in with tanstack query! I take it loading data at the route level is slightly faster than fetching when the component JS is ready
My gripe with this file-base routing approach is that we are still creating configurations with `createFileRouter` within the files that represent route segments.
I'm with yah. This system requires a build a build integration to scan for the files. Seems like it should be able to just handle it for me. Or by default handle it for me, and then allow for the automatic behavior to be disabled if I want to take control. But having files for the routes, and then within those files having to declare that they are file based routes, just seems really odd.
Not sure how I feel about the whole "loaderDeps" and "loader" design (8:28). Feels _really_ opinionated (to a fault?) about when and how fetching of data occurs in the "page" load lifecycle. Works in simple cases but has me curious about how it would actually perform when multiple requests are needed, dependencies are involved, etc.
Great video! I understand the intent is to share TSR with the community, but I think it would have been much nicer if you gave the search parameters a bit more time. For example when you enter the search parameter manually in the URL, it's the default state of query (which is what the code you provided does!), how to encode the URL properly to avoid weird quirks etc...
When you used the 3 second delay in your API I don’t think that’s streaming that’s just a delayed promise. With actual html streaming the initial server rendered page gets updated over time using the same connection.
What make it hard for you? I find it really intuitive. The only time that was useless for me was a project where I needed a route be in-memory and URL depending a condition
@@neociber24 Good thing that TanStack Router is not file-based routing by default. file based routing optional and opt-in in TSR. And even then, it just creates a config file.
The only complaining I have so far with React-Router is that the docs is really lacking. I just took a look at the Tanstack Router docs and it seemed way more detailed.
I genuinely don't know the difference between TSR, React Router and Remix anymore, they all look the same. Why this many alternatives to solve a common problem other frameworks already solved?
Remix is a whole-ass framework that includes how to build the project, server side rendering and a lot more, including a Router (React Router maybe? I'm not sure what they use by default but it has similarities to TanStack Router). The main thing here of TanStack Router is type-safe while Remix's router is not.
ok, cool, but I don't see how this is better than React Router. Since we're exlusively using JS and not TS, the main difference is File-based Route Generation instead of creating an object representation of routes and perhaps built-in SWR in loaders. Is there anything else? I think I will stay with React Router. A more significant difference is needed to migrate.
It certainly takes a lot of concepts from Remix, because they honestly are great! Where Tanstack Router really differs, is in its zero-compromise approach to type safety and first-class support URL search parameters. It also takes a special interest in allowing you to safely serialize and deserialize JSON from a search param as well. It does have some other points in which it differs as well, but IMO those are the big ones. Honestly, if you don't need a type-safe router and are doing very simple operations with the URL search parameters, then Remix's router will suit you just fine. Tanstack Router really comes into play when your URLs start holding more complex state patterns and you need strict type-safety in what's accessible via your router.
@@jherr Not to drag this out, but does that mean you'd build an app with the TanStack and not all the routing built in to next.js? I'm pretty heavily invested in Next. I don't love their routing, but I can't imagine I'd be able to use any other router with a next app because it so much a part of their way of building apps. (BTW, I think I met you once many years ago when you were working for Joe, and Joe and I were doing a project together sponsored with Microsoft.... Silverlight days, or as it was called back then, WPF/E)
@@PeterKellner99 Hi Peter, good to hear from you again. My point here was that if I was looking to do a SPA, probably with Vite, then I would use this router. But for SSR applications definitely Next and with no additional router. (Usually no additional router is assumed with NextJS, but some comments have indicated that folks are using a router on top of NextJS for some reason, which I think is a terrible idea.)
@@nigeldasilvalima4568 100%. Putting aside the politics of Vercel vs Shopify, IMHO, App Router is a way more powerful platform than Remix. And I really don't buy the "agnostic web standards platform" line. Remix being agnostic to framework has zero developer/customer benefit. And the web standards take is realistically scoped to a very small subset of the platform. It's more a talking point than practical reality.
Wouter is great! It's super lightweight and is the best solution for its target audience. TSR's focus is more on its first-class support for URL search parameters and storing complex state in it, as well it's type-safety story.
Although you tried, introducing new libraries should be done in a "crash course" way, not presentational. I felt lost after couple of minutes pausing and wondering what is what and why like this. Even though you explained parts of it, I was still left with a hole in the jigsaw.
Those eyes were rolled to align with your question which rolled off the topic from routing to state management. I would consider your question within a proper context - A. If the topic was Tanstack Query. B. If Tanstack Query was a client-state management tool. C. If I felt that the world needs another routing library. With that being said, "Redux-Router" does sounds cool 😉 Although.. I did get the impression that those guys (Redux, Tanstack..) are trying not to step one on each other's toes.
Why do people invest again and again time providing solutions for problems which dont really exists anymore. I am tired of all the JS stuff frameworks and libs which in the end all do similar things😅
With TSR, it was born out of Tanner needing to store some complex state in URL search parameters and needing strong type-safety out of it. He ended up having to heavily modify react-router in his startup's codebase before he couldn't get more type-safety out of it. Even now, outside of TSR, all the frameworks and libraries in the routing space treat URL search parameters as simple key-value pairs and don't really offer you a solution for dealing with complex states being stored in them. IMO: I don't think Tanner intends for this library to become the most used React routing library or anything like that. But, Tanner needed a solution for his problem and figured others may also want something like it.
Tanner should change his name to Midas Linsley because everything he touches is gold
Well, he is to touch NextJs. It is the last hope.
Another framework?@@dkaigorodov
he should touch me
@@dkaigorodov tan stack start is coming
The tanstack-router-vite-plugin is also great that you dont have to manually configure tsr config.
Impressive, very nice. Let's see Paul Allen's routing package.
tanstack makes react easy af, router, query, tables, web is actually fun now
could you please make a quick video to elaborate more on the usage of server in vite, to explain the "server" file a bit more, perhaps share you view on possible use cases as well.
and props to you sir, one the best content on youtube 🙏, thanks a lot for sharing your knowledge.
Tanstack Router is very cool, I will be using it in my next work application, thanks so much for your excellent example and explanation !!
finally not nextjs topic :D
Can you do a video of using TSR in nextjs?
Would be great to see how this ties in with tanstack query! I take it loading data at the route level is slightly faster than fetching when the component JS is ready
My gripe with this file-base routing approach is that we are still creating configurations with `createFileRouter` within the files that represent route segments.
I'm with yah. This system requires a build a build integration to scan for the files. Seems like it should be able to just handle it for me. Or by default handle it for me, and then allow for the automatic behavior to be disabled if I want to take control. But having files for the routes, and then within those files having to declare that they are file based routes, just seems really odd.
Two questions:
- how I can have layout for authentication and layout for dashboard for example?
- it's possible to integrate with tanstack query?
It's actually impossible to integrate with TanStack Query /s
Not sure how I feel about the whole "loaderDeps" and "loader" design (8:28). Feels _really_ opinionated (to a fault?) about when and how fetching of data occurs in the "page" load lifecycle. Works in simple cases but has me curious about how it would actually perform when multiple requests are needed, dependencies are involved, etc.
It’s similar to Query, so I think it’s the right direction.
Great video!
I understand the intent is to share TSR with the community, but I think it would have been much nicer if you gave the search parameters a bit more time. For example when you enter the search parameter manually in the URL, it's the default state of query (which is what the code you provided does!), how to encode the URL properly to avoid weird quirks etc...
Awesome video, as always!
When you used the 3 second delay in your API I don’t think that’s streaming that’s just a delayed promise. With actual html streaming the initial server rendered page gets updated over time using the same connection.
Jack, how easy it will be to have protected and public routes in comparison with react-router?
i dunno, i dont think ill ever embrace file based routing. its just not my cup of tea. every time i've tried it, it kinda falls apart in my hands.
What make it hard for you? I find it really intuitive.
The only time that was useless for me was a project where I needed a route be in-memory and URL depending a condition
@@neociber24 Good thing that TanStack Router is not file-based routing by default. file based routing optional and opt-in in TSR. And even then, it just creates a config file.
@@KevinVandyTech that's true, but to keep the typesafety you need to write more things than react-router
Seems like a you problem g
Agreed, especially for multi-language sites, file based routing becomes a mess real fast. Good for a brochure site, not for anything more complex.
Jack being savage with Napoleon. 😄
He's right tho. As a fan of both Ridley Scott and Napoleon, I think that movie should've been handled by someone else
The only complaining I have so far with React-Router is that the docs is really lacking. I just took a look at the Tanstack Router docs and it seemed way more detailed.
Which vs code extension are you using to dim the lines of code and highlight the lines of code for explanation
That's a post processing effect that I apply in ScreenFlow.
@@jherr thanks, other than that what are the various top plugins your are using in the backed please specify
I think the pace of this tutorial was a lil too fast, for someone completely new to TSR, a lot of things were skipped over or barely touched
I genuinely don't know the difference between TSR, React Router and Remix anymore, they all look the same. Why this many alternatives to solve a common problem other frameworks already solved?
Remix uses React Router.
TSR is a more typesafe alternative.
Remix is a whole-ass framework that includes how to build the project, server side rendering and a lot more, including a Router (React Router maybe? I'm not sure what they use by default but it has similarities to TanStack Router). The main thing here of TanStack Router is type-safe while Remix's router is not.
TSR can do a data fetch on button hover. Making this the absolute fastest paradigm possible in routing. SSR would be slower
@@everythingisfine9988 this come with a list of tradeoffs
React should mention tanstack in their homepage, best libs in React's eco-system
Hi Jack, when will your NextJs course be ready? I've been waiting for longggg time, haha. Have a nice day!
Working on it every day. I do apologize for the delay.
Issue with this video is yes you showed that it gave errors, but you did not show the type inferance on anything while typing.
data.???
Anyone know this vs code theme name, please tell👀??
It's in the description! Theme is Night Wolf [black] and font is Operator Mono
ok, cool, but I don't see how this is better than React Router. Since we're exlusively using JS and not TS, the main difference is File-based Route Generation instead of creating an object representation of routes and perhaps built-in SWR in loaders. Is there anything else?
I think I will stay with React Router. A more significant difference is needed to migrate.
Nice video, but latest version is 1.18.3 and a lot is depricated in your version, like new FileRoute is now createFileRoute()
Cool. I'll update the code.
was it server or client side fetces?
Server for SSR and then subsequent requests are from the client.
Thank you uncle Jack!
You seems to be using outdated version, new FileRoute is now deprecated...
This is great. thank you
Thanks Jack!
And how is this not a copy paste from all Remix ideas?
“Copy my homework but make sure to change it a little bit so it doesn’t look the same”
It certainly takes a lot of concepts from Remix, because they honestly are great! Where Tanstack Router really differs, is in its zero-compromise approach to type safety and first-class support URL search parameters. It also takes a special interest in allowing you to safely serialize and deserialize JSON from a search param as well. It does have some other points in which it differs as well, but IMO those are the big ones.
Honestly, if you don't need a type-safe router and are doing very simple operations with the URL search parameters, then Remix's router will suit you just fine.
Tanstack Router really comes into play when your URLs start holding more complex state patterns and you need strict type-safety in what's accessible via your router.
Where's your opinion? I thought you were going to give some opinions, not just a demo. compares to Next? Compares to React Router?
My opinion is that if I was building a SPA today this is the router I would use.
@@jherr Not to drag this out, but does that mean you'd build an app with the TanStack and not all the routing built in to next.js? I'm pretty heavily invested in Next. I don't love their routing, but I can't imagine I'd be able to use any other router with a next app because it so much a part of their way of building apps. (BTW, I think I met you once many years ago when you were working for Joe, and Joe and I were doing a project together sponsored with Microsoft.... Silverlight days, or as it was called back then, WPF/E)
@@PeterKellner99 Hi Peter, good to hear from you again. My point here was that if I was looking to do a SPA, probably with Vite, then I would use this router. But for SSR applications definitely Next and with no additional router. (Usually no additional router is assumed with NextJS, but some comments have indicated that folks are using a router on top of NextJS for some reason, which I think is a terrible idea.)
@@jherr Between Next and Remix do you prefer Next today?
@@nigeldasilvalima4568 100%. Putting aside the politics of Vercel vs Shopify, IMHO, App Router is a way more powerful platform than Remix. And I really don't buy the "agnostic web standards platform" line. Remix being agnostic to framework has zero developer/customer benefit. And the web standards take is realistically scoped to a very small subset of the platform. It's more a talking point than practical reality.
Cool framework
Wait what?? File based routing Without having to use a framework??
Wow😍
What about wouter ?
Wouter is great! It's super lightweight and is the best solution for its target audience.
TSR's focus is more on its first-class support for URL search parameters and storing complex state in it, as well it's type-safety story.
A bit of an overkill for something small. I'm sticking either react router v5 or v6.
Hehe you have some work to do to compete with me 😋
I have all the type definitions for every route if you want them.
Let's fix NextJs Memory leak. We don't need another copied router
Although you tried, introducing new libraries should be done in a "crash course" way, not presentational. I felt lost after couple of minutes pausing and wondering what is what and why like this. Even though you explained parts of it, I was still left with a hole in the jigsaw.
is redux dead? :D
Redux Router? 🙄
@@wishmeheaven tf are you rolling your eyes for?
Those eyes were rolled to align with your question which rolled off the topic from routing to state management. I would consider your question within a proper context - A. If the topic was Tanstack Query. B. If Tanstack Query was a client-state management tool. C. If I felt that the world needs another routing library.
With that being said,
"Redux-Router" does sounds cool 😉
Although.. I did get the impression that those guys (Redux, Tanstack..) are trying not to step one on each other's toes.
Why do people invest again and again time providing solutions for problems which dont really exists anymore. I am tired of all the JS stuff frameworks and libs which in the end all do similar things😅
TH-cam views
With TSR, it was born out of Tanner needing to store some complex state in URL search parameters and needing strong type-safety out of it. He ended up having to heavily modify react-router in his startup's codebase before he couldn't get more type-safety out of it.
Even now, outside of TSR, all the frameworks and libraries in the routing space treat URL search parameters as simple key-value pairs and don't really offer you a solution for dealing with complex states being stored in them.
IMO: I don't think Tanner intends for this library to become the most used React routing library or anything like that. But, Tanner needed a solution for his problem and figured others may also want something like it.
@@SeanCassiere thanks for the Info.
Great! Thank you for sharing