React Query + More React with Tanner Linsley

You're listening to Syntax, the podcast with the tastiest web development treats out there. Strap yourself in and get ready. Here is Scott Talinski and Wes Bos. Welcome to Syntax. This is the podcast with the tastiest web development treats. Today, we've got rid. An awesome guest on for you. We got Tanner Lindsley.

He's here to talk about React Query, fetching data, rest APIs, GraphQL, all kinds of interesting rid stuff in. I just got a list of questions to pick his brain on react wise here, and we're gonna get on into it. We are sponsored by 3 awesome companies today. Rid. 1st one is DQ, which is a trusted leader in web accessibility.

Sentry doing all of your error exception and performance tracking and mux, which is your API for hosting videos and delivering great video experiences. Welcome to them partway through the episode. With me, as always, is mister Scott Talinski. And, Tanner, how are you guys doing? Re Doing great. Doing great.

Awesome. Thanks so much thanks so much for coming on. I had not checked out React Query ever. And Scott was talking about it a while ago and I was working with an API. I was building this like little app for my shipping, my t shirts, and I I just had a little REST API where I needed to fetch shipments and fetch orders and a couple other pieces of data. And I remember it's got I've been talking about RackWare. I was like, alright. I'll try it out. Rid. So I I hooked it up, and I have this little API, and I feed it into React Query. And I was like, woah, that was easy. Like, it's sort of like, for For those who are familiar, it has sort of an Apollo like API where you get your data and you can get your errors and you can send mutations, things like that. And then I rid. Toggled away and toggled back, and it just refreshed on me. And then then I got into it. I was like, what else does this thing do? And I was amazed that I had not tried rid Not tried this thing out ever before, so is that let's have them on. This is obviously a really, really slick API. So welcome. And wanna tell us a little bit about yourself?

Yeah. I am an open source developer and an entrepreneur. I have a business called Nozzle.

Started it with a couple friends 6 years ago.

We Basically, reverse engineer Google rankings into big data, so that's fun. Oh, really? Yeah.

At scale for, like, a lot of people. There's a lot of big companies that, like, are data hungry. They want to know where they rank, so that's what we do. So, like, getting into nozzle and building that from the ground up is, like, why I got into open source in the beginning. I was definitely like a leech In the beginning, like, just taking all the open source software. Like I think we're all leaches for a very long time. Yeah. Yeah. Yeah. Pretty soon, I started building my own open source libraries, and some of them stuck around and some of them did not. But, React Query is one that I only launched it a year ago, and it really took off on me. Kinda

I'm trying, like, not to let it run out of my Hands. You know what I mean? Yeah. Yeah. It it feels like it's been around for longer than a year at this point based on how many people are using it in the, just Overall level of usage and satisfaction with it. So congrats on, on hitting a home run here. Thanks.

Yeah. I think it was only, like, was, like, a month or 2 ago that we actually surpassed Relay and GitHub stars.

What? Why do you think that is? Like, has data and and, like, talking to an API is has it been that hard? I think I know the answer is yes. But, like, why do you think it it's taken off so much? I I mean, the the way I tell people is, like, useEffect

is just the most powerful foot gun on the planet.

You know?

It's a foot shotgun. Yeah. It'll blow your foot off. Yeah. And and the React

docs And the core team and every tutorial out there on React, like, does not have an answer that covers all of, like, the edge cases for it. I think that's one of the reasons why. And then, like, from that, it's like, well, I wanna use a tool. So that's where people are like, I want should I use Redux? Should I use Apollo? Should I use you know, there's all these, like, tools, but there there are ton of buy in. And they're really hefty, like, either in methodology or, like, actually, like, a lot of code to implement. And then there's, like, React Query, which is like, oh, I just Import this library. I call use query, and then I'm done. You know? Mhmm. You don't have to think about anything else. I I think that's why, like, it it almost feels Like, you're cheating, and it just should just be part of React. But I I think that's why because it just makes it so easy. Yeah. Yeah. You know? And it does feel like rid. Other frameworks

like maybe Angular or something like that would include, like, a React query as part of the framework. So it does I I get what you're saying. It it feels like it would be very natural of a fit for, like, something that everybody does. Right? Everybody needs to do at some point. So, rid Yeah. I think yeah. It's definitely the right approach, and we we have been missing this because what were the other options before? I always thought using just fetch re Straight up in a React component, which obviously isn't scalable because you you have no caching or any of that stuff going on. Wes, you use Axios, but before that,

And Axios, what, to, like, pull into, like, Redux or whatever, but either way, there hasn't been an all encompassing solution like this, so re Very much needed. And we should say, like, the thing I really like about React Query and and maybe we should actually get into, like, rid. What are the the core features of of React Query does? But somebody on Twitter says says you can use React Query with anything that returns a promise, meaning that, like, rid. You still do use Fetch or Axios or Request JS or so whatever you want. Rid. Yeah. But or a new XML HTTP require or no. That doesn't return a problem, so that that doesn't make sense. But you still use that. Right? But you just feed it something Like, how you fetch the the data, Require doesn't care about. Right? It just cares about the promise. Right? Return a promise, throw an error. So let let's go into it. Can you explain to us, like, what are the core features of React Query? Like, why might somebody need React Query in their application?

Yes. I mean, like, The very first feature is just, like, to not have to use useEffect. Right? Yeah. So all of that, like, side effect logic And all that state tracking, and if you wanna get really deep into it, like the state machine behind fetching data, like, that's all just built It's all just built in. Loading error Yeah. Has been called. Mhmm. How many times it's been fetched? Yeah. Yeah.

I'm summoning David right now. Yeah. Right. Yeah. Right. Don't say state machine too loud.

All of a sudden, we get a 4th member on the Zoom call. Ready. He just pops in like, hey. How did you get in here?

So for everyone listening, I I hate when podcasts have inside jokes. We're referring to, our podcast with David K Piano.

He's the state machines guy. And if you say state machines even quietly, he He pops into the room and has is there to talk about it.

And it's like a good pop in. You know what I mean? Yeah. Yeah. Kinda like, yes. David's here.

Rid So, like, that that's one of the the main features. It's just like you don't have to deal with useEffect. Right? And e even if that was the only feature, it'd be a pretty great library, I think. But, Usually, that's where everybody else kinda stops if they're building a utility.

But like like what you saw, Wes, was like, it does caching for you out of the box.

So anytime, like, if you were to just browse around your app, you know, and come back to that same asset or that same query, It would just be there. Like, it it would load instantly, but behind the scenes, it re fetches for you.

So It's honestly more like a synchronization kind of a tool Mhmm. If you think about it. Like, it's it's more about just keeping this cache for that query, for that data in sync

as best as possible. Right? Yeah. Getting data and keeping it and Yep. Holding on to it, making it available where it's needed. Because we have often in the past, like I I know I keep saying that we reach for things like Redux. Right? But Redux answers the question of, like, Getting and updating and whatever the data, but it doesn't it doesn't make it easy to say, alright. Get the data and just hold on to it and let me deal with it. I know what you're talking about. Like, with Redux,

a good way to understand it is, like, if I wanted to use Redux inside of React Query to store and manage the data, like, I could definitely do that. Mhmm. But nothing about Redux is prescriptive for solving, like, the when do I refetch, How long do I hold on to the data? When is it considered stale or outdated? And, like, when do I garbage collect? You know? Exactly. Rid Those are all, like, these weird ephemeral questions that don't get answered immediately by tools, and those are the things that are baked into React Query. Like, rid Out of the box, you probably noticed, Wes, that it's, like, really aggressive. It's like refreshing all the time, hitting your API. Right? Yeah. But there's so many knobs on React Query to, like, say, okay. I want to consider data fresh for, like, you know, 5 minutes. And After 5 minutes, if the user still wants it, I'm gonna refresh from the background. So, like, you can really fine tune how often you wanna keep that cache in sync.

It also does I'm just looking at the list of features here. One sort of pain point and something that, honestly, that I just sometimes forego is just request cancellation. So If you are searching for something and you search for cooler, and then you're like, oh, no. And you delete that and then type in something else really quickly, Sometimes you can get into a situation where you have 2 requests in flight, and then Mhmm. The one that you searched for second will come back first, and then the re The first one will come back after it for whatever reason, and then you have this weird thing where you are getting the wrong queries. And, re Ideally, you should cancel that, but the Fetch in general's cancellation

is not great, and it re came, like, much after the fact as well. So that's built into Require? Yeah. So there's actually a couple different levels of that if you think about it. Like, the different levels of that are re Fetch cancellation, even with Axios, is kind of a pain.

Even it's hard to do even if you're just, like, doing something on your own. But Like you said, you brought up race conditions. I think that's really the fetch cancellation that a lot of people are referring to when they talk about, like, canceling a request. Mhmm. Lot of times, you don't really care about canceling the actual network request.

You just wanna make sure that if that old network request comes back rid at a weird time that it's not gonna mess up your application. Right? You're just ignoring it. Yeah. And so that is built in to where, Like, it eliminates all those weird race conditions you would normally get. If you had a bunch of promises going out at the same time coming back, all that's eliminated.

And you don't have to do anything to get that. It just works. But the actual cancellation APIs, that is awesome.

The best way to explain how to do query cancellation is so like you said, if you just have to return a promise, right, re In React Query. Yeah. All you have to do is tack on a cancel method to that promise, and It's going to get called when it should cancel the query. So you you have to implement the actual cancellation, if that makes sense.

I think you rarely have to do this, to be honest. It's really just like if you're going and fetching, like, a massive file and you wanna actually bail out of that network request, You just put a cancel method on your promise, and then you can use that cancel function to, You know, call your token cancellation or whatever in in Fetch or Axios or whatever. Yeah. I never even thought about that rid As to, like, you can just put methods onto a baked in Promise, but I guess you can because it's just an object. Right? It gets dicey in TypeScript. You kinda have to extend promise a little bit. But other than that, it's actually a pretty intuitive API because Whenever you're doing cancellation for promises or cancellation for Axios or fetch, you have to be able to do it, like, within the context of where you're making that call. It can't just be, like, some generic function. Otherwise, you can't keep track of the promise instances very well. Yeah. So this way, You you get to implement it however you want. And the docs have examples for Axios and Fetch, and it's it's pretty great.

I've only really ever implemented, like, XHR cancellation on a few

calls in my apps just because they're, like, massive bandwidth. Rid. Oh, yeah. Yeah. I've certainly made those API calls, especially in, like, internal tooling where you don't necessarily care all that much about it. But if it's bringing back Huge amount. You'd oh, I do need to cancel this. Otherwise, it could slow down the application.

And, usually, that's paired with a good amount of debouncing

as well. Yes. Like, what whatever you're doing. Yeah. You you wanna be a little bit cognizant of that if you have a 1000, 1000000 people hitting a query or something like that too. Of me. For sure. Yeah. The the both size and scope, depending on either of those things. One thing that I do wanna to Jump in here really quick before we go any further. If you are having to cancel and work with network Grips any kind like this, you might wanna have some sort of good error tracking system for those Oh. Caught and uncaught exceptions. That's a good good transition, Scott. Well, it took me a little while to get going, but I'm talking about Sentry at Sentry dot I o. And, they're one of our sponsors today. Now Sentry is the perfect place to see all of your errors, track them, re Log them and make sure that you have them accounted for. You can even attach specific releases to them, and now you even get rid. Tracking in Century, something that I am very addicted to. So I am I'm constantly having my Century open. I'm constantly checking out that performance tab, and I'm tweaking. Just tweaking all the time. So check it out at century.io.

Use the coupon code tasty treat, all one word and all lowercase, and you will get re 2 months for free. So check it out at century.io.

Thank you so much for sponsoring.

One other kinda interesting thing I I like to talk about Or just, like, mention to the users who are listening. This is one of the features of React Query is the simply just refetch refetching of a query. So what do you call what re React Query returns from you. Just the query? Like and that has a loading state and all that? Yeah. I I call it a query. Like, it's a query result, rid I guess, technically.

Yeah. Yeah. And on that will be, a method to just rerun it. Right? Sometimes you just need to rid new data and hook it up to a button, and it just gives you a method. And you can hook that up to an on click. It's just so simple. Yeah. A good visual tie to that is like a pull to refresh.

You know? Oh, yeah. It's like like that's like a manual alright. Just do it again. You know? Yeah. Yeah. Because I don't wanna wait or whatever. I just need to to do it myself. And an honorable mention here too is, like, there is a higher level API for the query client that re You can basically do anything you could do with an individual query but using its key in the client. So you could be like query client dot re Refetch queries and then pass the key of the query that you wanna manually refetch. Oh, okay. Can you explain to the user or listeners what a a key is? Sure. So React Query, the reason that it works so well out of the box is because you have to give every query a unique key.

And that key is could be something as simple as, like, here's a to dos list. So you say to dos.

The key can have rid Multiple items in it. So you could say, like, to dos, and then you could pass the individual to do ID that you're requesting.

So It's just a unique way to identify a query within the system.

Oh, yeah. And you can pass it an array of multiple values, which I thought was really cool. So if you've got, like, like a product with an ID and then a variation, like a shirt with the ID of rid. Ten and then a variation of medium. You could pass it an array of 3 those 3 pieces of data, and that will make it unique for that rid One product, and I thought that was such a a neat way. Like, in React, you have to, like, manually

concatenate all that information together if you wanna create a Unique ID based on that. That brings up a good point about, like, how does a query know when to refetch? Because people are like, well, where are my effect dependencies? You know? Your query key is your effect dependency.

And I tell people it doesn't have to be a flat array either. Like, you could get to the very last item in your key, and it could just be like an object, like a deep, deep object.

It gets deterministically serialized and compared between renders.

And so anytime your key changes, it's going to recall your query, either make a new query and leave the old one behind. So That that's kinda how I wouldn't call it cheating, but you kinda like, oh, here's a query key. Well, actually, we're using it as a dependency array. But Yeah. Which rid is one of the most confusing aspects

of useEffect anyways for most users. To give a little bit of background for those of you who might not be, super up on useEffect, the, what we're referring to is the, oh, array that's the last property passed into, useEffect. It basically that's what tells useEffect when to re Rerun itself. So that's when we're saying the dependency array. That's what we're referring to. Yeah. If you're coming from, like, class based stuff, we had the, rid did mount. The useEffect initially runs,

and then we had did update, and that will run when some of your data updates.

Rid. And with useEffect, you can give it an array of pieces of data to sort of I like to think of it as, like, it's watching that data. And then whenever any item in that array Array of of dependencies changes, then it will rerun the function, that's in there. And and that's helpful to ready. To update the thing. One question. I don't even know if you've ever run into this or not, but it's something I ran into the other day is that because hooks and react cannot be conditional, rid. I had, like, my own hook that needed some initial data.

And when you're in a loading state of in my case, it was Apollo. When you're in a loading state of Apollo, it would give you your my data would be undefined or an empty object. And then when the loading state re is done because the data came back.

Then I had my data, and that data needed to be put into my initial state of my use state hook. And I ran into this weird thing where, like, you cannot say, if it's loading, return. Otherwise, if it's not loading, then use a use state hook. And I had to write all this logic around, like, The initial state can be updated to a newer initial state once the loading is set to false. Have you ever run into anything like that?

Not not really. I think part of what you're describing almost sounds like this was a form. Yes. That's what it was.

Yes. Like like you're like you're querying something, you know, and then you you get the data in, and you stick it into some initial form state. Exactly. That's what it was.

And then that brings up the questions like, okay. Well, what if the query brings back new data? Yeah. Right? What do I do? Re Syncing form state. Syncing. And then do do you clobber your form state? Right? Yes. Oh god. I think most of that has been solved rid Because there's a few things that help that. K? The first one is that with React Query, you can just define rid your own initial state inside of a query. You can say, here here's my query. While it's loading or while it's disabled rid Even I want I just wanna use this state. And there's 2 types of initial state. There's initial state that actually gets put into the cache because It's real.

Mhmm. Or there's placeholder data that is more like a a default assignment when you're destructuring.

So you can just put in placeholder data.

Here's an empty array or something like that, and or, like, you know, this empty object with some placeholder stuff.

And you don't have to deal with, like, that initial state updating stuff.

Now when you get into a form, It's totally different because you wanna start out with that state and then be able to edit it and update it and kind of, like, Ignore what's going on with React Query. Right? Yeah. It was like a an update item form. Like, you you query the the item details from the back end. You put into the form and allow the user to type into it. Right. So there's 2 ways to handle that. The first way is I tell people to make a use state, Right.

And, just have it default to whatever initial state they want, and then just use an effect to synchronize those. Or you could even just use use memo, To be honest, you just say initial state, you know, equals use memo, and then you just memoize on the data coming back from the query.

And anytime that changes, you stick it into use state, and you're done.

You don't even have to subscribe to new updates coming in through React Query if you don't want to. It's just the very first time that that used memo gets triggered, you call it.

From there, bonus like, the bonus material would be If new data does come back in React Query, we do something called deep structural sharing.

Woah.

Woah.

Rid Good name. Smart. Yeah. Yeah. Which means that, if the JSON, the serialized JSON coming back from the server is the same, at any level of the JSON, it's going to share equality references between the old data and the new data.

So it's not gonna set off any weird use effects.

And the bonus material that you could do is say, okay. I've already started editing this form state.

If I detect new data coming in, Throw up an alert that says like, woah.

This item has changed on the server. Do you want to keep editing, or do you wanna update from the server? That is a weird like, that's a a missing piece of what almost all of us do every day in our applications.

So, Yeah. Maybe I need to write a blog post on that.

Please do. Because I was sitting there, and I didn't even know what to type in to Google rid To fix that and, the other issue I had is, like, I went the route, which just says use use sorry. Use a use effect, which means to watch this piece of state. And when it goes from undefined to an actual item, then the use effect will update. And then I ran into another issue, which is set state re We'll change a reference to the object.

So the useEffect was running every single set state call.

So the thing I ended up doing, and I don't even know if was a good idea, but I just I created sort of, like, a key based on the data, and I use, like, the name, the price, and the description as The useEffect Watcher.

And when the name, the price, and description went from anything to anything, in my case, It was from undefined to actual values, then, obviously, that key changed and Mhmm. It went ahead. I I I initially, I just started pass it object dot re Keys and object dot values, but you can't pass different amounts to useEffect. Like, you can't pass an array of 0 and then 5 things. It has to always be the same. So Cool. Yeah. Please do write that blog post.

I'm glad I could remember it because that was like Yeah. Yeah. That's that's good. Thank you for sharing that. I tell people normally with that is, for the most part, I think

the best user experience just to start is just to, like if somebody else edits rid That thing on the server and it comes back to you as, like, a new object, you probably want to just replace it unless you wanna start getting into, like, You know, conflict resolution stuff.

And if you're just following React Query, like, documentation by the book, then that's the experience you're gonna end up with. If you're just plugging that data right into your form state, that's what's gonna happen. Yeah. Maybe I should cowrite that with Jared Palmer.

Yes. Or Eric Rasmussen. Either one.

Yeah. Please do. That that's awesome. Alright. So let's get into

an an aspect that is rid Low key, very important thing in our world, and I'm this might sound like an ad transition. I'm not talking I'm not doing an ad transition.

Rid The the what I'm I'm referring to is, the dev tools. And one of the neat things about React Query is the usage of dev tools, because we often think about these individual tools that we're using, you know, just even React. Right? Can you imagine debugging React Without the React Dev Tools, me personally, it doesn't sound like a ton of fun trying to do that in the DOM. So the dedicated Dev Tools For React Query, can you talk a little bit about, not only the the idea behind them, the creation of behind them, and, like, What you're trying to do with them to make it easier for people to use? Because I I'm interested in the process of creating these types of dev tools and what went into consideration.

Yeah. I remember the moment that I kinda started thinking about them.

It all happened really quickly. One of the very first people I showed React Query to, I think it was Sean Wang, Swix.

Mhmm. And he was like, dude, this would be great with dev tools. I was like, yes. We need to make dev tools.

And then literally, like, an hour later, Kent, Kent c Dodds, of course, had some tweet or a blog post about like, hey. Read. Make your own dev tools for your own application. Right? And just make them inside of your app using React. Like, it doesn't have to be this browser dev tool thing. And I was like, yes. Because I had tried making a different dev tool in the past using, like, rid Chrome API.

Oh, man. It gets messy. And then you gotta worry about Firefox and Safari or Yeah. Yeah. Oof. Firefox

We'll run Chrome extension APIs. That's how almost everything gets into the Firefox. Apollo dev tools hasn't worked properly for almost a year on Firefox. And they've got version 3 coming out soon, but it's been a

huge pain in my butt. Yeah. Talk about, like you're basically building another app. Right? Yes. Yeah. And and it's complicated too because you have to There's a lot of security too. Yeah. And you're you're serializing events between, like, the main thread and then this, like, extension thread. You know? And I I hate that API.

Whatever it it is, whatever I ended up finding when I was going down this path, I hated it. I did not wanna do it. Like, I was like, I'd rather not build dev tools than work with this API.

And then Kent was like, just build them inside of your app. So I was like, well, what if I do what I do best and just build a React component called Yeah. Dev tools.

And all you gotta do is just render it really high in your application Mhmm. But inside of the re We're gonna pull in the like, it's just a component. There's really nothing special to it. I think it all lives in, like, 2 or 3 files. Nice.

And it subscribes to the the cache the same way that use query would or anything else with. So it's like it's using public API To show all of your queries, the state they're in, you can, like, focus on a query.

I I wish we could do visual because it it really is kinda cool. It's great, and it looks good. And one of the neat things is that it it does it works in code sandbox really nicely. It works pretty much anywhere you can run your app. It works really nicely. It reminded me instantly of this is something you neither of you have probably ever heard of or used, but Meteor, when it was, like, first launched, had this really neat Dev tool that was browser based. It wasn't in the actual dev tools tab. It would just kinda lived in the bottom right corner, and you'd click on it. And it would show you all of The current data that is currently both published because they did a whole PubSub thing. I remember that. Yeah. It was published to the front end, and you could change any value anywhere. You could re any user anywhere or it it just direct access to the cache that the site's using is is really super powerful.

Rid. Not only that, I think I mean, giving options to see, like, stale queries and things like that as well. Just giving you the the stuff that you need really easily is an underrated thing. We we like to build these kind of admin tools into our own site too. And and, like, when you talk about building dev tools in React, People don't often think about building their own tools in the browser, in the tools that they're comfortable with. Because we we did that For our site, even it's not, like, development tools, so to say, but it's tools to make our development process easier that is used by the development team. And I think you just did a great job illustrating exactly

the potential for things like that. Oh, absolutely. I I would do it again a 100 times over because I I don't feel like I'm getting anything by moving it into the browser dev tools other than some people are like, well, I wish it didn't hover over my content.

Alright. That's really small.

And another cool thing, I gotta give this one to Kent too, is Kent was like, hey. Re You should make a version of it that is just the component, not like the whole experience of hitting the button and opening it up and everything rid so that I can embed React Query dev tools into my own custom dev tools in the browser. I was like, done. Oh, yeah. So so you can import re React Query dev tools and put it at the top of your app. You don't have it just work. Or you can import the React Query dev tools panel Oh, no. And just put it anywhere, and it's just like a Static component.

Oh,

so the people that are complaining

about it hovering over top of their content, they could go to, like, their page wrapper component, like, their layout That gives you this visual that you I feel like once you see it, you miss it in other tools. Mhmm. You know, say you have, like, rid Five queries that are going out at the same time, you'll see 5 queries in that list with blue dots next to them, which means they're fetching. And then they come back, and they're yellow or or white or or green or whatever. It that visual aspect of it is it makes, like, that asynchronous

Way of thinking easier to Brock. Yeah. And it's it it brings to the forefront just the information that you you want to know offhand really easily. And like you mentioned, with the the The colors and the statuses, it is it makes it visually a little bit easier than popping open the dev tools, the watching your queries happen, having to filter them throughout. It just takes A little bit of the the ease and and brings it to the forefront, I think, which is really what the the library overall. Right? I mean, the the entirety of this is, like, let's take some things that everybody's doing, and let's make them really easy, but at the same time, really powerful.

And those are the most successful rid Libraries, in my opinion. Yeah. Let's reduce the cognitive load for everyone across the board.

Mhmm. And then if you wanna think really deeply about your stuff, you still can. You know? Yeah. Designing an API that gradually opens up to more complexity if you want it with great defaults is the key to success, honestly.

Totally.

So, next note we had in here was, what about React context? Do you have thoughts about context for state in React? Granted it's it's not cached. There's no normalized cache there. I haven't dug into the internals of React Query. Do you use contacts at all for anything in React Query, or do you have thoughts on using it for state management?

So interesting. The very first version of React Query didn't use context at all. It was just, like, used a singleton cache.

Mhmm. And when you used used query, it It just connected to that singleton and and did its own updates. Kinda like the way that Redux used to work or still works. I'm not sure. But it's, like, subscriber based. Right? We do use context now, but not for updates and not for memoization or or anything like that. Re We simply use context just to make the query client available to a specific React tree. Gotcha. And that's important for us too because you can have multiple query clients Mhmm. But 1 cache so that you can set different defaults for different re State trees in your app. So if, like, you wanted to use suspense for one part of your app, you can make a query client that has suspense enabled by default

on that, and then you can use a different query client for the rest of your app. And so context is just kind of like it's just a a really small mechanism to make that easier. There's such a surprising amount of complexities when you get into any of these problems. When you think, oh, you just load up some data. You have some mux or whatever. And then The the more you get into it, the more and more fascinating it is. And I suppose that's like with any project, but, man, this is really, some problems that I've never had to think about.

Talking more generally about context, like, people are like, well, state management context, it it's a huge topic. I think we kind of drown in it sometimes.

Rid. But from my perspective, it's the difference of, like, server state and client state. Right? And there's a lot of other different states too, like router state and local component state. But I feel like if people can just start thinking of, like, server state and client state being different, it's gonna make their lives a lot easier. And React Query is, like, rid Server state. It's a server state tool, and what I've told people from the beginning is that it doesn't replace rid Something like Redux or Zastan or Jotai or whatever you wanna use for global state.

But what it does do is it moves.

My guess is, in a majority of cases, it's like 95% of all of your global state. I'm putting quotes around global state. It moves that into React Query because it's just a cache. Right? Totally. Yeah. And and what you're left over with is usually very, like, trivial stuff. Rid It's like, oh, dark mode, maybe some authentication stuff, but, really, you should be using a tool for authentication too. But I'm really glad you pointed that out. Yeah. Because a lot of even like Apollo

was, like, trying to get too much into the local client state, which I Ended up implementing briefly and found it just the combining of the you refer to them server state and the client state into 1 client re Really made things a little bit confusing and difficult for us. We kept our server state in Apollo client, but our client state is known as Zoos stand in context pretty much. And Right. And moving those out was a a big, I think, a big pro, and many people Absolutely. They they get lost in that conversation, especially when they're taught Redux first. Alright. Now I got Redux to load my data, but Redux is also gonna store local stored their local state data for some reason. Like, I I never got too into that Myself, because it always seemed like overkill for local

component data. But Yeah. Luckily, Redux and and especially Mark Erickson, who We've been friends for a long time and and talk a lot.

Even Redux and their maintainers are noticed this trend, and they know that rid Server state is becoming more, like, of a pattern that we need to pay attention to. And you'll see, like, they have this thing called RTK Query that they're building that rid is kind of like React Query, but, you know, it's part of the Redux ecosystem. So it's definitely bigger than Just React Query. Like, all these tools, like Apollo was kinda one of the forerunners, and SWR is another great tool that literally came out, like, The same time that React Query did. Yeah. We even talked about it before we released. We're like, are we is this right? Are we doing the right thing here?

Let's talk about one of our sponsor, and that is Deque Systems.

That's d e q u e. They are the experts in web accessibility, and they have this tool called Axe, a x e, and that Axe will allow you to find out where there are inaccessible pieces of your website. So this is a really important tool. We ran on the syntax website ourselves, found out a couple little issues. We had some, contrast issues. We had a couple images that didn't have alt tags. Whole bunch of little stuff. I really like they gave us some copy here that we could read. It says, rid You probably didn't set out to build an app that was purposely inaccessible. So none of us are going out being like, I'm gonna make a website that's inaccessible.

But You may be unknowingly doing it if you're not actually actively testing your website for accessibility. So this is something that's really important for all web developers to do is Go and run your website through this tool, and it's gonna tell you what's going on. They've got tools for Chrome, Firefox, and Edge. It's just a browser extension you can run it on and see what the issues are so you can ship some fixes and make your sure your website is accessible.

So check it out at dq.comdequeforward/ax, a x e. Thanks so much to DQ for sponsoring.

Over the holidays, oh, in December, the React team announced this thing called React Server Components.

And around the same time, also, the folks from Basecamp re Release their what's it called, like, Hotwire or something like that? Livewire? Bombard.

Hot.

Something like that. I will do a whole show on them. But, basically, They announced this whole new API for, rendering components on the server and then just streaming them from the server to the client to render Out.

And, I haven't looked too too much into it. We're recording this in, January right now, but I will have a show on it soon. But I'm rid. Have you

dove into React server components at all? I've looked at them, played with the demo, probably what most people have done, nothing extensive.

Rid I did get to talk extensively about the subject, you know, with a a a couple of people after they came out, and, You know, I'm I'm excited about it. I think that it's a natural path. You know, if you're looking at React from the perspective of the Facebook team and and also rid The perspective of large frameworks like Next and Gatsby and stuff like that. I I think I think it's a natural path to to wanna go there, so I'm excited about it. It does have pretty big implications for the ecosystem and for everyone's apps if they decide to use it. Right? So rid. Those implications are the things that I think are interesting. Is the idea behind

React server components is that the data and fetching And, possibly, the management happens on the server.

And and how does React Query maybe play into this?

So Surfer components, it's it's almost like taking the concept of GraphQL and Relay and buying into it even more, where rid All of your asynchronous dependencies for an interaction on your page happen in one place As parallel as possible on the server, right, and then get interleaved with your client code re Well, they get streamed down to the browser, and then they get interleaved with client side components.

So It does have implications for data fetching. So, like, in this perfect world of server components, you wouldn't need to use rid Anything on the client to fetch data. It would just kind of be there because in your server components, you're you're not even, like, doing async await. Not using something like React Query.

You're on the server, and you're in a server context.

So you just say, re Go fetch this data, and it's probably going to use a mechanism similar to suspense. I think it does.

Mhmm. So it tells the server to suspend on that little server component, fetches the data.

And you're also in a server context, so you don't have to worry about, can go directly to the source. And then once you come back with that data, it just gets streamed down to the browser. So in this, like, perfect server components world, Yeah. React Query doesn't really have much of a use.

There might be room for tools that do, like, infinite lists And data fetching for that kind of stuff. And maybe maybe React Query has a has a home doing things in server components On the back end. I really haven't explored it that much. Yeah. It's early days for sure. And you're probably not surprised. I got that question, like, a 1000 times the day, yeah, server components came out. It's like, is React query dying? And I'm like, Yeah. You know, the the response that I gave everybody is that look at suspense and concurrent mode. Yeah. They they were announced so long ago, And they they shake things up. They shake up your code base. They shake up the the ecosystem.

Yeah. And when stuff like that happens, It's gonna take a long time for people to move into those new paradigms.

Totally. Even if a lot of people do, there's gonna be people that just, for whatever reason, They're gonna stick with client side applications.

So React Query is gonna be around. Oh, yeah. It's gonna be around for a long time.

You know?

Fetching that you're probably not gonna gain much by going with server components. Yeah. It will it will be fascinating to see how everything I mean, even because right now, it's, like, only, like, in a webpack kind of context and things like that. Like, obviously, I don't think they're gonna release a tool that only works with rid Some build systems in in some context. So Yeah. It will be very interesting to see how it evolves and develops and Oh, when we'll get to try it out. Did you by the way, this is actually somewhat related. Did you see there was on Twitter. I forget if it was Kent or somebody Who is oh, no. It's Tyler McGinnis had, like, tweeted out that he had had, like, a, like, a hate message come in basically already being like, this course doesn't teach server components, Tyler. Rid

Seriously? Oh, man.

Yep. Yep. That's funny. That's when, Rack Fiber came out. Everybody I got 1,000 of emails. Is your course rid Rack fiber compliant? And I had to, like, explain people, like, it literally nothing changed from the API standpoint.

It's all internal, and people didn't get it. So finally, I just said, it's updated for Rack Fiber. Here we go. You know, like, it uses the latest, But, like, there's literally nothing changed. Not a single line of code needed to change for React Fiber, in the stuff that we were using, which is funny.

It's very funny. Can we ask you questions about your thoughts on static sites? Yeah. You can ask me questions about anything. Alright. So you have Or had I I don't know if I'm sure if you're working on it anymore.

React Static. Right? It was a Stack site generator. You're no longer working on it. I saw you write a blog post about your Thoughts on it. What are your thoughts around static site generators right now? Well,

React static was fun, And I was trying to compete with Next and Gatsby.

And for being a 1 man show, I think I was doing a pretty dang good job.

But I remember the day. I was, like, next released, hybrid.

They released their hybrid, environment. You know? And, like, within the same week or something, maybe the same week. I'm not I can't remember.

Gatsby raised, like, another $40,000,000.

Right? And and I just looked at what I was doing, and I was like, this isn't gonna happen. Like, I'm sorry, but I can't compete with, you know Enterprise Jamstack.

Yeah. Enterprise open source, really. It's like, let's just take let's take VC money and just Dump it into open source. You know? Yeah. And and I I couldn't compete with that. And, honestly, it wasn't really doing much for me. React Static wasn't doing much for me at Nozzle At the time, my start up. So it was an easy way to just say, hey. I'm gonna take this, and I actually, like, sold the permissions to it rid to some company that wanted to manage it. I was like, sure. Give me a couple $100, and you can take it. Yeah. And so rid They took it, and they still maintain it. Some people still use it. I wrote a postmortem on it. And Yeah. In that postmortem, I basically told people that I'm using Next now because it gave me everything I wanted with React Static,

and it also gives me everything I want with dynamic sites too. So that's that's kind of the sweet spot. Do you think that Gatsby is gonna

have to go that route as well? Man, I think it would be smart for them, but they're probably not gonna do it.

Rid You don't think so? Interesting. No. I I had meetings with Kyle Matthews very early on, like, with React Static, talking about rid How we could potentially work together or or help, you know, react static influence to Gatsby API. And and he was very firm on of where they wanted to go, and they really wanted to stay static and embrace, like, the pure Jamstack mentality.

I don't know if they're still that way, But my guess is that Gatsby is probably gonna stick with static, and I think you can see that with where they're putting their investments and their time Building out cloud build centers and software services.

I don't know. I honestly think that next is so much better.

Oh, yeah. I have a issue with both of them that it persists, and I've talked about it numerous times on this. So I'm not gonna bring it up again, but I like them,

But I just wish the routing situation was a little bit better. Other than that You know what? I'm gonna segue into my own little ad here, but it's not even an ad for me rid Talking about routing, I haven't even tried it fully yet, but I I am excited for when I do get the time to try it. But Remix from Ryan and Michael deserves

a deserves a an honorable mention here because I think they're building something that could be potentially very exciting rid In that space. Different, which is much needed at this point. Yeah. Yeah. I, did confirm with Ryan that he will come on the rid. Once they launch it, and he said they should probably be launching it within a month or so. So I decided to to chat with him about that. Yeah. It's it's rid Kinda interesting. They've got a lot of people's ears up on what they're working on, which is really cool. They're really gonna

make something awesome. Rid It's gonna drive the ecosystem forward for sure. Yeah. I I I especially like the fact that they're questioning

how to do open source sustainably, and they're just charging for it, Which I I that's a whole another topic. I am 100%

on board with it. It's courageous, and it's courageous in the right way, I think.

Rid So Yeah. I think it's courageous, and I think it's right. I've been wanting to do it for a while, and I'm to the point where I don't care what people think. Like, My next few big open source projects are going to have some monetization strategy attached to them, it's not gonna be the typical one either.

I'm looking at doing some like, if you wanna access alpha and beta versions, then you gotta be a sponsor. It's like the Patreon model. Yeah. And I've I've even have ideas for, like, React Table Pro, which is Mhmm. This

rid a g grid competitor

that, you know, is gonna have a paid model. And and what I'm really excited about is for Michael And Ryan to be trailblazing that Yeah. Path so that I don't have to. You know what I mean? And when they figure it out, I'm just gonna hit them up and be like, alright.

How do I do, you know, subscriptions

and, you know, distribution and all that stuff? So So I don't know if you know too much about my background, but I I created, like, a re Thousand free like, a literal 1,000 free tutorials on YouTube in the hopes of, like, making it YouTube big. But, like, YouTube big doesn't get you anything anyway. So I started charging for content, it was, like, the 1st series that I charged for, and I charged very little for it. It was, like, $29. Here's a tutorial course, Something that you would normally pay for or normally get for free, you have to pay for. You would not believe the well, you probably would believe the amount of people just being Very upset with me on on YouTube. My my wife had to, like, hold back her her thumbs from from responding to some of these people that are like, rid. How dare you charge me for this thing that you've been you know, it's like, come on, man. I'm just trying to feed my family to do the work that I like to do. Like, you either Support me in the work I like to do or you like to to leech off of it. And and I, like many others, have had probably a little bit less time for The leaching and I'm I'm more than happy to produce a ton of free content and give out those free things as well. But in return

for my work, I would like for you to support me in my work. And I'm sure that's how many open source content feel creators feel. And that kinda draws a parallel, like, With what I tried in the beginning with React Query, I have a React Query essentials course Mhmm. Mhmm. That was kinda like, hey. I'm going to distill all of my, you know, creator knowledge of the library into this course and sell it.

And it did really well, and it's still doing really well. And I have to update it for v three because I promise people that it will. But if I'm being completely honest, I don't like doing online courses.

You know? I I don't wanna earn my keep by doing Yeah. Online education. I would rather have Kent teach about React Query Yeah. Than Yeah. You know, or or Wes or just somebody. You know? I don't want to do that. Rid I want to build libraries and software.

So I think that's been a difficult challenge for me. It's, like, finding Where do I fit in this monetization world of open source? Because as a content creator and an educator, man, you can really Just kinda be like, oh, what's the hot open source library? Boom. I'm gonna create a course on it, and and it it can be a really great project. But As the creator, if I wanna keep focusing on

building that software and making it better, it's not as clear of a path. You know what I mean? Yeah. Like, you shouldn't have to make a course in order to pay for your your open source work, or you should be able to, like you said, do what you want and focus on the rid Focus on actually building the thing and for that to be able to, you know, support yourself on it. I have a start up too that is doing that for me right now. Like,

Nozzle. I pour my heart and soul into Nozzle, you know, every day, and then I have a little bit of time left over for open source. And I'm lucky enough to where that's the case. Right? Not a lot of people have that that option.

Would you like to shout out Nozzle's URL?

Yeah. It's just nozzle dot I o. Lovely.

Marketing tool for SEO people.

Can I ask you what the the stack is, the back end stack Or also the front end stack of this? Yeah. I can tell you all the way from top to bottom. Please do. Yeah. So we keep all of our data in BigQuery,

And all of our big data data is in BigQuery and on Google, which is amazing.

Seriously,

life changing. Is it really? So that's like a database that Google provides. Right? It's not open source or anything. It's just a database. It's a distributed database

querying system. So, like, you can you can write queries that will go across, like, terabytes of data, and they happen in, like, 10 seconds. Really? Yeah. And it's because Google has you know, it's like their operating system as a service through their data centers. It's doing all that work for you. Mhmm. We keep all of our, like, rid Along with a couple of other great companies. But Vitess is awesome. It's like a horizontal scaling utility for MySQL. Super cool. Developed by YouTube initially.

And then from there down, it's all Golang.

We have microservices and task re queues and and Golang all the way down. Everything's, you know, running in Docker on Kubernetes.

And then when you hit the front end, Even our API is just all in going.

You hit the front end, and it's, Next JS.

But I'm not using Next as, Like a hybrid or static site. I'm really just using Next. Js as, like, a create React app replacement.

Yeah. Yes. Routing, linking.

Re I have a link to a gist that basically shows you how to do that. I'll I'll link to it at the end of this, but Okay. It's so much better. Like, Next. Js has a great CLI, and that's really why I like it. So from Next, I am actually using React Router v six. I know it's not out yet, but I'm using it. Oh, so you're not even using the router in Next. Js? Nope. Nope. Wow. I'm just using Next as, like, a build system and a configuration system.

Oh, interesting. Never heard of that. Yeah. That's how I was using Meteor was, like, I'm using it as a as a build system. Right? I wasn't using the data or anything like that, just as a create React app type of the thing. I'm gonna link to that right now. You guys can check it out here if if you want. But, yeah, it's from there down, it's just React router

React Query.

And for the very tiny bit of state that I have that's actually global, I'm using Zestan rid Or zoos stand out. I don't really know how to say it. I say zoos stand, and I have no idea how to pronounce it, though. I'm gonna keep saying zestan because it's already locked in. So I think that's I think that's fair. That way, we have it covered between the 2 of us. Exactly. Something Wes and I like to do. And, you know, a hand a handful of other libraries in there too. I got React rid in there because we're doing a lot of data, you know, dashboarding.

I have React charts, which is my own library, and I'm also using Vizzix from Airbnb now to do some more of the some more of the, like, more complicated data visualization stuff. So Cool. Oh, and then I got a this, you know, this is one of my picks. I'm gonna say it now. Alright. Tailwind is great.

You can't say that on this show because everyone gets real mad when Wes and I talk about Tailwind. You're not allowed to say the word Tailwind on the show because they they come after us. Aw. It's a joke. You know what's even better, though, is a tool called twin macro.

Twin macro? Twin dot macro.

Or or there's another one that's similar, but I haven't I'm not fully bought in yet called Twind, just Twind.

Rid But these are tools that basically give you the benefits of CSS and JS

with, like, Oh, cool. And

Whatever. And but you get the you get the syntax of tailwind.

And, seriously, I I've been doing CSS for a long time, and this is the most excited I've ever been about a tool.

So I'm just looking at the API here, and you can make Easily reusable components similar to style components where you just, like, make a component, and then you can go ahead and and use it. Rid. Yeah. You can extend it, override it. That's one of people's complaint sometimes is they like, I don't feel like making another component, but I also don't want all these classes in in here. So this looks like a easy way to do that. That's cool. Here's the other great thing is

it doesn't use tailwind classes.

When you call a Tailwind utility, it generates the CSS on the spot, like as an object. And that gets put into styled components is the thing that's doing the class hashing and sharing. Oh. So you don't have to worry about purging. Re There's no purging involved.

You know, it's not guesswork for purging. It's just like you only are generating the styles from Tailwind

that you're actually using. Oh, so it just imports them as you need it. Oh, that's cool. Let's dive into one of our sponsors really quick, and that's a video host. Rid And not only a video host, but it's the video host that I use and prefer. I'm talking about Mux.

Now Mux is a really interesting service. That's m u x rid. .Com.

It's basically branded as how developers build online video.

And I think one of the coolest things about this platform is it is it's very developer 1st. They even wrote their own little neat little tool for uploading video to the web. Something I've considered doing a tutorial on, by the way. But what's cool about the service is, basically, it's an API first video host that takes away all of the difficult things. I used to sign up for a bunch of different video hosts. We we did, like, a whole tour of different video hosts when we were looking to move over level up tutorials from building our own Video on demand platform with AWS to all sorts of things. And let me tell you, there is just so many little complexities involved in transcoding, Creating all of the different versions, storing the versions, creating those permissions, and everything like that. You don't have to worry about any of that with Mux because What it does is it transcodes your video on demand. Whenever somebody requests a specific video at a specific size, it creates it, then there on the spot Insanely fast, and then it's insanely fast for the next person because that video is already created. So you have the added benefit of not paying for Storage that you're not using. Right? Because you're not creating all of those things on ingest, which is what they say typically.

So your costs go down. There's a really nice data platform called Mux rid Data. And not only that, but there's a lot of really great companies using Bucks right now from, Vercel to Robinhood to Equinox To, oh, man, SoulCycle, Hopin, PBS, level up tutorials. We'll throw our level up rid. On that list with all those other companies because we're as as big as big as them. But either way, head on over to, muxedot come. Check it out. If you need video, this is really the way to do it in my mind. It is very, very good. So check it out. Mux.comforward/syntax,

and get started Hosting video today. Alright. Is there anything else you wanna talk about before we get into our sick picks? Anything that we missed?

I don't I don't know. A few notable like, there's a few notable things about React Query. I think it's good to, like, draw the sting. People think that it's only for REST. It's not. You can use it with GraphQL.

It's got TypeScript support.

There's a fantastic comparison page that I'll link That kinda shows how React Query stacks up against the competition Mhmm. Which is kind of a fun one. I don't think there's much else to talk about with React Query. I have a sick pick that's slightly related. Yeah. Let's hear it. Sick picks. Okay. Sick pick. One of my sick picks for React Query is my essentials course.

Right now, I'm updating it to v three. Really excited about it.

That's been the primary way that I've been able to, like, fund building React Query. So if anybody wants to give back a little bit, purchase the course. Yes. Where can they buy that? I'll link to it, but it's, learn.tanstack.com.

That's such a good domain name. Yeah. Tansack. And you know what? Let's sick pick tanstack.com.

I just barely launched the actual tanstack.com site probably just a few weeks ago.

It's really simple, but it's built using Next.

And I've got all my open source sponsors. They're, like, in this cool bubble format on that page you can go check out. Join the Discord.

It's it's been fun to do. So Oh, that's cool. What what did you use to build this bubble animation or UI? I used Vizzix. Re I used a bubble packing component.

But instead of using SVG, I just used DIVs because I'm lazy. Yeah. Yeah. And then I hooked that up to some serverless, endpoints on Vercel to, like, make sure that those GitHub Sponsors are always up to date. So as soon as you sponsor, your bubble shows up in that Oh, in that circle. It's pretty cool. That's yeah. That's really neat. Yeah. And just size of your bubble is relative to how much you contribute.

So it's, you you gotta get a bigger bubble. You gotta give them more money, and I I support that. Hey. If you're a big company like Retul or, like, this Neo four j, like, that's That's cool advertising for them. You know? Yeah. For sure. What's this Neo four j? I've I've seen them a couple times. Someone once asked us a question about Isn't it a graph database?

Yeah. It's like a GraphQL alternative?

Kinda.

I have a hard time understanding as well, but it's it definitely is like graph database related. It's It's like an entire platform, really. I haven't gotten into it much. I really should. Seeing how they sponsor, like, I should check it out. But Yeah. It looks pretty cool. It looks very enterprise y to me. Totally. Yeah. Yeah. Sick. Wes,

do you have any sick picks? I got a sick pick. It's what I've talked about before. One password. Re I've been on 1 password for probably a year and a half. I've been on a whole bunch of other password managers over the years, rid. And I just love 1 password.

I I just, like, went through the list of the watchtower that they have on it, and they will recommend Sites that can turn on 2 factor authentication.

I just went through the list and thought, like, oh, there's a couple, like, couple here that I should have turned on. I have 2 factor authentication turned on on, like, the re Super, super important ones. But I always went through it, and I found a few more. And I was like, what a helpful tool to suggest to me rid that you should have two factor auth turned on. So I was just, like, looking at it. I was like, man, this is good. They're they're also redoing their entire re web browser extensions so that instead of having the desktop app, it'll entirely be in the web browser.

Oh, cool. And it's it's working pretty well. They they took out the touch ID in Firefox for a couple of months just because they're they're redoing it. It'll be back eventually, but re It's, it's pretty sick, so check it out. The new browser extension called 1 Password x, you can still use the old 1 Password 7 Chrome and and Firefox extensions if you need touch ID to work in the browser.

Yeah. Man, I've never had it working very well on Brave, Either update when PasswordEdge, it doesn't turn the Chrome password thing off correctly in Brave. Only in Brave. It works rid finding Chrome. But let me tell you guys, I've been using Safari as my main driver for a little bit now, which like, the past 2 months to just try it.

And out of all of the things that Safari does worse than Chrome, it does one password so much better than Chrome. Rid It it it just works. It's tied in really well with the fingerprint.

Everything like, I've never had a situation where it's fighting, and it fills it in automatically. It's my favorite part about Safari if I had to pick a favorite part about it was that it works really well with 1 password.

My sick pick today is going to be a neat little, LED Strip. Now these little LED strips of, like, tape strip of LED lights, there's a 1,000 different ones of these. But, this is the same company that made the That little thermostat that I had sick picked before, Govee, they made that little thermostat that I use for my gym, and it's like a smart thermostat via Bluetooth. And this thing is $13 and is a strip for the back of TVs or whatever, but it's basically an LED strip. So it plugs in USB To get its power so you can plug it into the TV or something. That's how we're using it. But it also connects via an app, and you can set scenes. Like, I told it to the other night, do a rid like a candle. And I was just like, man, $13, I got the behind my TV flickering like a candle. It's pretty dope.

Yeah. It it was way easier and cheaper than I thought. It took maybe, rid like, 5 minutes to install. So give this thing a look if that sounds like something you're interested in. I I use Philips Hue for everything else, but the Philips Hue version of this is, like, $100. And it's like, well, I think I can save $100

by not going Phillips Hue on this. Shameless plugs. I'll shamelessly plug all my courses. Westboss.comforward/ rid Course, if you wanna learn a thing or two about JavaScript, Next. Js, Gatsby, vanilla JavaScript fundamentals, GraphQL, all that good stuff, you can check it out. Westboss. Com forward slash courses, coupon code syntax for $10 off. I'm going to shamelessly plug level up tutorials.com.

Our latest course is Testing with Cypress. We teach you all of the cool things about how to test with Cypress, why it's such a fantastic modern platform for testing, and how you can mock rid Your queries, you can intercept those queries before they even happen to return mock data from a fixture and all sorts of cool stuff that you didn't even know was possible in Cypress. Now there's even, like, a new Cypress utility called Cypress Studio where you can, like, click around and use your website, and it records and writes the code for you for your tests.

So you could use that as, like, a basis for writing any of your tests to actually manually clicking around your site. It's very cool.

So, check it out, level up tutorials .com.

I didn't realize that, the sick pics were not also shameless plugs. So I got more shameless plugs, though. Ready. Go on. Do it. Yeah. No. We accept any anything. Yeah. If you have anything to do with marketing, go sign up for a trial at nozzle.io. That would really be great. Also, this is more of like a teaser, but I'm working on something that's gonna, like, really Make React Query awesome, awesomer.

Right? So if you want to be a part of that or use it early on, like, before anybody else does, you can go Sponsor me on GitHub or just follow me on Twitter. That way, you'll know what's happening.

And, yeah, I think those are My shameless plugs. Go buy my course.

Yeah. Tasty teaser to end the episode. Yeah. Well, thanks so much for coming on, Tanner. Ready. Yeah. We we got a little sneak peek before the show. And let me tell you, it's gonna be exciting. It's I was pretty impressed. So, Yeah. Thank you so much for coming on. Really appreciate all of your time and letting us pick your brain on all this stuff. Sure everyone really enjoyed it. Thank you for having me. It's been awesome. Awesome. Alright. Peace. Peace.

Head on over to syntax.f rid for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.

Rid.