RTK Query is a hot new data fetching & caching library that integrates with Redux Toolkit. The creator, Lenz Weber-Tronic (coolest name ever), came on the podcast to talk about what makes it special.
RTK Query is a hot new data fetching & caching library that integrates with Redux Toolkit. The creator, Lenz Weber-Tronic (coolest name ever), came on the podcast to talk about what makes it special.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast, brought to you by water to remind you if there was no water, you'd be dry, saggy skin draped over even drier bones. Episode 255, RTK Query with Lenz Weber-Tronic.
Jamon Holmgren:
How good are you at chess, Robin?
Robin Heinze:
Chess? Not good.
Jamon Holmgren:
Not good?
Robin Heinze:
Not good.
Jamon Holmgren:
You've played it though, right?
Robin Heinze:
Yes, I've played it. My husband tried to teach me a while back and then he stopped playing with me, not because I was bad, although I was bad, but because I wouldn't stop talking about how bad I was. So he's like, "I don't want to play with you anymore."
Jamon Holmgren:
I could see how that'd be annoying.
Robin Heinze:
So no, I don't play chess very often.
Jamon Holmgren:
I played a little bit in middle school and didn't have any clue what I was doing, but then I just stopped. But this year, for some reason I just started watching chess YouTubers and this was before the whole chess cheating scandal, which a lot of people have heard about. There's a big cheating scandal that happened.
Robin Heinze:
What's the tl;dr if people don't know what you're talking about?
Jamon Holmgren:
Arguably greatest chess player ever, Magnus Carlsen was playing against another guy who's 19. He is very young and he's rose very quickly to grandmaster. Super grandmaster very, very top level. And his name is Hans Nieman. Apparently, Magnus thought that potentially Hans was cheating somehow in this game.
Robin Heinze:
Which is a very serious accusation against a chess grandmaster.
Jamon Holmgren:
It is.
Robin Heinze:
You don't do that lightly.
Jamon Holmgren:
But Hans had actually admitted to cheating when he was younger, and then he had been kicked off of chess.com for cheating. Anyway, there's a big lawsuit now and it's a huge fight. That's the tl;dr. It's been interesting. Doesn't seem like Magnus Carlsen would be the type to make this sort of a accusation lightly. Anyway, I was following it before then and I started getting into it about the same time as my son, Cedric. Of course, now Cedric is in the rating system. 1,000 is supposed to be the average good, good-ish chess player. I'm 800, so I'm below average, and Cedric's a 1,550 or something. He's way above average. We started the same time, but he's just way better than me.
Robin Heinze:
He has more time than you maybe.
Jamon Holmgren:
I'll say that that's it, but I don't even think that's true.
Robin Heinze:
He's better.
Jamon Holmgren:
He's a teenager, he's got a job. I feel like I have more time than him. Anyway, chess is pretty fun and it's one of those things that I'm glad that I found it later in life because it hits the same dopamine receptors or whatever that coding did when I was young. I got really into coding. I loved coding. I loved the figuring all of the logic out and all those things.
Robin Heinze:
Coding doesn't do that for you anymore?
Jamon Holmgren:
It does to some extent. I'm a little bit sad that it doesn't do it as much as it used to. But yeah, I can definitely say that there's been a drop-off.
Robin Heinze:
You'll have to try and teach me chess, maybe you'll have more luck at it than Travis did.
Jamon Holmgren:
I can try. What really got me into it was that I learned an opening. And once you learned an opening-
Robin Heinze:
So you always use that opening?
Jamon Holmgren:
I only have one opening for white when I play in white, and then I actually have two different openings when I'm playing black because there's two different responses based on what they're opening.
Robin Heinze:
Maybe that's what I need. I'm just always so overwhelmed by-
Jamon Holmgren:
"What do I do next?"
Robin Heinze:
... I can move any of these pieces and it's too many. It's decision fatigue. It's like, "I can't choose between all these." So maybe if I learn a couple openings.
Jamon Holmgren:
Were you like me where I always thought that I had to think eight moves ahead?
Robin Heinze:
Yes.
Jamon Holmgren:
But it's not true.
Robin Heinze:
Which I'm not good at. My brain doesn't keep track of that kind of forward-thinking.
Jamon Holmgren:
You can get really far just thinking one or two moves ahead. You can get really far, but you have to know what you're trying to do.
Robin Heinze:
Oh, okay. I'm resolving. That's my New Year's resolution, is to have Jamon teach me how to play chess.
Jamon Holmgren:
I may have just destroyed your productivity. I shot myself in the foot.
Robin Heinze:
When you ask me later why I haven't billed any hours, "Because I've been playing chess like you told me to."
Jamon Holmgren:
"I'm learning the London like you asked me to." Anyway, I'm Jamon Holmgren, your host. Friendly CTO of Infinite Red, 800 chess player and I live in the beautiful Pacific Northwest with my wife and four kids. I also play hockey at the rec level, which is an 800 in hockey. That's what I do. I'm joined by my, and we haven't used this one, by my mighty co-host.
Robin Heinze:
I don't feel very mighty today, but we'll go with it. I'll manifest that I'm mighty today. Maybe that'll turn things around.
Jamon Holmgren:
And we do have a guest as well who I'm sure is mighty, I will introduce him in a bit. Robin Heinze is a Senior Software Engineer at Infinite Red, future chess player. She's located west of Portland, Oregon with her husband and two kids. How good is Travis, actually? Do you know? Does he have an Elo rating?
Robin Heinze:
I don't think he has an Elo rating. I'll ask him. How do you get one?
Jamon Holmgren:
Just on chess.com or Lichess or something like that.
Robin Heinze:
I'll ask him if he's ever gotten one.
Jamon Holmgren:
I mean, if he's around my rating then we should play. Anyway, has specialized in React Native for the past five years. Our guest today is Lenz, hold on... I need to actually ask you to say your name.
Lenz Weber-Tronic:
Lenz Weber-Tronic. So it's not Weber, but it's Veber.
Jamon Holmgren:
Les-
Robin Heinze:
Veber.
Jamon Holmgren:
... Veber?
Lenz Weber-Tronic:
Yeah.
Jamon Holmgren:
Lenz Weber-Tronic?
Lenz Weber-Tronic:
Yeah. That's fine.
Jamon Holmgren:
I don't like fine. Is it good?
Lenz Weber-Tronic:
Dude, I'm German.
Jamon Holmgren:
Yes.
Lenz Weber-Tronic:
You will never get a higher praise than "fine" from me. It's not possible.
Robin Heinze:
That's true.
Jamon Holmgren:
We're joined today by our guest, Lenz Weber-Tronic. First off, I want to say that that is the coolest name ever. I was thinking you could start an electronics company and just use your name.
Robin Heinze:
And just use your name and it's the coolest electronic company name.
Jamon Holmgren:
Yeah. Weber-Tronic, you're good to go.
Lenz Weber-Tronic:
I mean, I married for that.
Robin Heinze:
You're like, "I'm marrying you just so that we have the coolest names to put together."
Jamon Holmgren:
Exactly.
Lenz Weber-Tronic:
Well, let's say there was no question on who takes whose name in the end.
Jamon Holmgren:
Right. Exactly. You're like, "This is an obvious choice. I'm going that direction."
Robin Heinze:
The coolest hyphenated name I've ever seen.
Jamon Holmgren:
So Lenz lives in Germany, works as a Senior Full-stack Engineer for a company named Mayflower. He works with Mark Erikson on Redux Toolkit, a Co-Maintainer of Redux Toolkit. And also, Lenz is the creator of RTK Query, which is our topic today. Lenz, you mentioned that you have ADHD and you said that you probably had a three-week hyper fixation period on every possible topic on the planet, which I love. I love that characterization. As someone who has a little bit of ADHD myself, I know exactly what you're talking about.
Lenz Weber-Tronic:
I think I'm about an 800 in probably everything.
Robin Heinze:
There you go. So he'd be a good one to play chess with.
Jamon Holmgren:
I know, right? Have you played chess, actually?
Lenz Weber-Tronic:
Yeah, for a few years as a teenager.
Jamon Holmgren:
Okay. So you're probably better than me still.
Lenz Weber-Tronic:
I doubt it.
Jamon Holmgren:
So what are you hyper fixated on these days?
Lenz Weber-Tronic:
Right now, I'm actually playing around with React Native a lot.
Robin Heinze:
That's a good thing to be hyper fixated on.
Lenz Weber-Tronic:
That's a lot of fun.
Jamon Holmgren:
It is.
Lenz Weber-Tronic:
Coming from React, playing with the animation stuff and the Chester stuff is just so much more fun. So I'm really happy to do that.
Jamon Holmgren:
That's great. Well, our audience will be happy to hear that. Before we get into our topic, I want to mention this episode is sponsored by Chain React 2023. Chain React is back finally, starting May 17th through 19th in 2023. It's going to be held in Portland, Oregon as usual, at the beautiful Portland Center Stage at the Armory, which is in the Pearl District of Portland. If you're familiar with Portland.
Robin Heinze:
It's a really, really cool building. If you haven't come to Chain React and you haven't gotten to experience the Armory, definitely check it out this year.
Jamon Holmgren:
Yeah, I agree. Go to chainreactconf.com. All right, let's get into our topic for today, RTK Query. So we had Mark Erikson on to talk about Redux and he mentioned... now, we purposely excluded RTK Query because we felt like that deserved its own treatment and we purposely focused on Redux itself, which was a great episode. You should go listen to it if you haven't already. Mark did a great job, but let's talk more specifically about RTK Query. And he did say, "You got to go talk to Lenz. Lenz is the guy to talk to about RTK Query." So first off, give us a quick overview of what is RTK Query from a 10,000-foot view?
Lenz Weber-Tronic:
From far away, RTK Query looks like all of these caching clients. So you have stuff like React Query for Rest stuff, or you have Apollo or Oracle for GraphQL stuff. So it's that, but it's in Redux or in Redux Toolkit, which allows you to interact with it with your store.
Robin Heinze:
You're hearing more and more about these Query libraries everywhere. It seems like someone's using Apollo or React Query or something because it's such a common pattern. Every app that I've ever seen has some form of, "Get data, store it, cache it, figure out if we need to fetch it again."
Lenz Weber-Tronic:
Yeah. And people have been using Redux for that forever, but they always did it by hand. And it can be a good idea to do it by hand still, but oftentimes you just need this data from that endpoint. So you just need a document from the server essentially. And for this use case of a document cache, that's nothing you have to do by hand. And so we provide it. RTK Query is a tool for that.
Robin Heinze:
Before we go a whole lot further, I do want to pause and just ask you a little bit about what your background is and how you ended up in the React world, with just React world in general and then specifically RTK and RTK Query.
Lenz Weber-Tronic:
Yeah, of course. I've been doing software development for about 20 years now. I've started up with PHP. I have a book on PHP 4.3 somewhere.
Jamon Holmgren:
Nice.
Lenz Weber-Tronic:
They had classes but that weren't like the classes that you know nowadays in the camp. PHP 5 and everything was different. And I've been doing web dev there, I went a little bit over to C# with asp.net. And about 2013, I really got into Java Script and tried to do component like things, but very handwritten stuff. I guess it was like that promise that I had from ASP, you write your whole thing and you have a click handler on it and a little bit more declarative. And then React just came in and it fulfilled that promise for me.
Jamon Holmgren:
That's very cool.
Lenz Weber-Tronic:
That's how I came to React.
Jamon Holmgren:
That's awesome. And then how did you get involved with Redux specifically?
Lenz Weber-Tronic:
I've been starting to use Redux pretty fast, I think around 2017. So that was the time when I came into the React world. Too, I started abstracting my own stuff pretty fast and I also started using other abstractions. My favorite thing was TypeScript-FSA, which is a super small library but it does all the things that were necessary to get rid of most of the boilerplate, to get nice typescript and everything like that.
And during 2019, I got onto open source and open source maintainership of other stuff like Fork TS Checker WebPack Plugin and React Async, and I started contributing to Redux Starter Kit to the side. I heard the first time about that in 2018, at the end when it was the first alpha, the time it had read it, I just sent it to a colleague of mine and we were going on about it. The typescript support wasn't there at the time. And then someone did a typescript pool request and it was usable, but I wanted more. So I started contributing types and subsequently teaching Mark Erikson typescript because he was in that weird situation where he wanted this to have typescript support, but he didn't know typescript himself. So I had to teach him the knowledge he had to have to accept the pool requests, which was a super weird time for both, but really fun.
Jamon Holmgren:
I'll tell you what, there's no better way to make friends with a maintainer than to improve the types of the library.
Robin Heinze:
Yeah, because you have to get to know the whole thing so intimately in order to do that. And they'll love you forever.
Lenz Weber-Tronic:
Yeah, that's so true. But you can really take it too far.
Robin Heinze:
Right?
Jamon Holmgren:
Lenz, I need you to do it for MobX-State-Tree next. I mean our types are decent, but they were written four, four and a half years ago, so there've been a lot of advanced typescript features that have come out that would really help. I'm joking, but it is a great way to get into the good graces of an open source project, is to improve the types.
Lenz Weber-Tronic:
It can be a little bit of a problem. If you come in and say, "I've rewritten your whole library to TypeScript," not everybody might be happy about that.
Jamon Holmgren:
That's true.
Lenz Weber-Tronic:
But if you nicely ask before, people are generally pretty happy about stuff like that.
Robin Heinze:
I feel like there's less and less pushback about typescript all the time.
Jamon Holmgren:
It's true.
Lenz Weber-Tronic:
Yeah, definitely.
Jamon Holmgren:
Yeah, it's become the default now. And I've seen even a lot of people who are very typescript critical, typescript reluctant, I guess. And then one by one, they're being converted.
Robin Heinze:
We've converted a couple.
Jamon Holmgren:
And they'll be like, "Well, I still don't really typescript, but it is useful in some situations." And then the next Tweet is, "I mean, I'm starting a new project and I am going to go ahead and use TypeScript because I guess so." And then pretty soon they're berating other people for not using TypeScript.
Robin Heinze:
That is the path.
Jamon Holmgren:
It's a fun path.
Lenz Weber-Tronic:
I think the main thing about TypeScript people don't even realize is how much help you can get in the editorial for a library is good types. You just start typing and everything is there, everything is documented. Even the weirdest things.
Robin Heinze:
It's amazing. How many years later, and I still think about what my dev workflow used to be like and the amount of time I would have to run it and fix an error, and then run it and fix an error and run it. And now that never happens because TypeScript, anyway. This is not an episode about TypeScript. I know we could talk about TypeScript forever.
Jamon Holmgren:
It's true. I want to say one more thing though. I think I'm in those early days of TypeScript with GitHub Copilot, because I keep telling people how awesome it is-
Robin Heinze:
And they're like, "Oh my God."
Jamon Holmgren:
... and people are like, "Yeah, but you know. I don't know." X, Y, Z reasons why you shouldn't use it. But it's eventually going to be one of those things that, everybody's got an AI assistant. Maybe not GitHub Copilot, they've got an AI assistant of some sort.
Robin Heinze:
We still have to do an episode about GitHub Copilot.
Jamon Holmgren:
We haven't done one yet. That's right.
Robin Heinze:
We haven't done one yet. We still need to keep an eye out for that.
Jamon Holmgren:
Yeah, let's do that. So let's go back to RTK Query. It's all about fetching data, tracking loading state, caching. These are super important things. How did you design the API? Was this based on stuff you'd seen in the past? Were you using other libraries as inspiration? Did you just come up with it completely out of the blue? How'd you come up with this?
Lenz Weber-Tronic:
There were a lot of inspirations taken here. I already said I was part of React Async for a little while. And during that time, the creator of React Async, Gert Hengeveld, he started the organization, Async Library. And he just got a ton of amazing people in there and tried to force them to discuss and get one thing out that in the end would land and be the library. And that never happened, but there were lots of good ideas there. Then I have been using Apollo for a long time myself, and I think that was the first global cache with hooks. They were really fast. I think hooks came out somewhere around January, February in 2019, and two months later, Apollo was out there with the hooks. Then of course, React Query is a big inspiration. At some point, I just went through all the features they had and checked what I still needed to add.
Jamon Holmgren:
That's great.
Lenz Weber-Tronic:
And I think the most overlooked inspiration in there is actually Oracle because Oracle doesn't have a normalized cache by default, but it just stores responses from the server. And every time you fire off a mutation, it re-fetches our queries that could be modified by that one mutation, it just takes the type of the entity. And if you modify something with this type name and you have five cache entries that, somewhere, contained that type name, it says, "That could have been touched. We re-fetched that."
And that gave me the idea to do something a little bit different with a little more granular control there, but for rest. So in RTK Query, you can just slap text on things and say, "This contains that tech. This contains the tech. This contains the tech." And then you throw out a mutation and that invalidates the tech, and all the cache entries that are still in use get re-fetched and all the cache entries that are not rendered right now just get thrown away. And if they're ever needed again, they can be fetched again.
Robin Heinze:
Wow, that's really ingenious. And is that specific to RTK? Are there any other query languages that are doing that with that tagging system?
Lenz Weber-Tronic:
You can do something like that in React Query with their cache keys. But in React Query, every query has one cache key. And in RTK Query, you can have 20, 30, 40 different techs on a cache entry, so you can do it a lot more granularly than you could to it.
Jamon Holmgren:
That's really smart. Just so much more flexibility, so much more control over what gets cached and invalidated. I mean as we all know as software developers, cache invalidation is a tough thing to do. So having that one the level of control is super important.
Robin Heinze:
Isn't that one of the things that's really hard in programming? It's naming caches and off by what errors, or something?
Lenz Weber-Tronic:
Yeah, I haven't got the naming right. Every time I want to name an API, we go back to Twitter and ask people if they have better suggestions. And if you look at RTK Query, at some of the options, definitely nobody had any idea how to call us. So we have weird options there.
Jamon Holmgren:
Crowdsourcing those can be very, very fun. You'll get tons of opinions, of course. Meanwhile, if you ask about something really important but complex, you'll get nobody.
Robin Heinze:
You'll get no response.
Jamon Holmgren:
It's the whole bike shedding thing people.
Robin Heinze:
People love to bike shed.
Jamon Holmgren:
It's true. So you've been working a bit more with React Native lately, is there any difference using RTK Query in React Native versus ReactJS web?
Lenz Weber-Tronic:
It's the same difference if you just work with React Native versus React generally, navigation and routing. You have those stack navigators in React Navigation and that means that you have tons of pages mounted at the same time, and that also means that you subscribe to all those cache entries. The user might never go back to them but they are still to subscribed, so if you invalidate them, you will fetch the data new. And that's just something to keep in mind.
Jamon Holmgren:
How do you avoid that? Is that something where you can, in some way, say, "This is stale right now"-
Robin Heinze:
Only if the screen is watching it or something.
Jamon Holmgren:
... "just stop watching"?
Lenz Weber-Tronic:
You cannot really do that. You can say, "Skip this query." So you have this active page hook or something like that I think, so you can just put the value of that into skip and then all those other queries are unsubscribed. And they have a timer, you can configure that. Put it for the 60 seconds after or 60 seconds of non-use, every cache entry will be removed.
Jamon Holmgren:
That's really interesting.
Lenz Weber-Tronic:
So if the user goes forward and backward, data is still there. If they go forward, five minutes later they come back, data will be fetched again. But you probably want that because it's probably just out of screen for a long time, it's maybe outdated. You probably want to re-fetch that.
Jamon Holmgren:
You want to reload it anyway. That makes sense.
Robin Heinze:
I wonder if you could probably do something with a focus effect too, where you subscribe or unsubscribe. It totally depends on obviously, there's some data where you're literally using it everywhere. It's the core data for your app and that would make sense to not have to unsubscribe from. But if you're talking about a list that you may never look at again, you want to fetch it anyway.
Lenz Weber-Tronic:
Pool requests are totally welcome. Also I have to add, the whole thing is modular. RTK Query, it's completely framework independent so you can use it pretty much everywhere. And we have a React sub-package that adds hooks on top of that. We had someone create the package NgRx RTK Query, so you can just use it in Angular. We also had someone doing experiments both Vue and we have some were a Svelte example. So nothing will stop you from creating a React Native entry point and just adding those special effect things in there and improving it there.
Jamon Holmgren:
That's really interest. I'm curious actually, because MobX-State-Tree, there are some other things out there. There's MST Query that tries to go down this route, it's a solo developer though, so not as much effort behind it. Very cool package just doesn't have quite the community. I am curious if something like RTK Query, could you bolt it onto a different state management system rather than Redux or is it very integrated with Redux to the point where it would be difficult to do?
Lenz Weber-Tronic:
I mean you could take the API and re-implement it somewhere else. That's totally possible. But the point of RTK Query was to do something like all the other managers with Redux, because you get all those benefits from that. You can have normal slices that just add an extra reducer on a query you finished action or something, and react to that, or you can add a middleware that listens to stuff in there. So it's meant to be integrated with Redux. So of course you can-
Robin Heinze:
That makes sense.
Lenz Weber-Tronic:
... use just that. Not have a Redux store or anything, but it would be a waste.
Jamon Holmgren:
Yeah, that makes sense to me. And there are some benefits that you gain by having that close coupling with Redux because you can really fine-tune it for that use case.
Robin Heinze:
Right. I mean you can use React Query for a lot of the same things, but it doesn't get you that tight integration with your state management library, which is where you're going to be putting most of this stuff anyway. So it seems like it's really handy to have them really tightly coupled. So it wouldn't make a lot of sense to try attach it to something else.
Lenz Weber-Tronic:
I wouldn't overthink it there. Usually, you shouldn't fetch data from somewhere and then put it into your state. Usually, we wouldn't recommend even if you use React Query in Zustand, for example. If you fetch the data from React Query, I wouldn't recommend to put that data into Zustand. You already have it in a state, it's in your global state and everything that goes from there is essentially derived data. So as long as you can just derive that, don't store it somewhere else.
The only thing I could think of is if you want to take the data into a form and modify it or something, to take it as an initial state for something. But I would try not to duplicate data, and that goes for everything. If you have data and your URL, don't put it into Redux. If you have data in your navigation and anywhere, if there's a good source for it, don't duplicate it somewhere else. Rather try to combine those things in the end.
Jamon Holmgren:
I think I generally agree with the concept of don't duplicate the data, derive your state from the source wherever possible. I do agree with that. But at the same time, I feel like in real world projects we end up putting it in the state almost always.
Robin Heinze:
Well, because we're not using Query libraries.
Jamon Holmgren:
No. That's probably part of it.
Robin Heinze:
Maybe we wouldn't put it in state if we were using Query libraries.
Jamon Holmgren:
That's true. But having essentially, a central place to access all your data rather than pulling it from different places, just having a place that you just know all your data is living and you're refreshing it from time to time makes sense. I'm definitely open to it the idea of, "No. Just let that live in your Query library, derive it." If you need a common API, you can have a layer on top of your state management and the Query to some degree. I don't know. I'm just thinking out loud a little bit right now. It's interesting. I guess I see it even with Redux too.
Robin Heinze:
It's a different frame of thinking. We're so used to relying heavily on our Redux or our MST or whatever. And then so all these instances where we've been doing all this caching and loading and fetching and stuff by hand, of course you put your data in your state management library, that's where you put it. And now, so this is a different way of thinking and you let your Query library manage that. Do what it does best and manage that, the caching and the fetching and everything. And then you have to think about your state management library differently. What's its role now? Is to then point to that data and do things with it or view it or give it to your UI layer? And that kind of thing, but maybe not store the master list the way it does now.
Lenz Weber-Tronic:
That's one thing where we really notice where things are getting better reviews in the approach of having a cache that's a bit indexed and stuff like that. I imagine you have a page that displays a product and you of course have, because people have been doing that for forever, they have product slices and that's coupled to a product page and then they fetch data into that product slices, and then they leave the page and then they come back to the page and they want to have a different product there. And then we get questions on Stake Overflow like, "How do I prevent my old data from flashing up before the new data?" And stuff like that.
Robin Heinze:
Everyone's had that problem.
Lenz Weber-Tronic:
And if you go to React Native right now, it gets even worse because if you have a recursive navigation, you could have multiple product pages open at the same time. And if you have a global state for those, that's coupled to the page, then all of them have the same data at the same time and you have to mangle that and throw it away in the right moment and all kind of stuff there. And if you just have a, "Use my stuff," Query hook, or a, "Use my product," Query hook. And on one page you call, "Use my product five," and on the one other you call, "Use my product seven," then you have two separate cache entries. Those will never have any overlap. They have separate loading states and you can have all those pages and they will never have that flicker in between that throwing away of data. You never care about all of that.
Jamon Holmgren:
Because it's fetching from the cache for that key or for that product. And then so when you load up, even if it's the same component that's being loaded up, it has all of the proper information shown. There's no overlap there.
Robin Heinze:
It's like it's creating and managing temporary slices for you.
Lenz Weber-Tronic:
Yeah.
Jamon Holmgren:
Yeah, that's a good way to say it.
Lenz Weber-Tronic:
And the nicest thing is it's only one slice. It's absolutely chaotic. You never have to look into that.
Robin Heinze:
Right. It's managing the chaos, you don't need to look behind the curtain. Just ask for what you want, it'll give it to you.
Lenz Weber-Tronic:
So if you start using RTK Query, you create one API and that's where some people go wrong because we are used to creating many slices and they create multiple APIs. But essentially, you create one API and you just add more endpoints onto that API and you describe how those endpoints are queried. And that means in the end, you have one slice, you have one middleware that you have to add and then you never touch your Redux store again. If you want to add a completely new API endpoint, you just really do that in your create API call. It's three more lines and that's all you have to do, and you get a free hook out of it.
Robin Heinze:
It really changes the way you use Redux. It's not just adding on top of what you're already doing with Redux, it's changing the way you use Redux and it's honestly sounds like it's making it simpler.
Lenz Weber-Tronic:
I mean, you have to learn a little bit. That's, I think one of the bigger differences. RTK Query looks a little bit intimidating at first look because you have to do this declarative thing where you declare your endpoint and stuff like that. Where, if you start with something like a Requery, you just write your hook and you call it and you can do that in line of your component. You never have to go to another place. And I was pretty strict. I was like, "We come from the Redux side, we want an API that's a declarative here." So you have to set up all your endpoints in before.
Robin Heinze:
Which we do anyway. We almost always have an API service layer. So you've defined your API and you're keeping your views completely unaware of what your API looks like. You're not like calling things in the moment.
Lenz Weber-Tronic:
And the nice thing is you can auto-generate that. If you have an open API file, you just throw it into our code generator, you get all the endpoint definitions you need, and we also have that for GraphQL. You might be arguing if you use GraphQL really deeply, you're better off with a real GraphQL client because RTK Query, all those libraries are completely independent. They just take promise that's resolved at some point, and they don't know about GraphQL, they don't know about the specifics of GraphQL. So you can take benefits from what GraphQL actually does for you. You cannot combine different endpoints where you see this data should be that data.
In those document caches, every request, every cache entry is completely separate. And if there's duplicated, there is duplicate data. We just try to keep it synchronous by doing stuff like invalidating the re-fetching. You can do optimistic updates, although I'm not a really big fan of that. And with a GraphQL client, you fetch data. And if it changed, then it will update in 10, 20 different places. So if you have a super small API, of course you can go for something like a RTK Query. But if you really use all the features of GraphQL, you should use something made for GraphQL.
Jamon Holmgren:
I have so many more questions for you Lenz, but we're running out of time. I guess one of the questions we like to ask people is, what sucks about RTK Query? Where would you not use it? Now you've already articulated some of those places, but what in your opinion right now sucks about RTK Query and what would you like to improve about it?
Lenz Weber-Tronic:
Well there's no suspense story, and this is deliberate from our side because we have three pool requests at this point that all implement suspense with one month in between, and then everything was scrapped because we heard that it should be done differently. So we never merged any one of those and we will not until everything is clear from the React side. So if you want to use suspense, you have to use one of our experimental booths or something, or you go with another library that might already be deeper into that.
And then there might also just be the thing you don't use Redux and you don't want to use Redux and there are good alternatives, so you're not forced to. If you look at RTK Query against React Query or SWR, then I think it's mostly preference. They pretty much do the same chop. They might do a little bit better here or a little bit worse here, but it's mostly about the style you write code and you want to write code. So with RTK Query, you write very declarative code, and with the other two, you're much more imperative in what you're writing that you're calling hooks and all that.
Robin Heinze:
That'll be interesting to see how suspense evolves and how libraries evolve to use it and what the adoption process looks like. But it's still so new that you don't see it very many places yet because-
Lenz Weber-Tronic:
I mean, it's not ready yet.
Robin Heinze:
Yeah, exactly.
Lenz Weber-Tronic:
It says so on the release, "Please don't use it for data fetching on the client yet. The story has not been written." And we are just adhering to that because with a package of this size, you release an API out in the wild, we can't really go back on that. And if it feels clunky, then it will feel clunky for the next few years. So we are holding back.
Jamon Holmgren:
That's a pretty big responsibility, the position you're in, you and Mark and the rest of the core team there because Redux is just such a huge widely used package. And then RTK Query, I'm sure is gaining popularity as well due to its prominence. So I think that's an interesting one. This is not a little package that you're doing in your side project, that maybe two or three people are using. This affects multinational corporations when you release something new, so you have to think about that.
Lenz Weber-Tronic:
Yeah, it's really creepy.
Robin Heinze:
I'm sure that's a very strange feeling.
Jamon Holmgren:
Well, we're out of time. This has been fantastic. I want to learn more, Lenz. Where is the best place to go learn more about RTK Query?
Lenz Weber-Tronic:
Well, the official docs and I'd say go to the Redux Toolkit docs. There's a whole section on RTK Query with 20 subsections on there, there is also a quick start. If you went through the quick start, go back to the Redux homepage, go to the tutorial section and go through the Redux Essentials tutorial because that's where we want everyone to start learning Redux. And chapters, I think seven and eight are on RTK Query. So you learn everything it builds on, you will know how it works internally, you will know how to combine it with other tools. That's the big tutorial. But take an afternoon of time because that's a really big tutorial. If you prefer video content, I just finished the first part of an Egghead course. So that should be out sometime soon.
Jamon Holmgren:
Oh, that's cool.
Lenz Weber-Tronic:
And I've got to do more after that. And we'll also put it on the Redux homepage.
Robin Heinze:
Well if that's out by the time we release, we'll make sure to put that in the show notes.
Jamon Holmgren:
Yeah, it'd be great. Where can people find you online to follow along and see announcements?
Lenz Weber-Tronic:
Generally, on Twitter. It's Phry there, P-H-R-Y. And apart from that, if you go into Reactive Looks and into the Redux channel and ask a question, there's a good chance that I might answer. If you go on Stack Overflow and you ask a question and you tag it with Redux or Redux Toolkit or RTK Query, also good chance.
Jamon Holmgren:
That's one of the strengths of Redux in the Redux core teams, it's just how incredibly involved in the community that you are.
Robin Heinze:
Yeah, there's no shortage of places to find help with Redux and RTK and all related things. For sure.
Jamon Holmgren:
If you'd like to nerd-out more about React Native, check out my Twitch stream at rn.live. You can also find me on YouTube, youtube.infinite.red. Maybe I'll have Lenz on at some point that I'm doing this publicly so that he feels pressured to join me.
Lenz Weber-Tronic:
I'm happy to.
Jamon Holmgren:
Awesome. And maybe we can do some Redux Toolkit stuff and it'd be a lot of fun to work with RTK Query. You can also join our Slack community at community.infinite.red. We have over 2,000 React Native developers in there. I actually recently asked that community, "Hey, do you think we should move to Discord?" And it overwhelmingly, the people in there said no. I was really surprised. I thought they were going to all say yes. It was 85% said, "No, stay with Slack." So if you prefer Slack to Discord, that's one place to go and it's also only React Native. Not React, nothing else, just React Native. You can find Robin online at robin_heinze. You are still on Twitter right, Robin?
Robin Heinze:
I am still on Twitter. I wouldn't say that I'm tweeting, but I haven't-
Jamon Holmgren:
Is Twitter still-
Robin Heinze:
... deactivated my account. It's not on fire.
Jamon Holmgren:
So you're still active? It's not dead yet? Okay.
Robin Heinze:
It's an experience for sure, but I'm still on Twitter.
Jamon Holmgren:
You can find me at Jamon Holmgren on there, probably arguing with Lenz. No, just joking. We're good friends on there. And you can find React Native Radio at React Native RDIO. Thanks so much for Lenz for coming on, it was awesome to have you on. I know there's so much more that we could have gone over. RTK Query, there's a lot to it and I think we could probably do 10 episodes on it. But we'll go into it probably in more detail if we get you onto a live stream at some point. And certainly, people can find you and ask questions anywhere. Really appreciate you coming on.
Lenz Weber-Tronic:
Thanks for having me.
Jamon Holmgren:
As always, thanks to our Producer and Editor, Todd Werth, our Assistant Editor and Episode Release Coordinator, Jed Bartowski, our Designer, Justin Husky, and our Guest Coordinator, Derek Greenberg. Thanks to our sponsor, Chain React. Go check it out, chainreactconf.com. Make sure to subscribe. Robin, do you have a mom joke to send us off in style?
Robin Heinze:
I think I do. What's black-
Jamon Holmgren:
I was really hoping you wouldn't.
Robin Heinze:
They're not that bad. What's black and red and black and red and black and red?
Jamon Holmgren:
I don't know.
Robin Heinze:
A zero with a sunburn.
Jamon Holmgren:
I feel like that joke had more potential than the payoff. It could have been really funny and it wasn't.
Robin Heinze:
I thought it was funny.
Lenz Weber-Tronic:
I'm chuckling.
Jamon Holmgren:
At least someone is. All right, we'll see y'all next time.
Robin Heinze:
Bye.
Lenz Weber-Tronic:
See y'all.