Tanner Linsley === Noel: [00:00:00] Hello and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket provides AI first session replay and analytics, which surface the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it free at logrocket. com. I'm Noel, and today I'm joined by Tanner Lindsley, creator of TanStack, co founder at Nozzle. He's here to talk about TanStack and TanRouter overall. Welcome to the show. How's it going? Tanner: It's going great. Thanks for having me. Noel: Of course. Yeah. I'm excited to chat today. This is, I feel like ~tan, ~tan stack in general is like this world where,~ uh, I've had like, ~it keeps ~kind of ~coming up in my periphery and I'm like looking for tools and stuff, but ~I've never, ~I've never jumped in at all. So I think this will be informative for me as well. ~Um, ~With that in mind, can you ~kind of ~give us an overview? ~Like what is, ~what is TAN stack and what's the purpose? Tanner: Yeah,~ um,~ so ~I, ~I co founded a company with some friends 10 years ago,~ uh, ~as a software startup. ~Uh, we were, ~we were basically reverse engineering Google search,~ uh, ~to provide ~like ~rankings and search. Analytics to marketers and SEO people. [00:01:00] Needless to say, it was very difficult challenge to take on,~ um, over the, ~over ~the 10 years, ~the last 10 years of nozzle,~ uh, ~save one or two years, I've been the only front end person at the entire company. ~Um, so. ~I have had a lot on my shoulders over those 10 years. And I knew that I needed to utilize open source software in a good way to make everybody else help me be as much of a 10 X dev as I could. ~Um, ~so ~I, ~I started building these tools. ~Uh, ~the first one was react table and then I built ~a ~react form and then I deprecated react form and then I built ~a ~react query. ~Um, ~and then after that, I've just ~kind of ~been building other libraries. So I built a virtualizer, like ~a, ~a windowing tool. ~Um, ~like you said, ~I'm work, uh, ~I'm working on a router. So I launched that router last year. ~Uh, ~and now I'm working on a full stack framework. ~So it's, ~it's a collection of open source utilities that. ~Um, they ~don't depend on each other other than the router and the framework. ~Uh, ~but they do work really well together because we've built them ~just kind of ~with our ideals of, ~you know, ~type safety and [00:02:00] headless UI and really powerful state management primitives behind all of them. Noel: ~Nice. Yeah, I want to, ~I do want to spend time getting into TAN routers specifically, but I think before we delve in, I'm curious, was there like ~kind of a, ~a long term plan or like an overarching philosophy that drove this, or was it kind of just like you had problems and you're like, I could solve this better than the tools on the market, or I have this specific need and I'll solve that one and then ~kind of, ~it just emerged. Did it kind of just emerge over time or was there ~like a, you know,~ a roadmap ~in your,~ in your brain to some extent? Tanner: There's definitely no roadmap. I mean, the roadmap was with nozzle with the features and the things we wanted to do there. ~Um, ~and ~you know, ~sometimes it was assessing the market and saying, okay, there are no good tools for this thing. So I'm going to build it. Other things,~ uh,~ like some of the other libraries. Like router for existence was more of a, ~you know, ~we address the market and there were good tools and we use those tools until we felt we were about to outgrow them. ~Um, ~at which point, ~you know, ~we would look into contributing or making them better ~or, ~or potentially building something better [00:03:00] ourselves. And that's ~kind of ~how some of the later libraries came to be. Noel: ~Gotcha. Is there, are there specific use cases or like,~ Was there a persona in mind when you were kind of set out to make these tools ~or, or is it, ~is it the same answer? It's just like ~what, ~what you needed at the time was what you built. Tanner: Yeah. ~I mean, ~I was the persona. ~I. You know, ~I was ~a kind of ~a solo front end dev,~ um,~ looking to get as much work done as fast as possible, ship features as fast as possible, and do it in the most ~like, ~safe, reliable way. And ~we were, you know, ~we were building enterprise software,~ um,~ so ~we wanted. ~I wanted to build software that would, ~you know, ~resonate ~with that, ~with that type of individual, somebody ~who's, who's, you know, ~building dashboards and, ~you know, ~widgets and high interactive components and working with a lot of data. ~Um, ~probably there's a lot of data visualization, ~you know, in, ~in TAN stack or tools that lend itself well to data viz. So it was definitely more geared towards an advanced user and ~that got, ~that gets better as. ~You know, ~we release libraries and ~kind of ~pare them down and make them easier ~to, ~to understand, ~you know, ~the very first version of react query was not as simple to use as it is today. ~Uh, ~but as,~ as, ~I open sourced it and ~kind of ~massaged [00:04:00] it over time, it got better and better. ~So, ~ Noel: ~Yeah. I mean, I feel like, ~There are probably a lot of devs in somewhat similar situations to this, right? ~Like~ Like working ~on this, these kinds of, or like in this, in this,~ in the front end space where they're like, have tools they're building internally, or they're feeling the limitations of things. But I don't think this is a super common Story, right? You don't hear about ~these kind of like ~devs working on something internally at ~a, a, ~a for profit entity and then being like, you know what, it would sure be cool if ~like, like, or I could, ~I could build something that had a lot more utility,~ uh, ~and I could share this, ~you know, ~with other devs,~ like, ~was there something that led to this being the outcome here versus what you think happens with other companies? Or was it just kind of like ~a, you know, the, ~the outlook that you had and the way you wanted to do it? Tanner: I've always been into open source software. ~Um, ~I just like the idea of sharing and helping people, especially when it comes to like front end tech, there's not as much,~ uh,~ intellectual property, or at least the feeling of intellectual property around front end software, like client side software. So a large part of me just ~kind of ~thought, why wouldn't I share this? You know,~ so, When, ~when they built these tools and I thought they were cool. I just wanted to naturally share them with other [00:05:00] people. There's also some of it that is ~like, you know, I, ~I knew at the time that I wasn't going to be able to hire,~ uh, you know, ~a 10 person, 20 person team to come into nozzle and help me ~build, uh, you know, ~make these proposed internal libraries better. So if I open source them, I can get the eyeballs of potentially,~ uh,~ Thousands to hundreds of thousands of developers on them. ~Um, ~and if I market them well, then it could even be bigger than that. And every single person that comes in and helps me answer a question or test a use case, or, ~you know, ~push the limits of an API. Really,~ they're, ~they're just improving the software that I'm using to build my product. So it felt like it was a win win. Noel: Nice. You mentioned~ like the, you know, ~getting these tools out there, the capacity to like market them and get eyes on them. I feel like something I've seen quite a bit,~ uh,~ when people are talking about these, the set of tools, 10 stack in general is like the docs being really strong. And like easier to parse than a lot of the other, ~you know, ~like docs for analogous tools in the markets. ~Uh, is there something that like, is, I guess, ~was that an intentional, like goal of yours to make these docs like [00:06:00] super parsable? Is this part of that marketing or ~is this just, ~did it just ~kind of ~naturally,~ uh,~ come to Tanner: ~Uh, ~yes, and yes,~ I, I mean, I, ~when I started writing the documentation, I wasn't saying, Oh my gosh, I need to make this as friendly and easy. I mean, yes, of course I want it to be friendly and easy to read. Okay.~ Um, I, ~I didn't necessarily consider that like a strength that I might have or that I would have. I realized that it is now,~ um,~ but in the moment I was just like, I got to document this stuff. So people know what they're doing. ~Um, ~and I just wrote it in a way that I thought I would be able to teach somebody kind of like a course, like, Hey, just introduce you to concepts slowly ~and. ~and build up knowledge and then show you how to use it. So I don't necessarily, there wasn't like some pattern or formula that ~I was, ~I was following. ~Um, ~I just wanted people to understand how to use it and why I thought it was important. ~Um, I, I did spend the last, you know, over the, ~over the years in the last 10 years, I was in the SEO industry rubbing shoulders with a lot of really talented and wonderful marketers,~ um,~ and organic SEO leaders. So I was able to ~like ~take some of, ~you know, ~their tips and [00:07:00] tricks and things to ~kind of ~learn how to market online a little bit better. ~Uh, I, ~I will definitely accredit some of that to them. ~Um, ~but for the most part, ~you know, ~even internally at nozzle being like an SEO bound,~ uh, ~company in the SEO space,~ we, ~we still know and recognize that ~it. ~It all comes down to content. If you build the right content and great content, the people will come. ~Um, ~and ~they will read, ~they will read it and watch it and love it. So I tried not to focus too much on the technicalities and just. ~You know, ~I wanted my documentation almost to be fun to read. In fact, it had to be fun to write because I don't know about you, but documentation is not fun to write. ~Uh, ~so anything I could do to spice it up and be like, Oh, this is actually fun for me to write. ~Um, ~hopefully it will be fun for the user to read. So Noel: Totally. ~I mean, I, ~I think ~that that'll, that I, like, ~that'll make sense to me, but I have to imagine that ~most, ~most library authors set out, they're like, I'm going to make my docs good. Right? ~ that's like, ~everyone has this kind of idea. Is there something in particular that ~kind of, ~you think ~makes them ~made the, ~You know, ~10 stack docs pop a little bit more. ~Like, ~[00:08:00] was there any mental framework that you went through or anything that kind of helped, ~you know, ~or you ~like ~found this to be a good way to learn ~or, ~or get through documentation? Or ~do you think that you just kind of like, do you think most other, maybe this is a cleaner way to ask this question. ~Do you think most other document authors are ~like ~losing the forest for the trees to some extent when they're trying to write their ~doc ~documentation? Tanner: maybe some of them,~ uh,~ I'm sure some people struggle with it. I know some other devs Friends who are really great at writing documentation. And ~I, ~I read through it and I'm like, yeah, this is fantastic. And I'm almost jealous. ~Uh, ~in fact, I really enjoy like the solid JS docs,~ uh, ~that ~Ryan, ~Ryan has written,~ um, ~and ~usually a lot of, uh, ~most docs from like the view ecosystem ~are, ~are really fun to read maybe just cause they're different. Yeah, ~but you know, I, ~I don't think that,~ uh, ~people are like missing the boat in any major way. I just think that some people have a little more personality that comes out in writing than others. Some people stay really technical and some people like to go out and be really personable. And I think it's about finding a balance. ~Um, ~because there are docs out there as well that get a little too loosey goosey and unprofessional.~ And, ~and I think it gives off the wrong look. ~Um, you know, ~like ~making, ~making a ton of [00:09:00] jokes. ~Um, ~and ~you know, kind of ~having a lot of banter in the middle of your documentation might seem fun. ~Uh, ~at first, and you might seem like you're being quirky and funny, but if it's ever distracting from ~like ~what the developer is actually there to do, then that's what it is. It's a distraction. ~So you've got to find the right balance of, um, you know, ~it's like giving a talk. You want it to be entertaining, but you need to get your point across. ~Uh, ~it's not very different from writing an essay, Noel: ~Mm hmm. ~Totally. Yeah. ~I mean, ~I feel like. Yeah, ~there's, you know, people, people on call, ~you're on call, it's three in the morning, you're trying to fix some bug and you're like going through docs~ know, ~trying to parse through jokes that some document writer, like,~ like,~ I'm sure this was funny at the time, but ~like, ~I am not in the headspace to appreciate the humor of this right now Tanner: ~Right. ~You're just like, I need answers. Noel: Yeah, exactly. ~Yeah. ~Yeah. ~Like, ~it's interesting to hear you say that and,~ um, kind of ~hear your response be.~ Uh, ~like focusing on just ~kind of the, ~the tone and, ~you know, the, ~the capacity to keep people interested, because I just feel anecdotally, at least when I see people talk about the docs,~ it's,~ it's more that they can like, just answer their questions, ~like ~figure out what they need to find. More easily,~ um,~ or find what they need to find more easily. Do you think ~that ~[00:10:00] that is ~like, ~is a,~ uh,~ misattribution or do you think that those people, ~you know, like ~are actually onto something ~in there in the, ~in the docs being slightly more possible than something ~like,~ Tanner: ~I think, I think they're on to something, um, yeah, ~I think they're on to something and I think you have to approach it from different angles. I think ~everybody makes the mistake of ~a lot of people make the mistake of thinking every developer thinks like they do. In fact, I would say that many developers are ~like ~neurodivergent, right? ~Um, they're, ~they're just ~kind of ~built differently. And so I like to think of my documentations as having multiple entries and multiple pathways through the docs. ~Um, ~there's going to be people who come into a. Getting started like a quick start and they're going to paste that quick start in there. And then they're never going to come back to the docs ~until, ~unless they get stuck. And when they do that, they want to come back and just command K and search for the thing that they want. So you've got to have really good anchors and pillar page sections for all the different concepts that you have. And then there's going to be people that just want to read through all of the documentation. So from that perspective, you also have to have ~like ~a guide. ~You know, like, uh, like, uh, ~I always think like Nintendo power, right? ~like, ~[00:11:00] they just want to read through the entire thing ~and, ~and just learn text based until they feel confident enough to get started. So ~you have, ~you ~kind of ~have to have that linear journey and that's really difficult because it's more like a course than it is just ~kind of ~technical documentation. And then there's going to be those people that are really highly technical and they want to. ~You know, ~they see a new concept and they just want to learn everything about it before they move on. So they're going to be jumping into the API documentation, into the source. They're going to be looking at function signatures. ~You know, they're going to, ~they're going to be investigating very thoroughly on specific topics. So I just, I like to put these hats on periodically as I'm writing the documentation and say,~ Can, ~can each of these types of people get in and be productive? And ~I, ~I'm sorry to say that right now, all of our docs are not great for each one of those people. ~Um, ~but then I'd say the fourth secret is just feedback. Like if you get negative feedback about your documentation, ~like ~don't tell them to take a hike, say, Oh, ~I ~I'm really sorry. ~Like, ~I want to know where you got [00:12:00] stuck. I want to know where, ~you know, ~you had a hard time and ~I will, ~I will listen to you and help out. Like you can help us and make it better. Noel: ~Yeah. Yeah. I think there's, ~there's definitely like an impulse there. I think, especially like, say ~you got, you know, ~you have a support or discord or Slack, like chat and someone comes in with a question. I feel like you see it time and time again, the community and the developers is like, it's right here in the docs. Like, why did you not try to search for this yourself? And I think that there's an assumption, like this person didn't try. So that's not used as like an opportunity to improve the process to find the thing. And it's instead just like, it's right here.~ Um,~ Um, do that a lot with discord We have a discord server for all of tan stack Which makes it easy for people to come in and search through questions that maybe didn't make it into the docs ~and ~and not into It could get hub issue. And so I think that's really helpful and we use those as seeds for like, okay We're getting this question a lot, ~you know, ~let's write some first class documentation on it and then just point people to that. Tanner: ~So it's kind of like, uh, ~I always think of ~Kent, ~Kent C Dodds, a good friend. He just loves writing blog posts. ~Uh, ~he gets one [00:13:00] question about something and he'll write a blog post about it and never answer that question again. And I think that's great. ~Uh, ~I hate writing blog posts, but I don't mind writing documentation. So I ~kind of ~try and employ the same tactic for docs. Noel: ~Nice. Cool. Yeah. ~I think ~I, I could, ~I could go on to like there cause I feel like information discovery like this, especially for ~like ~tools and libraries is a super interesting topic, but ~I want to get, ~I want to get into ~some, ~some specifics here. So ~we gotta, we gotta keep the, ~keep the train rolling a little bit. Let's talk about Tanner: move along.~ move along.~ Noel: ~Yeah. Yeah. Um, ~can you tell us more? About like why you think ~there, ~we needed another router in the react ecosystem. Tanner: ~Uh, yeah. So, uh, I, again, ~I was building. A SAS application at nozzle and,~ uh, ~it just got really, really big. ~Even for, ~even if it was for a team of people, it just got big. So it was a lot, even just for me to handle. And I found myself,~ um, you know, ~I used the URL for state because all of our clients needed to be able to share URLs with their, ~you know, ~coworkers to say, Hey, check out this thing, or I just found this anomaly ~or, ~or, ~you know, ~look at this and we needed a hundred percent consistency across all these dashboards ~and they had, ~some of them had, ~you know, ~anywhere between, ~you ~Two and [00:14:00] seven widgets on the screen with data grids inside of some of those widgets. It's a lot of states to manage for each one of these pages and I needed all of that in the URL. So basically dumping just hundreds of lines of JSON into the URL is no easy task. ~Um, So ~one of the problems that we had was ~we would, ~I would write links to go from one dashboard to another to say, Oh, you want to drill into this thing. ~Well, ~I got to make sure that, okay, I'm sending you to the right dashboard, and then I have to make sure that I'm setting the right search parameters,~ um,~ with that link. So that ~they'll, ~they'll land in the right spot and ~then ~I won't break anything and keeping track of all of these search parameters was really, really difficult. I tried using constants. I tried using, ~you know, ~validators and validations and some of that helped, but at the core of it, I just needed type safety. I needed to know that. Do I have any links right now that are pointing at dashboards that are just incompatible? ~Like, can I, you know, ~can I group by this column on this dashboard? I have no idea [00:15:00] because ~it's, you know, ~it's just a string. So ~I, at the, ~at the end of the road was search parameter manipulation and type safety and validation. And the road to get there was bumpier than I thought because to get there.~ Um,~ I wanted to have good primitives all the way underneath that. So I wanted to have type safe routing in general. I wanted to be able to know all of the paths, all the dashboards that existed,~ um,~ catch typos, ~you know, ~catch properties that don't exist and values that aren't compatible. That's ~kind of ~what sent me on the journey. So it was actually four years ago. I started trying to retrofit react router with. types, and it just didn't really work out that well. I, I tried to even, I did retrofit react router with a lot of the search parameter APIs that I have today in 10 sec router. So all of the cool ~like ~search param state management APIs that I have. Those were in a,~ a, in like ~this layer that I built on top of react router and that worked okay. ~Um, but ~when I wanted to pursue type safety and make those search [00:16:00] parameter APIs a little bit more powerful,~ um, ~I had reached out to the react router team. ~Um, ~and even Kent at the time who was working for remix and ~kind of ~said, Hey, this is what I'd like to do. ~Um, ~these are the APIs that I would need access to. And they were kind of like, Oh, that's interesting, but we're not really interested in that right now. And I was like, okay, are you sure? Because ~like, ~if, ~you know, ~If I can't have this, I'm going to have to find some other way to get it, ~you know, which is, ~which at the time I was like, am I going to have to fork react router and, ~and do my own, ~do my own fork, you know? And so they ~kind of ~just weren't interested. And I said, ~you know, ~that's fine. I realized,~ uh, no, ~not everybody's interested in these,~ um,~ advanced use cases that I have. So I started building my own and I decided not even to fork react router. ~Um, ~I just wanted to understand. ~Like ~how to build my own router first. So I built a library called react location,~ um,~ which was not type safe, but had all of the APIs that I wanted in it.~ Uh, ~and it even had things like loaders and actions and things that were only in remix at the time and not in react router. And ~it was, ~it was pretty fun. ~Um, ~and I built it all from scratch. I really wanted to [00:17:00] understand. Like how to do this from the ground up. And once I did that, I was like, Hey, this is really cool. People are interested in it. I said, now let's do type safety. I tried to retrofit react location with type safety. And it was like impossible. It just, I could not do it with the architecture that I had, which was honestly ~very ended up being ~very similar to react router and water and ~everything,~ every other router out there. ~Um, ~but I just couldn't do it because ~the, ~the APIs ~that we had, ~that we were using were not designed for Typeflow.~ Um, ~so I had to ~kind of ~rip everything down and redesign everything from the ground up for Typeflow. And ~it, ~it ended up having some wonky APIs ~and, ~and going in the direction of like file based stuff. So it took three years,~ uh, ~like two and a half, three years of polish to get it to a state where I was like, Hey. I'm releasing this new router called TANstack router. ~Um, ~because after react location, I rebranded everything to TANstack so that I could do cross platform cross,~ uh, ~framework libraries. [00:18:00] So TANstack router is ~kind of ~the successor to react location. And in my opinion, it was the first router to really do fully type safe stuff. There were some routers that came really close, ~probably, uh, Um, ~I can't remember one of the best ones, like type droughts. ~I think I have it. Um, I, ~I really do need to pay homage to this router because~ up until, ~up until I built mine, it was probably the best one. ~Uh, ~Chicane, Chicani,~ um,~ I think ~it's, ~it's C H I C A N E. So ~it has some similar. ~It has some similar concepts in terms of like type flow, but the APIs are extremely different. ~Um, ~and I actually found it halfway through building TanStackRouter and ~it, ~it helped me solidify some of my assumptions about it. But, Up until that point, ~like ~it was basically the best one. ~Uh, ~and it wasn't very popular. ~Um, ~and it's not its fault. The people just didn't care about type safe routing. I'll be honest. And that's where ~like ~a lot of that ~education, like ~educational marketing comes in after I launched 10 sec router, ~like I had to, ~I had to teach people that like, Hey, what you're doing is [00:19:00] not safe, ~like ~in terms of programming, like ~we.~ We're adopting TypeScript as an industry now for everything except for routing and we're just passing magic strings everywhere So it's been a rough road for education But I think a lot of people are now ~that they're ~tasting the developer experience that you get from it Like it's not just oh, I have to write all this type safe stuff. Like we built it to be a hundred percent Inferred type safety. So ~if you're doing it, ~if you're doing it right, which is easy to do, you don't really write in TypeScript at all.~ It's, ~it's ~kind of ~magical. Noel: Yeah, I find increasingly so ~like as ~as we're getting to maturity here ~Like ~I love typescript But I'm finding that ~like that live I'm having ~the libraries that I'm using and stuff are making this ~so ~so easy that ~like I'm Never ~I'm very seldom ~I guess ~defining types manually because it's just like data in data out and ~it's like ~the types are flowing and giving me nice checks, but ~like ~I'm not having to sit here and like almost to the point now or if I am like start do manually specifying types and complex types. And ~like, ~I feel like I'm doing something wrong here because I should be leaning on a tool which can just ~kind of ~[00:20:00] do a lot of this foundation work out of the box for me. ~Um,~ Tanner: ~I'm very,~ I've become very sensitive and conscious to ~like, what, ~what input am I giving the library to make it be type safe? And, What is the,~ like,~ what level of hackery is the library doing to deliver that back to me? ~Right? So, I mean, ~cause it's one thing to just, Hey, I'm going to write this library to have generics and use generic parameters and just ~kind of ~flow things normally. And then you start getting into some like more complex stuff that's,~ uh, like, ~Oh, you know what? We have to generate some code. And then there's other really big questions like, how much are you generating? And ~You know, ~what's the developer experience like, what's the performance like ~we're, ~we're getting into some TypeScript performance stuff with TAN stack. That's crazy. Like we have tests that spin up thousands of routes in a router, all of them using inferred schemas from Zod. And we're like, we're trying to, we're testing the IDE for response times.~ So. ~It gets really deep really quickly. ~Um, people don't really understand how deep it gets. Hang on just a second.~ ~I want to show you something. This is you and, you and mom. Oh, it's, it's okay. Close the door. Yeah. Okay.~ Noel: ~No sweat. No sweat. I'll ease us back in. It'll be beautiful. No sweat. That was a pretty good Mr. Potato Head though.~ Tanner: ~Close the door. Yeah.~ Noel: ~Nice.~ Tanner: ~All~ Noel: ~so I do like, is there, I guess I'm curious I think a lot of the,~ you're right that there, I think a lot of devs were not ~kind of ~[00:21:00] cognizant of the the Danger. They're putting themselves in here, ~right. ~With just the,~ like,~ Oh, we're just going to do routing. And they're like, isn't really any type checking ~happen ~happening here. But I feel like typically where that would become a problem is like, as things change over time, ~right. ~It's like, Oh, I'm like adding a new sub path that like this route is. Is changing. Is there anything specific in tan router to ~kind of ~help with that problem? ~Like ~as I mutate a given code base, is there anything like, Hey, you might have URLs that are pointing to an old thing. And if so, how is that ~like ~tracked? Tanner: ~Well, it's, ~it's static. So TanStackRouter uses,~ it's, ~it's all statically compiled with TypeScript. ~So we don't, um,~ We do generate some things if you get into ~like ~file based routing,~ um, ~and tensex start like framework level stuff, we are generating some helpers based on all of your routes ~to Most ~mostly for performance. ~Um, ~but what it allows us to do is just know about your entire route tree at front. In fact, I I'm lying. We don't have to generate anything for you to do that. Tansec routers built with code based routing. So all of the types flow down through your entire [00:22:00] app. And the way that it works is if we know about your entire routing configuration, we know what every single path is that you could possibly have. We know about the paths, we know about the dynamic parameters in those paths, and we know about the search parameters and which routes and paths they belong to.~ Uh, if you ever, if you, ~if you were to go and you have this app that you've been working on for like a year or two and you go to one of your routes and you change the path, ~you know, ~you say, Oh, you know what, instead of dashboard,~ it's, ~it's ~panel or something, you know, ~admin panel or something, and you change the path. ~Well, you know, ~you could run TSC or just look in your editor for errors, and it's going to show you all of the links that you have going to dashboard that are now erroring out. ~And ~it's going to say, Hey, dashboard does not extend the possible route paths here. You probably need to check this out and you can do the same thing with search parameters. ~Like ~if one of your pages,~ uh,~ needs to change the name of a search parameter that you're using, you can change it in your Zod schema or just in the [00:23:00] type that you're returning. And now all of your links that are trying to use that search parameter ~will, ~will fail. So ~there's, ~there is like CI level protection here. ~Um, ~and ~I think, ~I think that should not be underestimated. Like how important and cool that is because it's, we're not doing anything crazy. ~It's just using type. ~It's just using TypeScript.~ Um, ~now ~I, I'm not gonna, ~I'm not going to point fingers too much or ~like, you know, ~create too much fun here, but I do want to illustrate,~ um,~ like the complexity of what we're doing because in the very near future, you're probably going to see ~other frameworks, ~multiple frameworks launch their own versions of type safety. ~Um, ~and they're not doing it ~like, ~like we're doing it. ~They, ~at least as far as I know, they're going to be writing,~ um, ~the TypeScript plugins, IDE plugins that,~ uh, ~hook into the language service provider. They only run in your IDE. They're not doing anything during TSC and similar to Svelte, ~they're going to, ~they're going to end up having to wrap,~ um, ~TSC and make their own ~like ~hacked up TSC thing that ~when you, ~when you run TSC, you'll actually be able to type check your stuff. ~Um, ~[00:24:00] We're not even getting into ~like ~that level of craziness. Like we're just obeying the rules of TypeScript. Building it how types would normally flow. So you just get to fall back on regular TypeScript stuff. And what that means is that as TypeScript improves and gets faster and they make changes in TSC or the language service upgrades or whatever, we don't have to worry about any of that. Cause ~we're, ~all we're using is public API. ~Um, ~So like ~this, ~this recent change where TypeScript is only type checking the lines that you're looking at in your file, like we didn't, we, ~you know, ~we didn't get broken by that. We don't have to worry about anything like that. So,~ um, ~yeah, I think that's important ~to~ Noel: ~Yeah. Yeah.~ I think, yeah, ~that, ~that is ~nice.~ Nice to see. And again, it's ~like, ~I think ~it, ~it leads to more code portability and like less breaks over time. If you end up in some product that's on an old version, you're not going to have to be like ~doing all this, ~doing all this juggling. And I think ~that'll, ~that'll be nice too. I guess to circle back a little bit ~back ~on this, like route safety and will things break? ~Um, ~I think you ~answered, ~answered the question I asked. But ~I'm, ~in my head, ~I'm also, when I, ~when I'm thinking about this thing, I'm also thinking about like external links. [00:25:00] Into apps. And I think that this is a thing that I've thought about for a long time, right? It's like people are sharing links to stuff and there's like links on, ~you know, ~old links and social media. And there's just like links to old specific sub pages and apps all over the place, I suspect. But I've never seen anything that like does a good job of ~like, you know, like, ~Hey, ~there, like ~this was an old valid path and now you've changed things like this is going to break. ~Is, ~have you guys thought about that problem at all? ~Like, ~is there anything that. ~You know, ~any ~like kind of ~paths to mitigation? Cause it feels ~like we're almost ~like with ~what, ~what is being generated here. You could almost have the, like, here's the old version. ~Like ~something's changed. Like, Oh, we need ~like ~a migration path. ~Like, ~is that a thing you guys have Tanner: Absolutely. And so I thought about it for search parameters, but not with paths. So with paths, I ~kind of ~just expected people to say, Oh, ~you know, we're, ~we're breaking this path. Let's create a redirect. So you leave the old path around, you create a redirect that redirects back over.~ Um, ~but ~for, ~for search parameters, I did go down ~this, ~this route pun intended. ~And, uh, ~and basically what we have, we even use this at nozzle is we have different schemas. ~So, uh, ~you can actually provide different,~ um, it's, ~it's a user land abstraction [00:26:00] I created inside of nozzle. So you ~kind of ~have to do this on your own. But we created schemas, different schemas for different versions of our search parameters. And as people would come in, if we detected the old search parameters, we would write transformers to go between the versions, very much ~like, you know, ~a database migration. ~Um, ~and so they would come in and even if they came in on a link that was really old, ~like ~two or three versions back, we could detect the version number, ~Pick the right, ~pick the right entry and then just run the search parameters through the migration path and then do a replace on the URL. And they would end up right where they should. So it's a little more complex in practice,~ um, ~than I'm making it sound, but it definitely works when you start thinking of the URL as like a schema. ~Um, ~as in ~like ~a database schema that you need to version and migrate, things get a lot simpler, like you said. ~Um, ~yeah. And ~as for, ~as for the path stuff,~ uh,~ I think ~it, ~it would probably be more of a. Terrible DX, in my opinion, Noel: be hard. ~Yeah,~ Tanner: ~to, ~to say, Hey, ~you have to,~ you are forced to keep your old path schemas around Noel: [00:27:00] correct. Yeah, it Tanner: safety ~in,~ that would go with that would be ~really, ~really crazy. ~So,~ Noel: would be hard because I feel like Tanner: I have thought about it. Noel: that's, ~I mean, ~I think that's ~the other, the, like ~the other edge to this sword. Is it like, as soon as you start doing that, right? ~Like, ~or as soon as you have to start having to write migrations, ~it's like, it is, ~it is more work for the developer, like ~for, ~for, in both of these cases in that,~ like, ~especially someone new coming in, that's ~like, ~doesn't understand ~this, this They're, ~they're just not thinking about this problem. Cause they're like, ah, ~I'm in, ~I'm in the early stages of an app. I'm just developing internally. If I go and ~like ~do a commit, that's going to change query string or then all of a sudden I get this ~like, ~Oh, you need to handle the migration. I'm going to be like, what? ~Like, ~I don't even know what you're talking about. Tanner: Yeah. It's ~kind of like, ~you don't want to do that until you're in production. And once you're in production, yeah, it's, you don't want to have to learn it after you get into production, which is why ~I just think it's easy at some. ~I always say this to people. At some point, you have to be a developer. You have to be an engineer. At some point you have to do your job. ~Right. ~And I think that remembering to do redirects and remembering that if you're breaking A search parameter in a new schema, like ~you, ~you just, you have to handle that. And if you don't, that's fine. ~Um, ~sometimes you don't care, ~you know, there's, ~there's [00:28:00] apps that break search parameters every day and people are fine, ~you know?~ Noel: but every time it does happen, every time I get one of those, like my query string just gets cleared. I'm always like, ah,~ somebody,~ somebody wasn't thinking about this. ~It's the~ Tanner: This is why I like Zod too. Cause Zod, you can set defaults. So ~it's, ~it's like, ~uh, you know, here's,~ Oh, here's my new schema. We still have the defaults. So if things go terrible, like you can at least recover to a decent state. Noel: yeah, no, ~I love, ~I love,~ um,~ cool. Yeah. ~I feel like, ~I feel like we covered a lot. I guess I want to keep digging in, but ~we should, ~we should talk about the future a little bit. What's ~kind of ~on the horizon for, ~uh,~ tan router, tan stack at large. ~What are you, ~what are you working on right now? Tanner: So right now I'm working on tansec start, which is just ~kind of ~the full stack layer to the router. So tansec start is like 95 percent tansec router and the other 5 percent is basically an SSR entry point powered by Vinci, which is powered by Nitro Noel: Nice. Tanner: And with that, you can deploy anywhere in fact, you just change one option in your config to one of these, ~you know, ~options say, Oh, I want to go to Netlify or I want to go to Vercel. ~Um, ~we [00:29:00] host all of our stuff at Vercel. ~Um, ~I really like Vercel. So we ~kind of ~tested that first, but you can really take it anywhere that you want. And ~that's, ~that's kind of a really nice thing. So you get SSR out of the box and then it's also a bundler because it needs to bundle for that destination. And then we have server functions. ~So, uh, ~it's not just like use server. That's ~kind of ~the dinky toy version that I'm ~kind of ~calling it now. ~Um, ~we have first class functions called create server function that. Let's you not only pass a function that you'd only want to run on the server, but you can do a lot of other things like, ~you know, ~change the method headers, you can do middleware. ~Um, ~you can take a server function and expose it as like an API route so that you don't have to go duplicate logic between your server functions and an API routes folder. So yeah, we're working on tansec start routers, getting small upgrades here and there on some hidden features for now to make start work great. But that's what I've been focusing on for the last five months. [00:30:00] In fact, tansec. com we migrated off of remix to tansec start. Eight months ago now, I think it's been eight months. So we've been running tansac. com off of tansac start for a while. ~Uh, ~and it's working really well, so I'm very happy with it. Noel: Nice. ~Well, thanks for, uh, ~thanks for coming on and chatting with me, Tanner. It's been a pleasure. Tanner: Absolutely. Noel: For sure.