obviously, I talk about React Query and now TanStack Query quite a bit, but I've been slowly getting more and more hyped around TanStack Router, which is its alternative to React Router. But in order to do a router right, you can't just throw it in the client and hope for the best; you kind of need a server. We've learned that quickly with the React Router team becoming Remix, with Next.js going all in on servers, and then eventually becoming Vercel. And now it's time for TanStack, which is the newest JavaScript framework for React developers. It's a very interesting project because it was originally meant to be almost like a boilerplate, like a starting point to use the router correctly, and it has very quickly morphed into a framework all of its own. It is different, it is fun, it is powerful. It does not have server components yet, but it has a lot of its own really cool things. It almost feels like the natural evolution of the original T3 stack in a lot of ways, and I cannot wait to start.

diving in with your tanack router is one of the key points here. It's all built around tanack router, so you get a full type-safe and powerfully unmatched routing system. You also get SSR streaming and server RPCs, you know, trpc effectively built-in client-side first 100% server capable. While other frameworks continue to compromise on the client-side application experience we've cultivated as a frontend community over the years, tack start stays true to the client-side first developer experience while providing a fully featured server-side capable system that won't make you compromise on user experiences. Do you know what else is capable? Today's sponsor, so let's hear from them really quick. Ow, sorry about that. I just set up Clerk. It's a really easy-to-use auth platform for developers. What? What is this? Clerk works with pretty much any tech stack, from Next.js to Tan Stack to React Native. If you're even near the React ecosystem, it's pretty hard to beat. Okay, can you tell me how to get through? You have so

many options to authenticate. You can sign in with Google, GitHub, SSO, magic links, two-factor with SMS, all the things you would ever expect for authentication. Did your shirt just change colors? Oh, you noticed. Trying out a new theme, switching between different looks is as easy as snapping your fingers. Okay, this is some weird. I don't get it. Thank you to Clerk for sponsoring. Sorry about that. Let's go back to nerding out. It's also built on top of Vigi in V, which makes it relatively easy to deploy basically anywhere that you run Office script, which is really cool. Also, shout out to all the people who are sponsoring this and partnering with them. Cool set of companies, can't complain, and a bunch of additional sponsors as well. There's some really cool companies in here, by the way. AG Grid is literally a competitor to Table, and they funded him and were the biggest sponsor supporting Tanner for a while, and a huge part of why he was able to quit his job to work full-time on this. And we got all the big partners here as

Well, it's cool. I'm really pumped to see funding going towards Tanner and his team so that stuff like this can happen. And shi for real, so good to see Tanac start. Overview Tanac start is a full-stack React framework powered by the Tanack router. Provides a full document SSR streaming server functions, bundling, and more powered by Tanac router VY and V. It's ready to deploy now on your favorite hosting provider router or start. Great question. I almost just went down the path of doing a Tanc router tutorial because I thought this was Tanac start. It's not. Still looks very good. Shout out to Adam Rack for making it. But we're here to learn about Tanc start. Tanc router is a powerful type-safe and fully-featured routing system for React applications. It is designed to handle the beefiest of full-stack routing requirements with ease. Tan stack start builds on top of router's type system to provide type-safe full-stack APIs that keep you in the fast lane. So, to be clear, this is what you get without

tan stack start at all. This is just the router, which you can throw into an existing React app today. 100% inferred TypeScript support, type-safe navigation is a big deal. Having a link tag that you can never send somebody to the wrong link with really nice nested routing and layout routes built in. Route loaders with stale wall validate caching designed for client-side data caches using things like tanat query SWR, etc. Automatic route pre-etching, asynchronous route elements, and error boundaries. Oh, that's really nice having asynchronous parts of your route with the ability to error and like hoist that to a good spot. So good file-based route generation. They do this in a very interesting way, which I'm sure we'll touch on in a bit. Type-safe JSON first search params, state management APIs, path and search parameter scheme of validation, search param navigation APIs, custom search param parser and serializer support, search param middleware, route matching and loading middleware, and then tanack start. It's a shorter list. These are the things it adds on top of the router. You get full

document SSR streaming server functions and RPCs bundling deployment and full-stack type safety in summary. Use tan stack router for client-side routing and tan stack start for full-stack routing. So, how does it work? Tan start uses a tool called Vite to bundle and deploy your apps. In fact, this is the same tool that powers Solid Start. With Vite, we can do a few things that we couldn't do before. We provide a unified API for SSR streaming and hydration. We can extract server-only code from your client-side code, and we can bundle your application for deployments to any hosting provider. Very fun stuff. Also, quickly on Solid Start. If you're not already familiar, Solid Start is the Solid JS equivalent of Next.js. Originally, it was a close collaboration between Ryan Carni from the Solid side, Tanner Lindley from Tan Stack fame, and a good bit of help from Fred Schott, the creator of Astro, trying to use Astro as the base for all of these. Eventually, Vite happened as a better way to build full-stack.

applications and specifically frameworks on top of v, and they moved to that as the base point instead of Astro, which I think makes a lot of sense going forward, but was interesting to see Astro as the starting point for a ton of these things. So why don't you actually use Tanack start? Tanack start is perfect for you if you want to build a full-stack React application with the following requirements: full document SSR and hydration, streaming server functions and RPCs, full-stack type safety, robust routing, and a rich client-side interactivity and experience. As I said before, this is like T3 stack Plus+; the full document SSR and hydration is an important detail though because all of the JavaScript code you write to render your components, that gets sent to the server and to the client. So any React code you write in this code base runs on both server and client. It's an important detail because server components don't work that way. I can have a file with like 5,000 inline SVGs in it, and as long as it's only run on the server as a

server component that doesn't bloat the JS bundle at all. This doesn't solve that problem, which means there are certain issues. Like if you have a terms of service page, you have to send down the data on both the client and the server in order for that to render and hydrate correctly. 'Cause all of the code that was necessary to load that page and render it on the server has to also exist on the client. So, it is not great for a lot of things, but it is fine for almost everything. Shipping the code twice, it's whatever. Most people do it for a reason, but it is cool that server components moved off, and it does make me sad to work on a solution that requires the whole document be hydratable. I've kind of gotten pilled on the islands thing, so why might you not want to use it? Tex starts not for you if your site's 100% static, if your goal is a server writer site with zero JS or minimal client-side interactivity, or you're looking for a React server component.

first framework we will support RSC soon, though in their own awesome flavor. Yeah, it's not their priority, but it will be coming. So, how is it funded? I like that they call this out. A lot of people are very concerned when they see new frameworks, like, How is this going to exist? Like, how are they making money? How does this work? And Tanner's taking this seriously. Tanack works closely with our partners to provide the best possible developer experience while also providing solutions that work anywhere and are vetted by industry experts. Each of our partners plays a unique role in the Tan stack ecosystem. For Sell, which is the leading hosting platform for web applications that provide a fast, secure, and reliable environment. You guys know what Forell is. They're working close to make sure Texart works there. Clerk might surprise you guys again. Channel sponsor fun thing with them, though. They already announced that they have an SDK for Tanack Start. That's pretty cool to see actual companies shipping actual tools and solutions before the framework's even out of alpha. W so cool. Convex is in.

here as well. They're a database data management solution. Does a lot of different things. You'll probably hear me talking about Convic a little more in the future and Sentry, the thing that you should be using to keep track of your errors. I tried a lot of other alternatives. If you want to figure out from the client to the server why something failed, I have caved an IU Sentry for everything, and they've sponsored things as a result. Cool company. Had a good time working with them. Also, uh, Z, the founder and then CEO, then CTO, now I think he's just had a marketing or something or product. Regardless, great dude, good friend, interesting crew. We start by creating a TS config. Then we all the depths. Best part about pnpm. Ready for it? Instead of pasting directly when you have an npm command, put p in front, then paste. It's really nice. You don't have to require all the different options here. That step is done. Let's get Viny working. Make sure types module cool. I need to configure the app config.

app.config dots for required files for Tan stack start usage, the router config, server entry point, client entry point, and the root of your app. This is an important detail. Remix was one of the first ones to really take this seriously, where you specifically write different starting points for the server side and the client side because they are that different. When you live in Next.js like a lot of us do, you stop thinking that way, but realistically speaking, they do have to start differently, and a lot of frameworks embrace that. Once config is done, the file tree should look like this. Cool. This goes in app SL router. This is the file that will dictate the behavior of Tan router when used with start. Here, you can configure everything from the default pre-loading functionality to caching staleness. Let's do it. App router file app router. TS, TS or TSX, TSX, so just components. Cool. I'm slowly becoming more and more sympathetic to the people who use TSX for everything in their code base. Oh good, they called this out. What

did it say route tree GTS is not a file you're expected to have at this point. It will be generated when you run the tanack start command via npm run Dev or npm Run start. Let's go to app SSR TSX. Paste this guy is what defines the server-side handle, as I mentioned before. Now need the separate client entry point because again client and server start separately, they're ending otherwise client. TSX paste so enables us to kick off client-side routing once the user's initial server request has been fulfilled. Now the route of the application. This is the entry point for all other routes code in this file will wrap all of the routes in the app. Let's make it and then take a look app routes double uncore rout. Yeah, here's our route create rout route tack react router Outlet scroll restoration also from T react router body head HTML meta scripts. Those are all the fun meta tags that I mentioned briefly in another video I filmed today. Const routes equals create root route.

looks good to me. We have the root component. It has an outlet component. The outlet component is where sub-routes will be rendered. In this case, every route children SC illustration scripts. This might look like a lot of code to get started, but the difference between this and something like Next is that Next has all these things, but they're hidden in the Next configurations, where with Hand's Deck Start, all the code lives in your code base. It's a little more similar to something like, I don't know, if you were using CN, where this code, if you were using something like, I don't know, MUI, it might look less bad in your code base, but it's the same code that they have written in their packages. You just don't own it or have any control of it. Like if you wanted to turn off scroll restoration, it's off now. I just deleted it. That easy. So let's make our first route index.TSX, paste, save. That's it. Let's run it. That's enough. This runs first try. Let's over-under it.

quick cool pred is closed. Let's see who said it was going to run first try. Oh, is it I to do Dev? That's okay. I think it counts. I ran the wrong command one. As long as this loads, I think one wins. Looks like the Easy Choice ultimately won. You lucked out there, y'all. Back to now that we've seen it working. I do want to actually read the code in this 'cause I'm curious. Oh, is it actually writing to a file? Oh yeah, count.txt is actually writing that to a file. That's server code then. Oh, he snuck bling into here. That's what that is. Interesting for those who aren't as nerdy and tuned in as me. This is a very interesting thing. I'm going to put something a little extra in here to see if you guys can catch on to why this is cool. Con, look at that cursor already knows where I'm going. That is wow. So I didn't expect that to make it in. Let me contextualize this for y'all so you understand why this is so cool. CU I

did not expect that. So, this file is obviously running on the client by console.log. This is running on the client up here. We open this console. This is running on the client. Since this is server-rendered, it also has to run on the server. But if I go to this update count create server function console log updating count, no log here, updating count there though. The thing that is interesting here is it is true collocation. You cannot write this same code in Next.js with server components because here we have defined server functions. These are endpoints, so this is the request that's actually being made. We can see it's calling server function name dollar sign dollar sign function zero. That's how it knows which function to call. Theoretically, I should be able to run that and have the number go up, which is not working. We'll do this slightly differently. Copy as a Node.js fetch. Save this as demonstration.js. Put that in tan stack start Bund demonstration.js. I'll run this three times. Oh, is that just the get code? Did I copy the wrong code? Yeah, I've

been copying the wrong code this whole time. I'm so dumb. I've been copying the server-side fetch, not the server-side post. So, I copy this one as a curl. Now, now it's updating, and if I refresh the page, it goes up to 33. Okay, I am dumb. Just ran this a bunch of times. Now, if I refresh, the number's gone up because, again, it is just making a post request to the endpoint. The reason I fell for that is there aren't single flight mutations, which means once the client has done the post, it then has to do another get to get the new data with new server component stuff. That isn't necessarily true where the post request can send back the update. They don't have that yet. It's not that big a deal, but that cool. And the thing that I was trying to showcase is the intermingling here because this file is a client JavaScript file. So, if you're doing things in here like calling fs.promises, we can't bundle FS, so the bundler has to

be smart enough to figure out which of these depths are being used on the page on the client side and which ones aren't. Like something you wouldn't be able to do would be like const St count equals await read count. I'm curious if I try to do that if I console.log cannot read properties of undefined reading read file because it will not import FS on the client side. So me attempting to call something that uses FS here fails. I can go a step further, do that same deal. It cannot call read file because fs. promises does not exist on the client side, which can be unintuitive because there's things important in this file that I could try to write code access that will. It will just not work. I personally prefer to have my back end code and front end code in different files, and server components have gotten me really hyped on the separation and the intermingling there. I do quite like it now that the model is clicked, but not having to think about it as powerful too if you want server code.

you're out a function and create server function. Now you have server code that's really cool. This was the original promise of bling, which was the attempt to make a generic RPC that your bundler could handle. What it was actually doing under the hood is these get compiled into an endpoint or multiple endpoints, and then when the user tries to go to a page or hit one of these functions, it does a fetch call and then gives you back the result. And of course, it's type-safe. So if we look at get count, it returns a fetcher undefined number. Then once we await get count, which I'm sure we do down here instead of coming from the router. So where actually use get count. Oh, the route cost route create file route component home loader async await get count. And now this will hand back the count. I bet I could even do this, make it nice and simple type variable declarator. That is interesting because this should be the exact same thing. Weird but fine. That feels strange 'cause awaiting a function that returns a

promise should be the exact same thing there. Whatever small things I'm seeing the light. One more thing I want to check because of how am is being a nerd. I want to look at the JavaScript that is being shipped to me. Here's the transpiled code. Children server counter JSX. Dev button yada yada. But notice that FS is imported here. Build at ID V browser externals. Interesting. So they actually have these functions get stubbed out to let you know if you try to call them that you can't call that in. Interesting. So they're not just like blindly bundling server code. They're overriding things that can only run on server by creating a getter that just throws an error instead. Very interesting. Very interesting. This is my first time digging into Viny. Cool way of handling that because that's the reason that a lot of these things are so hard is once you start putting server side code and client side files and you need to make sure that the right stuff goes to the right sides. Now you're writing a crazy

compiler and do it might sound. The server component compiler with React is actually quite a bit simpler because there are files that only run on the server and files that don't. Let's go back to the tutorial because there's a lot more here. Server functions. The thing I just spent all this time on. Apparently, there's a new server function shipping soon. This will be even more fun. Let me know if I should do another video on those ship server functions. Allow you to specify specific functions to only run on the server. They are used to perform tasks that should never be directly exposed to the client. So, how do they work? Server functions can be defined anywhere in your application, but they must be defined at the top level of a file. Interesting. Very interesting. They can be called from anywhere in your application, including loaders, hooks, etc. Traditionally, this pattern is known as a remote procedure call, but due to the isomorphic nature of these functions, we refer to them as server functions. On the server bundle, server functions are left alone. Nothing needs to be done since

they're already in the correct place on the client. However, server functions are removed out of the client bundle and replaced with a function that, when called, makes a fetch request to the server, instructing it to execute the server function in the server bundle, and then send the response back to the client. Quick history lesson of why people know who I am. I showed up in a Tanner Lindley Twitter space three years ago, back when those were still cool, as a little nobody with like 30 followers. One of them was Fred Shot, and one of them was Ryan Carniato, 'cause I had reached out to both about helping with copy on their blog posts. But I didn't have videos. I was a nobody still. I was getting really into React Query, though, and I was starting to get into building stronger relationships between my server and C code. Also of note, I had never heard of TRPC. This was a while ago. I had an idea. I was writing all of these endpoints in the API folder in my Vercel project, not even Next.js. I was just using

raw versell and vit and writing out my typescript functions as his own file. I was tired of having to guess and check for type definitions and inputs and outputs from that API directory to my react query calls. I was trying to build something to compile it out and give me correct type definitions, but I kept thinking about it. I was like, maybe I'm going the wrong way here. Maybe rather than trying to export from the server code to get the things I actually want in the client code, I could inverse this. What if I just write the server code in the client code and a compiler rips it out? This is a proposal that I wrote to Showcase this. I called it the used backend hook. You gave it a key just like you would an old react query. Then you would write an async function that does something that you can only do on the server. In this case, I was getting a profile from the database, returning the result, and then when it's compiled, it would create for you a use Query call, the same key, but it would

call fetch to this generated endpoint and then stub out okay get user info here it is yeah request response con St is wait get profile data and it returns it j onfi i I was ahead okay I I thought I was real clever with this proposal now most Frameworks have this or something like it at the time nothing did this was a actually newish idea I'm sure others had the idea but nobody had the implemented and I saw tenner Lindley person who I quite looked up to was doing a Twitter space so I joined we're talking a bit about server stuff and I was like yeah I I'll do the scary thing and hit request to speak he saw that I was followed by these other people we mutually respected let me up to chat and I brought up this proposal he thought it was really cool but he had an interesting response he said that sounds really cool I've heard of two other projects working with something similar one I think's called Blitz JS and I think the other's trpc but I can't

quite remember. I don't know anything about them. I just know they're using React Query for backend stuff. Are you down to look into it more and let me know what you find? So, he gave me a homework assignment to go figure out TRPC and Blitz, and then a week or two later, I came back and couldn't stop ranting about how cool TRPC was. But the journey that led to T3 stack in this whole goddamn channel in the chaos started with this little gist, and we bringing it up with Tanner in a Twitter space, and him giving me the excitement that I've been seeking since Co destroyed my experience at Twitch. All of a sudden, I had this person I looked up to giving me homework, but not in the annoying sense, in the fun sense, where I had something to go look into with the promise that in the end, my reward would be nerding out with somebody about it again, which is all I wanted to do. I just wanted to nerd out about these things I liked, and he gave me an

incredible opportunity to do it and a platform to justify like the effort and to share it with others. And now we're here 3ish years later. It's unbelievable to think, and I owe Tanner so goddamn much. I can't even put it into words, and I didn't realize we would be chasing what I showed here for the next three years, but we have been. Bling was another attempt to do this with a syntax server dollar sign, so you'd write something server dollar sign, write server code in it, and now when you call this in client code, it just turns it into a fetch call. This is the building blocks for what I was showing there. Then React server component bonus happened and sent us all down weird paths for a while, but now we're back. Now we have create server function, and this is the primitive that you would have used here instead of used back into the top level. It's the same thing, and it's really cool to see my dumb little proposal from 3 years ago.

becoming an actual solution. And I'm not saying I have any responsibility for its creation. I absolutely don't. This was like the obvious inevitable thing. It's just nice to know that I guessed that's where we were going as an industry. Purely CU. I wanted it so badly. So yeah, this whole thing here. I was real close on. Oh yeah, I was also way ahead with Zach. I had a validation wrapper for server actions before server actions were public. I found it on GitHub and pushed it early. And now there's a whole ecosystem of tools wrapping server action with validation, authentication, all those things. Like, I built the first vzero version of that because I wanted it. And everyone else would have realized anyways that this is the right way to go. But it's cool to be validated, seeing these people I look up to, respect immensely, building the things I was trying to prove could exist 3 to 4 years ago. But now they're real. It's so cool. As I was showing in the code, it's pretty easy to define them, create Ser.

function you give it the method, give it an async function, and you're done. What's cool is you can call them anywhere - from server code, from client code, from other servers, from basically anywhere. It's a single parameter which can be a variety of types: string, number, Boolean, null, array, or object, form data, readable stream. It can take in a readable stream, that's pretty cool. A project using EXA in production, you should move to next type-safe action. It's a much better thing, it's in a much better state. I didn't even ship Zack, we ship Zack in production for the earliest version of upload thing, and we got it immediately because I didn't feel like fixing it, and I think I ended up just moving back to tanack query. Yeah, also good call out Dev here. Get and post needs to be specified because you can cash get, you can't cash post, and they also behave quite differently. Like you can attach metadata and a body on a post, you can't have a body on a get, which means that when

you're getting with parameters, so if I'm passing a string or an object as parameters to a GET call, it has to be done in a query parameter. Nice and simple. Here are things get fun. Type safety. Server functions are fully typed, and the type of the parameters inferred from the function's signature. So here we specify this needs to take in a person, and then it returns person.name. Now it can infer the correct types for all of these things. Really cool stuff. Jon parameters. Server functions can accept JSON serializable objects as parameters. This is useful for passing complex data structures to the server. Pretty cool that it will automatically serialize for you too. Apparently, you can also accept a form data object, so you can bind this in a form, which is huge because Tanac forms coming in hot. Going to be a fun one. Server function context. In addition to the signal parameter that server functions accept, you can also access server request contexts from within any server function using the many utilities from Viny HTP. Under the Vin is using nj's H3 package to perform

cross-platform HTTP requests. That's actually cool. I didn't think about like how many weird different ways there are to get things out of like headers and stuff with HTTP across different services. So having Viny HTTP abstract that between Cloudflare workers, Node, and different places, Versel weird fetch stuff, all of that abstracted is actually really nice. They also handle multi-part form data, which is obnoxious, so that's really cool. You got the request context by calling get web request. What happened to web standards? This is fine. Personally, I would want to put these server function files in a different file and not allow them to be in the same file where the JSX code exists, just to make it easier to reason about what is and isn't server code. Still really cool. I also would have liked the dollar sign in front to indicate like this is different. Using Vin's get headers function to access all headers from within a server function. Yeah, we can return values here. Where things get fun is something like TBC. By default, your return types are quite limited because they have to be.

serializable as Json. Fun fact: you can't serialize and deserialize a date in JavaScript. So if you turn a date into Json and you turn it back, you get back a string. That sucks. So usually, you'll introduce a thing called super Json, which will allow you to do a little more than you usually can in Json. Seems like Tan is doing even crazier stuff here. What was your question about context? Yeah, where does this come from? Yeah, I have no idea where context came from. This might be a mistake. This might be one of the things web request returns and they forgot to stub that out there. Dev, I think you're deep enough that you could get that likely typo fixed. Let say here you can do primitives, Jason serializable objects, redirect errors, not found errors, and raw response objects. Apparently, they don't handle date time. Let's try that quick. I'm going to make a new file in here. Let's um just have this post call Demo post. I want the get to input date console.log date date love all of that put.

dot and let see if I can call that return responded at new date. I'll try the loader quick too. Let's do that. Get loader, kill all this, kill that too. State, oh was it smart enough to ah look at that. They're no longer functions. Let's see what happens when I actually load this. Yeah, you just get the string here. That was the concern. It doesn't handle things that you can't Json serialize. Sad rip. What happens if I hit that though? Uncaught request failed with status 500. And what does the server say here? Server says it is mad at me is what it says. Server function error input. Get day is not a function. Yep, if you pass a date time from the client to the server, it also gets converted into a string. I know that uh Maple created some crazy hacks on type definitions to make sure you couldn't have input types or return types that weren't Json serializable. It might be worth ripping that so that you don't get into these use cases in these weird error cases as

easily yeah. I'm sure it would be straightforward to inject super Json through middleware, but the default should be type safe 'cause like as far as TypeScript's concerned, like there's no type error in this file, but it still throws errors because you can actually post a date and have it behave. Either the types should correctly indicate the behavior or super Json should be the default. I don't like the in-between. You can also set custom headers, custom status codes, calling server functions from within the route life cycle, also really cool that the loader can just call random server functions and it's fine. People got really tripped up with this with trpc where they were trying to call trpc from trpc. Okay, Tanner's in YouTube chat. I am so sorry for not checking that. I am sorry, Tanner. He'll handle dates soon. Handle dates soon. It's customizable. Okay, cool. I can have the credit. Oh, I can have the credit for starting this wave. I high honor. Thank you, Tanner. I had no idea you were here on YouTube. Sorry, I'll keep an

eye on the YouTube chat now. What else do we have here? Calling server functions from Hooks and components. Interesting use server function. Interesting, very interesting. So, if you want to just get the data in the route, you throw it in the loader. But if you want to load it client-side more traditionally, use server function to generate the function call that's safe, and then use Query to actually call it. Very interesting, really only to handle redirects and not founds. Okay, that makes sense. The thing I was going to question, use server function. I felt like that was an unnecessary abstraction, but knowing that by putting it here as a hook, handling things like redirects is much easier now 'cause you can Hoist the throw CU. If you throw inside of used query, Ed query will catch it and give you the error. But when you're doing a redirect or not found, usually that's hoisted through throwing an error, and use server function can throw the error high enough to trigger things. So, you wouldn't need the use server function at all if you don't have a redirect case in

the function, so I could literally just pass get server time to the query function here instead, and it would be fine. Good stuff. And if you want to call these anywhere else, you can. You won't have the problem that many had with TPC, where they were calling TP PC from trpc. It just handles that built-in really cool. As mentioned, server functions can throw a redirect error to redirect the user to a different URL. So if you throw redirect to URL, that'll handle the redirect as long as you're not catching this error before it can go up. I had a fun issue recently. I think I done with this in a video with P thing, where I returned a redirect in a TR catch. And because I was using the redirect in nextjs in the try, it got caught, so the redirect would never happen. Redirects can utilize all of the same options as router.navigate, use navigate, and Link components. So feel free to also pass path pram, search prams, and hashes. Again, tanack router, the only router that intelligently handles path pram search.

prams and hash. If you're not familiar with each of these, path prams are the things between the slashes, search PRS are the things after the question mark, and hash things after the hash. Doing these correctly with your router is so annoying that most routers gave up. Tack router was built around them, so if you have like really complex query parameters or you want to store more state in your URLs, isn't another option right now. You can also set a status code in the redirect, that's cool. Every router gave up, not most, yeah, every router gave up on these things. Some of them even redefined what certain terms mean. We can't use Query prams instead of search prams anymore because a certain router repurposed the term to mean path prams. Yeah, good call out here that send redirect will send a location header, which will force the client to hard refresh and navigate there instead of doing it on the server side. Good call outs also custom has headers on a redirect by passing a headers option, headers custom header value makes sense.

not found while calling a server function from a loader or before load route life cycle. A special not found error can be thrown to indicate to the user the requested resource was not found. Again, throw not found all makes sense. Handling errors here where it's going to get fun. Create file route loader. Try await do stuff. Catch error, and you can decide what you want to do from there. So, a server function throws an error. It will be serialized into the client as a JSON response along with a 500 status code. It's useful for debugging. You may want to handle these errors in a more user-friendly way. You can do this by catching the error and handling it in your route life cycle component or hook as you normally would. So, here you could return something different in the error case, and by doing that, you've now allowed yourself to handle the error differently, and you'll actually get a type-safe loader data in the components now. Good call out too that you have to call throw redirect so you actually see in the code what you're doing. So, if I

had to do that in next. It would have been much clearer. My redir bug was going to happen. No JS server functions without JavaScript enabled. There's only one way to execute server functions by submitting a form. I'm surprised you even added this, Tanner. It's cool that you did. I just didn't expect it. Oh, oh, I see. That was a big click moment for me. Check this out, guys. Demol loader. URL that will console log the URL that gets hit when you call that endpoint. So, if I copy that address, here's the demo loader. If I open that, we get back the empty object that that loader returns. I do more stuff here, more data. I chat. What is missing there? There are some errors. Try it with a form action. That's no fun. I'm just going to copy it, but the fine. I'll do it with a form action. I'll change it from demo loader to, uh, demo form post. Kill the input form action. Demo form post URL. And now, if I test, hit submit, server error, not found. Error was

encountered on the route with ID double root small bug or skill issue. I don't feel like figuring out which, so we're going to continue. Yeah, Tanner shrugged. I will find every single dumb way your code can break. That is my skill from the heavens. I break things every single possible way to pass arguments to a server function when submitting a form. You can use the input element with the name attribute to attach arguments to form data past your server functions. That all makes sense. Interesting to return data through that. I'm not going to dig too deep into that. You all get the idea. There's another thing this includes that I'm excited about API routes because a lot of projects don't have this. I was surprised to learn that um, what's the name of Dai's React framework? I know he's building a server component framework. I forgot the name of it. Waku? Yeah, Waku doesn't have support for API routes, which I was really surprised by. Cool to see it already included here. Apparently, Waku now has

API routes, but it did not when I tried, and it wasn't even that long. It was just a few months ago. We cool to see it here in the early Alpha. This is a lot of things to cover. I'm just happy this exists, routes API. Users TS will create an API route for API users, all different syntax for it. I like you can do the API dot syntax instead of slashes, pretty cool, interesting. If you have API routes in a folder that's for a layout, it will include that in the URL. I'm just pumped this exists and that I can define routes totally fine. This means an upload thing binding is going to be trivial to build as well. So, uh, that can be a fun thing for me to hack on when I'm back for my next trip. Pump that's there. SSR all works too. File exports a function that creates a server-side rendering handler. The handler is created using the create start handler function from Tanack start server, which takes an object, the following properties. I like how short the SSR page.

is beautiful, wonderful, and then hosting. It should work with any hosting provider they recommend for sell. Sure, it works other places too, and O. It's going to say clerk already provide stuff databases. Works convex. You use other Solutions as well. Cability Sentry static pre-rendering powered by Nitro. Also really cool to have static Pages starting point. There's a lot of cool in here. I could spend all day digging into the details, but the core thing I wanted to cover here is the actual experience of using it. I didn't even touch on the generated code side, the route tree which is generated. You don't have to write this code. It just creates it all for you, so you can do file-based routing, and the result is still traditional config-based, so debugging and figuring out what is where is Trivial. All of this is just generated for you. Well, I am very excited for what is coming out in the future. I will probably do a follow-up for uh, not just middleware, but for Server components as well. This is a very fun, very fun project.

and I am so excited to see it coming along. Let me know what you guys think. I am so excited for the future for Tan stack start, and I'm curious if y'all are as well if I should cover more tack start stuff going forward. Let me know. Until next time, peace nards.

Next.js has real competition now

Hi, I'm a software dev nerd mostly known for full stack TypeScript stuff. Check out me and my stack at t3.gg
