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.
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...
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.
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
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.
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.
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.
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.
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.
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.
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.
@@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.
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.
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.
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
Impressive, very nice. Let's see Paul Allen's routing package.
The tanstack-router-vite-plugin is also great that you dont have to manually configure tsr config.
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 makes react easy af, router, query, tables, web is actually fun now
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?
Jack being savage with Napoleon. 😄
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...
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
Awesome video, as always!
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
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.
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.
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
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.
React should mention tanstack in their homepage, best libs in React's eco-system
Jack, how easy it will be to have protected and public routes in comparison with react-router?
Thank you uncle Jack!
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.
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
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.
Thanks Jack!
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
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.
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.???
Cool framework
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.
You seems to be using outdated version, new FileRoute is now deprecated...
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.
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.
Wow😍
Anyone know this vs code theme name, please tell👀??
It's in the description! Theme is Night Wolf [black] and font is Operator Mono
Wait what?? File based routing Without having to use a framework??
A bit of an overkill for something small. I'm sticking either react router v5 or v6.
was it server or client side fetces?
Server for SSR and then subsequent requests are from the client.
Let's fix NextJs Memory leak. We don't need another copied router
Hehe you have some work to do to compete with me 😋
I have all the type definitions for every route if you want them.
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.
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.
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