Ben: Hello and welcome to PodRocket. Today I'm here with Tanner Linsley who's the creator of the TanStack, which includes popular tools like React Query and React Table. And he's also VP of UI/UX at Nozzle. How are you doing Tanner? Tanner Linsley: Doing great. How are you? Ben: I'm doing well and excited to have you on. So maybe we can first start by jumping into the TanStack, which I'm guessing is named after yourself. And this is a bunch of very popular open-source tools in the React ecosystem, and maybe you can give us a quick introduction to them and what they do and how they help build great apps. Tanner Linsley: Sure. I'll start by saying I really hope that TanStack doesn't come across as ostentatious. Ben: No, I don't think so. There's a fair amount of companies that have tool space or tools named after their founders, like HashiCorp is, I think that's named after the founder and New Relic is named after the founder. Tanner Linsley: I mostly just needed something that wasn't my name, but could be vaguely branded. So- Ben: Yeah. No, makes sense. Tanner Linsley: ... TanStack seemed to work out. So I actually didn't make TanStack a thing until probably about a year ... No, about two years ago. Before that I was just building open-source just under my own name. And most of my libraries are still under my own name, but I'm trying to slowly move things over to the TanStack branding. But yeah, if you go to tanstack.com you'll see quality software and libraries for the modern web and I have a list of open-source libraries. So mainly React Query, React Table, React Charts and React Virtual are probably my foremost well-known libraries that I currently publicly want people to use. I have lots of others that I work on and that I use personally, but might not be ready for primetime yet, or at one point were and are not anymore. Ben: And maybe we can start with React Query. So what does that one do? Tanner Linsley: React Query is a data synchronization library for React. So if you've ever used a tool like Apollo for fetching GraphQL, it brings a lot of those same niceties and features of having a coordinator for queries, but without the necessity of using GraphQL. So really it is an interface around promises. So anything you can turn into a promise, you can use with React Query, including GraphQL for that matter. So React Query is just all about synchronizing data from your server or wherever you want really promises to your clients and making them more accessible in the React ecosystem. Tanner Linsley: You've seen a lot of people who they always start out building that little fetcher component. useState, useEffect. And we all know that useEffect is the biggest footgun created in React. But it's also really powerful. So React Query is basically there to help you not write that code over and over again. It's got all the major use cases of caching and deduplication and it really in a great way it gets you away from where we've ended up as global-state-managers. So there's lots of tools like Redux and Mobx and even creating your own with React Context. If you're doing that to manage server state and server data, you're probably taking a step in the wrong direction now. That's where a tool React Query would just come in and own everything and make it bullet proof for you. Ben: So let's talk about it a bit more. Let's say I have a REST API, have a React app, one way I could get data from the server is write some code that fetches data, sticks it in Redux. Every time I need to update they poll the server for new data, I have to write some logic that grabs that new data, puts it in Redux and then my app will update. How does React Query improve upon that experience for a lot of the common patterns you see in a typical REST based application? Tanner Linsley: So you make a good point. We're already talking about global-state, Redux. Everything you do with a global-state-manager like that is synchronous. So you are converting these asynchronous events that you're getting back from the server into the synchronous events. And trying to keep that state up to date. So the first thing React Query is going to do is get rid of the need to manage that on your own. There's not more set loading, set data, set error. All of that is handled for you. So it is a state machine. Under the hood it is a state machine that's managing all of that for you. So that's the first great thing that it's going to replace. So you're no longer managing your own state. Tanner Linsley: The next thing it's going to do is it's going to cache that response, so all that data. The same way that Redux would make it available through your entire app, React Query also makes it available through your whole app. So anywhere that you call that query again, in any component, as many times as you want, it's all going to get deduplicated into one query. That's not necessarily something new, but it's expected functionality, I have to mention it. Tanner Linsley: And then next great thing about it is usually people stop after they do the on mount event. Everybody does this with Redux or even React Context, you mount your component, you kick of the fetch, you get the data, and then after you get the data from there on out, updating that data through your application is a very manual process that's very granular. You have to say, "Hey, they remounted the component or they left the page, they came back, we remounted again." You have to fire off an event that's going to refetch that data. And you have to make sure that that fetch happens in the background so that they're not seeing a loading state every single time. So while you can still be very granular with React Query when you want to update, most of that event lifecycle of keeping your data up to date is just built in. Tanner Linsley: So there are a lot of automatic dispatched events through React Query to keep that data up to date based on user interaction. So you can customize that user interaction and those events a lot. But out of the box, it will automatically keep your data up to date as you refocus the window, as your network goes on and off, as new instances of the query appear on the screen and come off the screen. So there's not really the need to manually keep that data up to date anymore. It makes it feel like a subscription, almost like a WebSocket, but without WebSockets. And then it's not even using interval polling either. It's not on a timer. It's user input based refetching. Ben: Interesting. So it sounds like it's smart enough to know when a user interacts with a page, or you mentioned when the page is refocused after a period of being unfocused. Those are the triggers to fetch new data versus just saying naively every 30 seconds fetch the data. Tanner Linsley: Right. And you can still do that. If you want to put it on a timer you can. There's refetch intervals built in and if you want to hook it up to WebSocket events you can do that too. I do that at Nozzle. But out of the box, it's designed to be very friendly. It's also very aggressive with how often it keeps the data up to date, but you can tune that up and down as you need it. Tanner Linsley: Something that's unique to React Query is the concept of stale time on your data. Or data staleness. And what that means is that out of the box React Query is just going to always be refetching data from the server a lot. It's going to err on the side of let's keep this up to date as much as possible. Versus, sometimes you don't want to fetch the data that often. Either because you have API restrictions or you just don't need to, or the data's not changing. So if that's the case you can set something up called stale time on your query instances. You can say, "I'm okay if this data is stale for this amount of time before you refetch it." You can set it to 10 seconds, or 30 seconds, or you can even go all the way up to infinity if you just don't want it to ever refetch again. Tanner Linsley: A good example I give people is a Pokemon API is probably not changing that often. They're kind of locked in for a long time. So you wouldn't want to be refetching that all that time. You can set it to infinity. But a task list that you could be potentially sharing with other people, probably don't want that to get stale very often, so I would just leave it at zero. So that's the concept of stale time. And like you said, it is intelligent enough to know what data is being used on the screen at any given moment, and another unique feature that it has is that if you have five components that all subscribe to the same data, you'll have five instances of this query, but it's still just sharing one entity. But if all five of those instances become unused, if they unmount and drop off the screen and you're not using them anymore, React Query will mark that data for an eventual garbage collection. And by default it's about five minutes. Tanner Linsley: So if you have an app that your users are moving around a lot of screens and loading a lot of data into memory temporarily, and then moving to other screens, eventually you would run out of memory if you were loading a lot of data into it. Maybe every app doesn't run into this issue, but I do a lot of data visualization and querying in our products and that data can be very heavy sometimes. So that five minute cycle of recycling the memory and keeping things up to date, that's just built into React Query for everyone who uses it. So it's pretty neat. Ben: And React Query, does it have an internal Redux like store where data is cached? I think I've used Apollo before and I think I want to say they can integrate with Redux and actually store data in the Redux store. Is there something similar with React Query, or is it a different model? Tanner Linsley: React Query has its own store model internally. You can kind of see it a little bit as you create the query client. So one of the first things you do when you use React Query, you create a query client and you provide that to your application. That query client is where a lot of that state lives. And it's not just state for the queries, it's also state for any potential mutations that are happening as well. So it's a very specially designed store that's optimized to work with events around React Query's purpose. Ben: In terms of debuggability, can you use one of the various Redux logging tools or debuggers or something similar when you're trying to debug issues and see what the state was at a given point in time? Tanner Linsley: No. We did look into something like that early on as a way of integrating, but at the end, then event system internally was pretty custom and as you're just logging out those events, it got really, really noisy. You can imagine with refetches happening automatically all the time, just a constant stream of those texts or JSON dumps of those event would get heavy. Instead of going that direction we kept it internal and proprietary so that we could build devtools around it. The devtools for React Query are just built into the library. You just import them from ReactQuery/devtools. And the devtools are just a React component right now. You render them in your application and they just mount at the top of your app and the devtools are really unique because instead of just pounding you with all of these events, it takes everything and turns it into more of a GUI. Tanner Linsley: So there's a lot of color in coding and status updates going through these devtools that you can actually see through these color indicators and status indicators on each of your queries which ones are refetching when and if they're stale or if they're fresh, or how many observers on the page, how many components are observing that query. And of course the things you would expect from devtools as well like inspecting the data payload and the query settings for that query and manually triggering things and removing so they're much more involved and wholistic than say an integration with something like Redux devtools. Ben: Got it. Moving on, curious to learn a bit about some of the other tools in the TanStack. React Virtual is one I'm particularly curious about. Could you give us a quick overview of that? Tanner Linsley: Yeah. React Virtual is first and foremost it is a library for doing virtualization. If you don't know what virtualization is, it is the concept of windowing lists or windowing elements in your browser that might be very long. So if you have a list of 100,000 or even a million items, and you want to scroll through those items in your browser, you can't render all of those items all at once into the DOM or the DOM will probably choke. So React Virtual makes it so that it only shows the items that are within the view port or within the bounds that you have set, and as you scroll or move through those bounds, the items move in and out of that list making it look and appear as if it's a really, really long list, but really there's only a few items rendered at a time. So that's virtualization and that's what it does. Tanner Linsley: There're other libraries that have done this before and really well. React, let's see React Window, and there's one other one. Brian Vaughn has done a lot of work with these virtualization libraries and they're great. One reason that I created React Virtual was that I needed a headless solution and again, if you don't know what headless is, kind of a modern newish term in the ecosystem. But it means that it doesn't render any markup or styles for you. It's merely just the logic. If you were to go to react-virtual.tanstack.com and go down to some of the examples, you'll see that the way you use it is you just call use virtual, it's just a hook. And you provide it some basic information about the virtualizer you want to create and then you then take that information and the event handlers and the props and styles and you apply them on top of the mark up and styles that you are using in your application. There are a lot of benefits to doing that, and we can talk about those if you want. Ben: Yeah. I'm actually, it's an interesting topic. A couple of years ago when we were first building the MVP of LogRocket, in our UI there's a component where it's basically our recreation of the Chrome devtools log viewer. So you can have tens of thousands of log messages that need to scroll, so it's a good use case for virtualization and I used Brain Vaughn's React Virtualized for that component and definitely pushed up against the limits of not necessarily that component, but just got into some different edge cases. And shout out to Brian who is super helpful on the GitHub issues, helping patch bugs and answer question. But one of the things that traditionally can be tricky with virtualization is dynamically sized elements since the goal of the virtualization component is to calculate, what's in the current view port and if you have a bunch of elements that can change their heights, that can cause some trickiness. So curious how you handle that. Tanner Linsley: So React Virtual can do all three styles of item measurement. So it does have a static style obviously where each item is the same height. There is a variable style where each item can have a different height, but it's still hard coded and set to never change and known ahead of time. And then there's the dynamic style. And the dynamic style is very unique. This challenge difficult and React Virtual is by no means perfect, but I think that its approach is pretty cool. So out of the gate you need to at least give React Virtual some type of hint about how big you expect these items to be. They can all be the same size but just roughly, and just take an average of the size really is just fine. I always go with about 40 pixels tall, because that's about how most lists are. Tanner Linsley: But from that point, every time that you render an item React Virtual has a backing mirrored store of each item and its size. And it's full of gaps. It's full and gaps and unknowns and that's where the size estimation comes in to give you some type of scrolling that you can use out of the gate. But the cool thing is that we use React's ref callback features. So if you've ever used a ref in React, you can pass it a useRef object or you can pass it a function. And that function will give you the element, the underlying element, the DOM element and call that function for you anytime that it mounts. And this is really helpful because we can basically just give you a ref measurer utility and you can take that and place it on each item that you're rendering and React Virtual will know, oh, we just rendered item 150. And in a request animation frame, and honestly I can't remember the implication details, but we measure that item and all the other items that are coming through. And as we can we update that backing model with all of those heights. Tanner Linsley: So you'll notice if you go to the dynamic scrollable version, the scroll bar will be this big when you start. But depending on how those items actually get rendered out, which in the example, they're totally random, it's just, it could be any size between these pixels. As you scroll down the page, you'll see that scroll bar flex up and down, get bigger or smaller because of how the items that you have rendered are changing that backing store and changing the total height of the virtualizer. And because it's headless, we don't have to manage all of those styles in React Virtual, we just tell you here's the total height, how it's changing and here's where you are in that window. And it kind of just works. Ben: And so when you say measure, that's like you have an item, it could have any height, and you don't know the height until it's rendered in the DOM. And the browser, especially if you have fonts or things like that, that if you have overflowing text or different things like that, that make the height unknown until rendered on the DOM, you use the useRef callback and then just measure how big is this actual element once the browser renders it? Tanner Linsley: Yep. And we try and do that before paint too. So if you were to click the scroll bar immediately half way down the screen, those 10 items that pop into view, they're all going to render with that estimation size first. So it might even render 20 items, because it thinks they're all 20 pixels. But for each one of those individual line items it's going to measure them really quick and figure out what their total height is and then readjust before the paint happens. Ben: And this is really getting into edge cases, but one that I remember being pretty fun to deal with was if you have elements that can change height. For example, in our log viewer, similar to in Chrome, if an object is allowed you can click on it and it will expand. How are those handled with React Virtual? Tanner Linsley: So at the bare minimum we provide you some callbacks, some functions that you can call to like, "Hey, I want manually invalidate these measurements of what's there." And they'll get remeasured immediately. And that invalidation function of and remeasure everything is pretty darn performant. I've seen people who, my suggestion would be not to do animated expands in virtualizers, because you can just expand it and then call that function and it's very synchronous. There are people who want that animation expansion, and so I just say, "Well, then you need to hook into that animation loop of whatever is doing the animating for that and call the invalidator throughout that animation. And it works really well. So it just depends on how complex you want to make your virtualizer, what your use cases are. Yeah. I can't think of a good use case of why you would need a virtualizer to be animated height, like the items. But someone's going to come up with it and they're going to say it's important enough to us that it needs to work. So yeah. Ben: Yeah. That is always true when you're building something and I guess it's a good sign when people in the community come up with use cases you didn't think of and push the boundaries of what you're building. I'm curious, when you think about these different tools that make up the TanStack, are there any themes that unite these or better together kind of aspects of the different tools you're building? Or how do you decide what to build and add to this stack of tools? Tanner Linsley: Yeah. We could talk about an inception first, I guess. I usually don't build a tool without doing a lot of other things first. One of the main reasons that I would build a tool is because I need it first of all and need, that need comes from the other non open-source projects and companies that I work on. And mainly Nozzle. Nozzle is my startup. I started it up with two other guys and we've been going for eight years, and we've been solving some very, very difficult problems with big data and reverse engineering Google search results essentially and providing that data back to whoever wants it. And with that comes just a lot of challenges just for a modern web app. Tanner Linsley: And these are challenges that may not be super hot right now. Everybody seems to be talking about SSR and hydration and the things that might affect a majority of the web in terms of performance. But everything at Nozzle is on the other end of the spectrum. Everything's behind an authentication gateway. We're not going for first page load speed. It is very much an application that lives on the web and with that we've had to tackle different problems. One of the very earliest ones was tables. I just could not find a good table component for the life of me and I found some but they were just rigid or they didn't let me do things, not just the way that I wanted, but they didn't give me proper inversion of control. Tanner Linsley: And so I set out to build React Table, that was one of the very first libraries that I built, and I built it for Nozzle, because I needed it. And I built it until it matched my use cases in Nozzle and then I released it and stopped. And other people took it off from there and they kept improving it. And the same thing happened with React Form and even React Query. I needed those because I was bumping into the ceiling on some of these concepts in Nozzle. I wasn't getting enough data updates in Nozzle. We have shared workspaces and shared teams and people were saving things all the time and objects were changing. I'm like, "Redux is not cutting it." And so I found myself writing all these events to keep things up to date. Tanner Linsley: Pretty soon I had this custom thing and it was like, "This is big problem, I'm going to release this as a library." And that's where React Query came from. And the same thing with React Virtual, I needed to virtualize some things that I needed to own the divs and the styles, and I needed to know about the implementation of said virtualizer. And bless Brain's soul, I love his work, but it just that's not how his components were built and I'm sure he wasn't ready to just completely revamp all of his virtualizers for this one use case. So I like to vet libraries in the ecosystem really hard. I would rather not have to build something to proceed with my blockers at Nozzle, it just saves me time. But if there is a situation where there's a gap and it's going to help everyone if I just build something, that's why I build the tools that I do. Ben: And what has your experience been like open sourcing these tools? Some like React Query, I mean, all of the tools definitely getting some strong traction in the community. Has the decision to open-source generally been one that is worth it from amount of time you have to invest versus the returns you get from having the community members being involved, fixing bugs, finding edge cases, or have there been any cases where you feel like maybe you shouldn't have open-sourced it just because you haven't had the tie to invest as much as you should? Tanner Linsley: Most of the time it's been worth it. We're a very small team. I mean up until just a year or two ago, I was the only front-end developer at Nozzle. I was the intern and the VP. Playing all the pieces and doing all the roles. And it was hard because I didn't have a team. I didn't have people to help me or bounce ideas off of. So open-source was like my adopted team so to speak. I adopted the internet as my team. And if I could convince people to use these tools and help me make them better, I would essentially be outsourcing and exchanging that for some work. And it proved to be very helpful. Like React Table got a lot of support. React Query has a ton of support now. And at the end of the day, Nozzle is my biggest concern right now and it's doing great. Tanner Linsley: I'm very confident about all of the query in Nozzle because of all the great help that I've received. So it's definitely been worth it. It doesn't mean that it's always been worth it for every project. There've been some open-source libraries that I've built that just they either don't catch on, because they're not necessary or because competition is fierce and I'm a one man show with a full-time gig going on. One of those examples was React Static. I built React Static because this was back when Gatsby was getting started. And Next.JS was getting started. And I threw my hat into the ring with React Static as this static site generator that could do route based data fetching. Tanner Linsley: It was really, it was kind of ahead of its time a little bit to be honest, because everybody loves route based data fetching now. I just didn't have the dynamic part that Next.JS has. And it was really cool but at the end of the day it was merely just to build Nozzle's marketing site, because I didn't like the tools that were there. And that's not a really big use case for Nozzle. We didn't really want to maintain it. I didn't want to maintain it and honestly when you pitched it up against Next and Gatsby who Next has this awesome company Vercel behind it, who they have a lot of cash, a lot of people that they can throw into Next and they're doing that and you can see how it's paying off. I knew that that was going to be the case. I did not want to try and compete with that. Tanner Linsley: And then Gatsby, in a similar vein, they raised a ton of money and they still have raised a lot of money and they're throwing a lot of that into the Gatsby open-source project. And I'm like, "I can't compete. I'm a one man show and I can't compete against these 20 or 30 developer teams that who are contributing to these projects." So situations like that where it just makes sense to just let it die. And I didn't really let Static die, I handed it off to somebody who was going to appreciate it and take care of it more than me. Tanner Linsley: And another great example is React Form. React Form was, it was early in its time and some people still use it. I use it at Nozzle, but I can recognize that there are libraries like Formik and React Hook Form, and React Final Form. These are really, really great form libraries that they have a lot of features and a lot of great things about them that I don't have in mine. So I just quietly decided to retire that library at least from pitching it to people and trying to get people to use it, because I'm not doing open-source for the attention. I'm not doing to stroke the open-source ego as some people say. It really is just a means to an end for me to solve these bigger problems and hopefully problems that other people are experiencing as well. Ben: You mentioned before you're building this company Nozzle. You've been working on it for the past number of years and you said that you pulled data from Google and did a lot of interesting big data stuff. Just curious to learn a bit about Nozzle. I'm not super familiar with the product, so maybe you could give a plug for what you're building. Tanner Linsley: Sure. Yeah, if you want to learn more about it you can go to nozzle.io, that's our website. But essentially we are reverse engineering Google's search rankings at scale. What the people in the SEO community call that is SERP or rank tracking. And so we are very much an enterprise scale SERP or rank tracker. What that means is that you come to Nozzle and you enter in keywords and phrases, things that people would search in Google that are in the vein of your business and your marketing department. We have people with 100 keywords that they want to track and we have people with tens of thousands of keywords that matter to them. And those keywords can be modified with languages and devices, whether you're on a phone or a tablet and they can be based on geo location or zip codes. There's a lot of permutations to these searches that people are doing all over the world and we've built a manager around all of that keyword tracking and scheduling and very advanced scheduling that you probably won't see in the SEO rank tracking community. We're kind of leading edge in that way. Tanner Linsley: And from there, there's the whole admin side that we have a whole backend team. We are all kubernetes go, very microservice driven, just constantly crawling and categorizing and we maintain so much data. I think we create a couple terabytes of data every week that we're throwing into technologies like BigQuery and Vitess, for my sequel. So there is definitely a big data problem that we have on the backend and our engineers are doing a great job solving that. And then on the front side, on the front end of it there's like, "How do we take all of this data and all of this complex keyword management and possible reporting scenarios and make them all accessible? And you know what, that kind of reminds me, I didn't even talk about React Charts. That's another one that I built because I needed it at Nozzle. Ben: Well, I'm happy to hear about it. Maybe you could tell us what React Charts does or how it improves upon some of the existing chart libraries. Tanner Linsley: Yeah, I'm trying to think how I can frame it. I guess I'll start by saying I stared with D3, and tools like D3 and C3, and I learned a lot of those. And I even contributed to tools like Crossfilter that were built to integrate with D3 visualizations. From there, this is probably about five or six years ago, I worked on Chart.js. I worked with Evert Timberg, actually the two of us we rewrote Chart.js to version two. So I'm not super affiliated with it publicly any more, but you can still go to the contributors there and see some awesome contributions from me to Chart.Js. I loved Chart.js for a long time and got very a little too familiar with the Canvas API. I don't really enjoy working with Canvas API anymore. Tanner Linsley: And when I got into React, I moved back to SVG because they're so, they work together so well. And I was like, "Oh, there's got to be some great tools out there. I looked into tools like Nivo and Visx and their React Data Vis, is another one. I can't remember what it's called. But I tried a lot of these tools and they're all great. They either tend to be more on the spectrum on one side of like, "Hey, we're going to give you a lot of low level tools and you still have to build your own data visualizations." Or they are very drop in kitchen sink, here's the charting library that you just say, "render this chart." And I liked both of those for different reasons. I'm definitely partial to libraries for charting that take care of everything for you, because I know I'm all about headless and the implementation details and making it so that you can control everything, but I don't think that that's the right approach for chart building. It is for data visualization that's custom. Tanner Linsley: If it's custom, go with Visx, do your D3 thing. But for 99% of us who we just have data and we need to get it to the user and show them, you don't want to have to think about data visualization. It is complex. It's not top down like you think it is. There's graph dependencies under the hood and there's so much that goes into building great charts that it's not something that I would even want to be headless and wire up on my own. So that's why I built React Charts, it's just a component chart and you say, "here's a chart." And I narrowed in the scope really small to make sure that it was doing the best that it could at one thing, so it only does XY charts. There're no pies, no radial charts or anything like that. And I have my opinions about pie charts, but I don't think they're that useful or great. So don't use them. Tanner Linsley: But it only does XY charts. But by locking into say, "Okay, this is the way that we're going to do it and we only do XY charts, and we're very friendly with React." Now you can just dump a chart in there with some data and you get all these great features out of the box. You get automatic access generation. And tool tip generation. There're cursors that show up on the axis. And there's ... what else is there? It's totally responsive, so it's hyper-responsive, if that's even a term anymore. But locally responsive to the component. So you just dorp it in and it will fill the space that you give it by default. I get so angry with charting libraries that are so like, "Oh here's a way to make it responsive." No, it should just be responsive out of the box. Tanner Linsley: And things like automatic margin calculation for your axis labels and automatic tick rotation. This is little niceties that take so much work and effort even if you're doing your own D3 visualization. They're so hard to do and I've been working on them for probably three years, and I finally feel like it's in a place where I can let people use it. So that's why I built React Charts and now it powers all of the charts on Nozzle's dashboard. In fact if you go to the examples on React Charts, you'll find one that's a stress test. It's at the very bottom. That stress test example is there to essentially prove a concept if it will work in Nozzle. Tanner Linsley: We have so many charts on the page at any given moment, and they're not just static. They're moving around, it's resizing and they have linked cursors, so that you can keep your place across charts. Some of them are tiny little spark charts and some of them are huge. So it's definitely built for a specific use case, but it's really good at what it does. It's currently in beta right now, simply because I haven't written the full documentation for it. But I'm using it in production. Lock it into the specific beta version and you'll be okay. But seriously, it's a fun tool. Ben: So tell me, what are you most excited about in the future in terms of improvement to the TanStack tools that are on your roadmap? Tanner Linsley: React Query is pretty stable and we're getting a few contributions here and there, which reminds me, I should give a shout out to my other maintainer TkDodo, Dominik Dorfmeister. He's a great maintainer. Definitely in it for the long haul and he's a great teammate. If anybody appreciates his work, they need to go sponsor him on GitHub. I do. And what a fantastic developer. He has a great blog too, that we recently just integrated into the docs talking all about best practices for React Query. So go check that out. TkDodo.eu, I think is his blog. Tanner Linsley: As far as improvements to other tools, I don't have any big major features planned for any of the other tools that are currently out. But I do have a new tool that I'm working on that it's not a secret, but I'm definitely not marketing it a lot. But it is in the routing space for React. I know that is a crazy weird space to get into, but there're tools like React Router, that just, they just own everything. And React Router's wonderful I use React Router in a lot of places. But I'm working with some new concepts around enterprise routing, mainly around building these real, like Nozzle, a very complex application that has a lot of states and a lot of schema rules and types that are built into the routing of your application. Tanner Linsley: React Router does a lot for you that is just wonderful if you're just looking for a client side router. And I know they're working on Remix and that's the back bone of Remix, which is really cool. But going into the purely client side realm where there's just a lot of state encoded into the URL, there's definitely some areas that are left to be desired. And I have some proofs of concept out. I have a React location library that I'm working on right now. It's definitely not something I would suggest you use, unless you just want to try it out for fun. But that's going to be a new home for some of these new concepts that I believe maybe are not as prevalent or widespread as the necessity of React Router. Tanner Linsley: I will keep using React Router for specific projects that need it. But for the very, very small amount of big applications out there that are doing a lot of enterprise level routing, I would like to build a tool that's going to make some of those things easier. So that's on the horizon. I'm currently using a very, very internal alpha build of that React location library at Nozzle and it's turning out really well. So stay tuned for that one. Ben: Great. Well, Tanner, thanks so much for joining us today. It's been awesome to learn about Nozzle and of course all the open-source tools you're building. We will put some links in the episode description to your different tools, to Nozzle. But otherwise, yeah, thanks so much for joining us. Tanner Linsley: Yeah, you bet. Brian: Thanks for listening to PodRocket. Find us at PodRocketPod on Twitter or you could always email me, although that's not a popular option, it's Brian@logrocket.