00:00 Hey, everybody, this is Kent C. Dodds, and I'm so excited to be joined by my friend Dominic. How are you doing, Dominic? Hi, I'm doing great. Thanks for having me. Yeah. Thank you so much for being here. So Dominic and I just established we have not actually met in person before, but I have

00:16 been following Dominic's work for the last, I don't know, maybe since 2020. That may be around the, well, that was certainly around the time that I started using React Query. That may be when React Query was released around that time, because I added it to Epic React V1 that year.

00:35 And then, yeah, it's just been a pleasure to see the hard work that you've put into that library that is one of the most popular libraries in the React ecosystem and has been enormously helpful to so many people. And you also have a really great blog and a bunch of stuff.

00:53 But I would love for folks to get to know you a little bit. And so if you could intro yourself, that'd be cool. And at the very start of your intro, if you could explain why your handle is tkdodo. Yeah, that's a question I do get asked sometimes, actually.

01:11 So yeah, my name is Dominic. I'm a software engineer from Austria. And I've been working as a software engineer for over 20 years now, but I've only got into open source during the pandemic around end of 2020.

01:29 And that's where I joined the 10Stack Discord and also started to be active on Twitter a bit. And yeah, that's when I started with my open source contributions, which led to me now being a maintainer of React Query for, I think, the last three years. And I've been writing a blog about it a lot.

01:46 And yeah, that's pretty much what I do. And yeah, tkdodo, this comes from the movie Ice Age, because there are the dodos and they kind of do taekwondo. And that's where kind of like this, they call themselves the taekwondo.

02:05 So tk is kind of like the abbreviation of that. And dodo used to be my nickname because my first name is Dominic and my last name is Dwarfmeister, which if you abbreviate that, it leads to dodo. So that's kind of like where it comes from. Okay, I got it. I got it. That's awesome.

02:22 And yeah, I'll have to tell my kids that I met somebody who referenced the dodo birds in Ice Age. They like that. It's cool that kids these days still watch it because I think it's a bit of an older movie. I watched it when I was younger. So that's where it comes from. For sure. Cool.

02:42 I think the thing that you're most known for is your contribution, or at least the thing I know you most for is your contributions to React Query. And I'm curious where your entrance into the React Query scene came from. Why did you start contributing to that project?

03:00 What were you working on that made that project impactful for you? Yeah, so at Verity, where I'm working as a tech lead, we are building a platform that has lots of interactive parts, dashboards and stuff like that.

03:17 And we were building a lot of things with the 10 stack already. So we were using React Table and React Virtual, and we kind of like, I don't know who said we should try out React Query, but I think we did it for the optimistic updates approach that they had, which we were struggling with.

03:34 So we kind of started with React Query and got it into one of our products, and it worked out very well for us. And then during the pandemic, I kind of had some time, nowhere to go, there wasn't much to do. We had lockdowns in Austria a lot.

03:49 So I was thinking, okay, I want to do something that has maybe a bit of an impact on the projects that I'm using anyways. So I wanted to, I've screenshotted actually the Discord welcome message that I posted,

04:06 and I shared it on Twitter recently, where I said, yeah, I'm Dominik, I'm using the 10 stack a lot, and I want to give back a little by helping people and maybe answering questions and helping out with triaging issues and stuff like that. And that's how I actually started with it, because for the first, I think, four months,

04:23 I did nothing but read every question on GitHub and on Discord and tried to find out, okay, do I know how to address this? Like, what's the issue there? Kind of look into the source code and help people getting rid of their problems or making their code a bit better. And that's how I got to know the library really well.

04:41 So I didn't really do any meaningful code contributions for the first six months. And I just tried to help the community understand the library better. And by that, I learned a lot myself. And it was really a very positive experience as well, because people are very grateful

04:57 when they have a problem with their code, and somebody answers in like an hour or two and says, oh, you know, this is maybe a way how to fix this. So that's kind of like, gave me like all this adrenaline shots. Like every time when I could help somebody, I was really, really excited about it. And then at some time, I wrote my first blog post about it.

05:16 And then I really got to know the ins and outs of the library, because there were always issues I didn't know how to address. So I had to look at the source code and kind of like step through the things. And then I was like, brave enough to do my first feature that I built into Rackquery. And from there on, it was like, yeah, Tanner reached out and said, you're doing a great job.

05:35 Help me maintain it. And that's it. Wow. And we can talk a little bit more about the impact on your career and your life as being a maintainer of the project. But there are a couple of really cool things that I want to call out about your story.

05:53 When I was in university going through a programming class, I was not doing great in the class. I was doing fine, but I wasn't confident. And so I signed up to be a TA, because I knew that if I was a TA, now I have to finish the homework early, and then I have to understand it really well to be able to help explain

06:12 it to people. And I guess not a TA, no, I was a tutor. So you could ask people who signed up to be tutors questions and stuff. And it was from that moment that I realized how valuable helping other people can be in your own learning and experience.

06:31 And so from what I hear from your story is that you just decided, hey, I'm going to start answering people's questions about React Query. And it turns out that that gets you into the code base better than anything else that I can think of. I know of a lot of people that are like, I really want to get into open source, I just

06:52 don't know how to get started. Because the projects are really big, and there's a lot to it. But I think use case-driven learning is a really great way to really understand things. And when you open yourself up to the use cases of other people, that's where use case-driven

07:11 learning really expands your experience beyond what your own personal experience is. So I really want to just call out that as a great way to contribute to open source. Were there other benefits as you were helping other people?

07:27 Aside from just being a helpful human, were there other benefits to yourself in being helpful and answering questions for other people? So yes, I absolutely agree, first of all, I think this is a very good way to get into open source.

07:42 And I think there are a lot of other contributions than just code contributions. And this is where it doesn't feel like it gets rewarded as much, but it actually does. Because even core maintainers are always really, really appreciative to people who just want

08:00 to help out with answering questions and triaging issues and helping with the documentation and stuff like that. All those things are really, really valuable for a community and are also really important for a successful open source library to have. And it's still something that I like to do a lot.

08:18 One of my most favorite things to work on is to go through the GitHub discussions and try to answer the questions there. Even though I have answered most of the questions, I think that coming up are now repeating itself. So I also wrote an FAQ page that I can just link to.

08:36 And most of my blog posts came from people having the same questions. I said, okay, instead of writing down the same answer for the 10th time, I just write a blog post and then I can link people to the blog post. And then I don't have to do that again. That's how my blog started.

08:49 And I think I have over 17 or even 20 blog posts about React Query right now. And that's how that started, just for me, making it easier for myself to answer questions for people. But every now and then, there comes a question where I'm really surprised. I'm like, yeah, that's a really, really good question.

09:08 And I don't know the answer. So it takes me back like three years and I'm like, okay, now I need to dig into and learn about how things work for some parts that I'm not that familiar with. So that's still a very humbling experience to see that even after three years of working

09:26 with this library and really having probably touched every file that exists, I still don't know everything about it. And career-wise, I think going into open source and picking this community has been one of the most impactful things that I could have done.

09:46 I also think that I was extremely lucky how my path has evolved. I think this is something that you can't influence. You can only influence by being open and choosing as many opportunities as you get and kind of like trying to make your own luck in that regard. But you still have to be at the right place in the right time.

10:03 And I think React Query, when I started with it, it wasn't that popular, but it has grown so much in the last couple of years when people really started to appreciate that service data and agent management that it brings to the table, that it has kind of like exploded in popularity.

10:22 And I think if I got the numbers right, it's now in every, like if you look at the download numbers, I think it's in kind of like every sixth React application that there is. And that's like, I think it's a really, really high number. And it shows that people actually like really like the library and want to use it as often as possible, probably.

10:42 And it has gotten me like a lot of opportunities for jobs. Obviously, I do consulting now next to my job for React Query, so people come to me and want to pay me to tell them how to write the code better with React Query, which is

10:55 something that I have never thought that's even possible that this will happen to me. And I can, with all the sponsoring that I'm getting, obviously from Tenor and from other people that want to sponsor my work, I can actually spend time on doing open source without

11:13 having to worry about still doing a full-time job and doing everything in the free time. So I have the liberty to reduce the time that I spend at work and do more open source. And this is something that I really enjoy doing because it has such a high impact that

11:30 I would love to do it full-time and maybe I'll get there once, I don't know. Yeah, wow. Yeah. So it's had a massive impact on your career.

11:41 It also made it really easy for you to develop a like following or like your blog post series as well. And so there's a very natural funnel for people trying to learn about React Query.

11:57 They end up on your blog because you're not going to answer the same question twice. That's exactly how my blog started as well. It's just like people keep asking these questions. I'm just going to answer it here and then link them. And actually, for a while, I felt like I was a search engine for my own blog.

12:15 People just ask a question and I'm just like, go grab that link to the blog. I haven't had to do that recently. I think search engines maybe have caught on or something. But yeah, there are so many awesome impacts.

12:29 And the true hack for really learning and understanding something very well is by putting yourself in a position to teach people that thing. And so for anything that has any sort of community around it, there are going to be questions.

12:48 And so for anybody who's interested in getting into open source or getting really good at a particular subject or establishing themselves in a particular field, go to where the community is gathering and start answering questions. I think that's just such a really great takeaway from your own experience.

13:07 Yeah. And I think it should be something that you're generally interested in, right? So I know I've heard a lot some people that want to get into open source because it opens up opportunities, but I don't really think that's the way it goes, right? It starts from an intrinsic motivation of wanting to help others and wanting to contribute to open source.

13:28 There's tons of open source contributors that don't get recognized as much as they should. And it takes a bit of luck to get kind of that breakthrough maybe. But it was never about that for me.

13:42 I never did this to be invited to conferences or be asked for advice on things or go on to a podcast with Kent, like here right now, and I never expected any of this to happen. So I think with that mindset, it was something that I wanted to do for fun and wanted to

14:00 do because I like the libraries and I like the community. And yeah, the rest just fell in place correctly for me. Yeah. Yeah. I think that's very, very wise. You'll have a really hard time becoming an expert in something that you have no interest in.

14:18 And when you get there, it doesn't seem like a very fun way to live, given that we can have alternative ways to live. So yeah, I think that that is really great advice.

14:31 And like you said, you were working at a company and you had some need for the optimistic UI features that React Query offers, which by the way, at the time that I discovered React Query, that was one of the things that just blew my mind was how easy it was to do optimistic

14:49 UI. But especially compared to other things, I did optimistic UI in Backbone. My goodness, that was hard. But yeah, having an actual use case and actually using library.

15:05 This is why sometimes people ask me, well, what library should I contribute to? And I always say, just look at your package JSON. What libraries are you using? And what about those libraries is not great. And often, what about the libraries is not great is going to be the documentation or

15:25 something that you're interfacing with a lot. A lot of libraries don't have good docs on their public methods, so you can go update the JS doc and stuff. Really small things that you can do that have huge impact. But again, it always just comes down to what are you actually using?

15:42 And you're going to be much better equipped at contributing to those libraries, at first at least. Yeah, fully agree on that. Super. So yeah, React Query, we've kind of talked a little bit around it. But let's talk about what it is.

15:59 And also, in the last couple of years, the TAN stack has taken the React out of lots of these things and made them more generic to support other frameworks. So I'd love to first hear about what React Query is.

16:14 And then also, let's talk about abstracting it further so that it supports other frameworks. Yeah, so React Query is not a data fetching library, right? This is kind of like the sentence I keep repeating myself.

16:30 But it goes very well with data fetching, because what React Query does is it takes the result of a promise, and it kind of like manages it alongside the React lifecycle. So it gives you the typical data loading and error handling that comes with it.

16:48 And it has a lot of built-in features that go very well with data fetching. So it has a caching layer. It deduplicates requests. It has garbage collection for when you don't need the cache data anymore. It can do things like state-of-the-art revalidate, refetching, where it updates data in the background

17:06 and still giving you instant data for your UI out of the cache and stuff like that. And all of this you basically get with just calling one useQuery hook. And from there, you can go into more complex use cases.

17:23 You can do infinite queries for those, what's it, kind of like missing the word here, for these, you know, Twitter feed-style UIs. Yeah, infinite scrolling and these Twitter feed-style UIs.

17:42 Or you can build, like we said, mutations with optimistic updates. You can sync with local stores and stuff like that. So you can kind of like build like quite complex features on top of it. But most of it comes from like, here's one hook that you can use, very simple to set up.

17:59 And it gives you a lot of features that traditionally took a lot of effort to build around. Yeah, so that's kind of like the value proposition that you can, with one hook, basically get like a very good user

18:12 experience and developer experience around fetching data, which is something that probably every React application does in some way. Yeah, you know, at the time that React Query came around, we didn't really have, I don't think that suspense was officially released yet. We did have error boundaries.

18:31 And so like the idea of starting to get some declarative management of some of this state with error boundaries and then the upcoming suspense features for declarative loading states, that was starting to become a thing in React.

18:49 But React Query was introduced with the like, is error or the error state and the pending state and you just render something based on that. I'm really curious what, I haven't used React Query in a while.

19:01 What is the current recommended approach now that suspense is solidified and error boundaries are clearly the declarative mechanism for handling errors?

19:12 Do you recommend using those or is it still better in some cases to just use the booleans and render things based off of that? So what I'm doing at the moment is we're starting to also use a 10-Stack router, which is kind of like the other project of the

19:31 10-Stack I'm a little bit involved in, because again, we started to use it at work. I saw some issues. I talked to the other maintainers. I tried to help out, fix a bunch of things that I was interested in myself. And now I'm kind of like one of the maintainers of that router as well, which is also like this is one of the projects that really,

19:51 really blew my mind lately in terms of what it brings to the table in terms of type-safe routing and using the URL as a state manager with search parameters. And also because it's a suspense-enabled router.

20:05 So every route that you're having is automatically wrapped in suspense and error boundaries for you. So it goes really well with React Query when you're using suspense in React Query, because you can really write your components in a

20:22 way that they only care about the case when they retrieve the data. And you basically offload the error display and the loading display to the error and suspense boundaries. But they come from like the nested routes that you already have.

20:38 And that kind of like gives you a really good developer experience. But it also gives you a really good user experience, because you can trigger fetches as early as possible from the route loaders. And they still all integrate with suspense until it's ready to display your UI. So it's kind of like gives you the best of both worlds.

20:57 Right now, that's what I'm doing. Of course, if you're using, so we're building a client-side application only. If you're using a server-side application with server-side rendering, you know, things are a little bit different. You can use suspense on the server with streaming. It is a bit difficult in Next.js.

21:15 There are some hurdles to go through. And we're still trying to figure out like a very good approach with streaming and suspense that, yeah, also works with how the React team thinks that, you know, these things should be used. It's not always that easy.

21:32 But yeah, I think we're on a good path. And of course, if you're using Remix, I think I haven't seen many use cases of React Query with Remix together.

21:41 But now with the new client loaders that are coming, I think if you have a use case where you want to have a refetching that happens more automatically, or that happens in an interval, or where you want to build an infinite query with React Query,

21:57 you can definitely use client loaders in Remix to just interface with React Query. And I think I've talked to Ryan a bit as well. And he also said, yeah, you know, probably not going to build anything into Remix itself. But if you want to integrate it with React Query, you know, the client loaders are a very good way to do that in that regard.

22:15 Yeah, yeah. You have a great blog post actually about using at least React Query with React Router. With React Router, yeah. Conceptually, it's like the same with TanStack Router, and it's probably conceptually the same with the Remix client loaders, yeah. Yeah, yeah. Makes tons of sense.

22:31 Yeah, I think that in the world of React Router slash Remix, TanStack Query makes a lot of sense for anybody who wants fine-grained control over the cache. Is that kind of the basic thought there? Yeah, that makes a lot of sense.

22:50 And that was honestly, that was the big revelation to me. In Epic React V1, I chat with Tanner because that featured React Query as part of that series of workshops.

23:04 And one of the things that I remember talking with him about is how React Query was the first time that I really started to grasp the value of separating my UI state that doesn't persist from my client-side cache that's just like a cache of the server state.

23:25 And a lot of the challenges that I've found with application state management in React applications is when we try to mix those things together, and you're just like, you're treating your cache like it's UI state, but it's not.

23:38 And the idea behind React Query just saying, no, we're going to treat this as a cache, and that's like, we're going to do all the things that you have to do because it's a cache, that just really frees up your mind. And then the rest of it can just be like a useStates and maybe a useContext here or there or whatever.

23:55 And it's actually not all that complicated once you've delineated the difference between what's the cache and what's coming from the server versus what's the UI state. Yeah, Tanner has a really good talk about that. I think it's called It's Time to Break Up with Your Global State. I think it's from 2020.

24:11 But it was kind of like the talk that also blew up my mind at the time was that, yeah, we have everything in the Redux store, and we have lots of complicated logic on top of that.

24:22 But if you take a good look, probably 80% or 85% of that is just things that we fetch from the server, and we just fetch it when the component first mounts, and then we never refetch it and things get stale.

24:36 And all those problems that come with it, that come from treating server state like your normal UI state where we have an all-purpose state manager or a state manager that's more geared towards managing client state.

24:48 And funnily enough, a couple of times right now, I got asked about, can we use React Query to manage UI state and synchronous state as well? I have a dark mode toggle button, and I click it, and I want to store the state in React Query.

25:05 And people try to post tons of snippets about how to make that work with React Query. And while it's probably possible, it's not what it's made for, and it's not a good idea. And it would kind of like swing the pendulum in the other direction, because it would kind of like we still want to have one tool for everything then, which is what we try to get away from with React Query.

25:25 We really wanted to have that split and have the server state on the one side, where we have a dedicated state manager that knows about the promises and knows how to treat those with all the things that you need to do around them and refetching and caching. And then you have client-side state that doesn't need any of that.

25:43 And once you mix those two together, you lose all the advantages on either of the sides. So if you take your server state and you put it in the client state manager, you kind of like lose all the knowledge of that it's a promise and that it has a time to live and that you need to refetch it at some point.

25:59 But on the other hand, if you take your client state and you put it in React Query, you kind of like make it a promise and you have unnecessary pending states, which doesn't make any sense to me. So it's kind of like I think that split is still very, very relevant and something to always think about when you try to write state management for your application.

26:18 Yeah, 100% makes sense. So the future of React is very interesting and I'm curious what the future of TanStack Query is going to be in that future.

26:30 So like you said, TanStack Query is not a data fetching library, but it's used to help manage those states and everything.

26:41 With React Server Components, where the server component can await stuff, typically that's going to be data, but any asynchronous thing, and even support streaming and everything.

26:52 Where does the integration between React Server Components and TanStack Query happen? And is there a scenario where somebody using TanStack Query now could uninstall it and just use React Server Components?

27:10 Like are we getting to a spot there or is there a really great use case where some people will want to use both together? So I know a lot of people that want to use both together right now.

27:22 I think Server Components is still in a very early stage where caching is really hard and we've seen with Next.js, with the latest release, how they kind of like went back on how the caching works because it was too aggressive. Now they're going back to like, we're not making it that aggressive, so customize it yourself if you want.

27:42 So there's kind of like a progression that we went through with React Query probably some time where we tried to figure out what the best way to default those things are.

27:53 But I still think that, I have a blog post that's called You Might Not Need React Query, and it kind of goes into that direction that if you're starting a new application right now with Next.js and Server Components,

28:05 and you're basically only fetching like some data that doesn't need to get revalidated as often, it's not very interactive, like an interactive dashboard, you probably don't need it, right? I wouldn't say that you need to use React Query just because I'm maintaining it and I want you to use it like every time. I think you should use the best tool for the job.

28:25 And if you're all in on Server Components and you want to use that latest technology, then there might not be a place for React Query. But there might also be when you want to use Server Components to render some static parts of your application, but then you still want to just use them to initialize the client cache when the page first loads,

28:45 and then basically hand off the data to the client cache to do some more automatic refetching or to integrate with WebSockets and pull in data from a stream of live information and things like that.

28:59 And this is kind of like the integration that we're trying to work towards, that we're going to make the streaming from the server on the first render as seamless as possible,

29:10 and then basically hydrate that data that comes from the server into the client cache, and then you can use it there for any further things that you've been doing. But it's a progress to get there. All those things are still, at this point, are still quite new for us as well.

29:29 Yeah, I think that's the general mood for React Server Components. You have people who are using Next.js and they feel like, well, we've been using it a while, but we're still not sure about what the future looks like.

29:44 And then, of course, folks like me, not very interested in using Next.js and just hopeful that things are going to look good. And in Epic React V2, we have a workshop where we build a React Server Component-based framework.

29:57 And so hopefully people listening to this who've been through that have a pretty good sense for how it all works together and an idea of what it's capable of. But yeah, there's still a lot of uncertainty on how that's going to impact things like React Query and the integration.

30:14 My intuition says that React Query in that future will be really useful for people who want very fine-grained control over that client-side cache, which makes a lot of sense.

30:28 So on the mutation side, though, React 19 is the first time React has had any sort of opinion about mutations as well.

30:40 And so that is really interesting to me. How is the mutation aspect of React Query going to be impacted by form actions? Yeah, it's a very good question.

30:54 I'll be honest that I have to take more look into React 19 and form actions and use Optimistic and what that brings to the table. The mutation story of React Query has always been like just a thin wrapper around the request that you fire off at nothing else.

31:14 So while queries manage the whole lifecycle and everything, mutations are really just, you know, we give you a function, you invoke the function, and then once you're done, you should probably invalidate the cache and then it goes back to the query cache. There's no correlation between mutations and queries.

31:33 So I think that there is some room for improvement that we could do on mutations.

31:39 Maybe we are going to, but I'm just, you know, brainstorming here out loud now, maybe we're going to create a new use action hook on our end that's going to integrate with what React has to offer on that side and then maybe fade out the mutations that we have.

31:56 But that really depends on, I think, how fast we can actually go and have React 19 as a required peer dependency. Because as long as we need to support people that use React 18, that don't have these options, then yeah, what we have right now is going to stick around, obviously. Yeah, yeah. That makes a lot of sense.

32:15 I think that that's the right attitude to have, too. Like, kind of a wait and see, and once it's officially released, it's not like everybody should just uninstall React Query.

32:26 Even when people upgrade to React 19, they probably have got a whole bunch of code that is still using use mutations and things, and even if you decide, oh, you know what, we don't need to have that anymore, React solved it or whatever. Remix is actually going through the same sort of thing right now, too.

32:45 Like, do we need to have something or can we just, say, use the React version? But even in that world, people will probably want to upgrade to React 19 without losing all of that stuff, and so it makes sense to keep around, even if it's just for a migration.

33:01 Or maybe we discover something that React Query can do on top of what React 19 enables. So, exciting things in the future.

33:10 It's amazing to me that React has been around so long, and it's dominated for so long, and there are still things to look forward to and kind of wait and see sort of stuff. Like, the team just continues to innovate in this way, which is just remarkable.

33:26 Yeah, I think what they're shipping with React 19 is like the first big release in quite a while, and it has so many good things in there. I'm a little bit sorry that I was somewhat responsible for delaying the release with the suspense situation. Yeah, thank you for that, though.

33:44 Well, on the one hand, yeah, thank me that it didn't go into production like that. But on the other hand, I'm really looking forward to all the other things that are in the React 19 release because the release is great, and I'm also really grateful to the React team that they kind of listened to the feedback and now put in this stop and reiterate on the API

34:04 to have something that's really valuable for everyone, even if that means we have to use forward ref a little bit longer, but hopefully just a little bit and not forever. Yeah, yeah, 100%. Well, thank you so much.

34:18 Was there anything that you wanted to talk about that we didn't get to in our conversation so far? No, I think this was a really interesting conversation to talk about React Query.

34:32 Sweet. Well, I really enjoyed it. Hopefully the folks watching really did also. What's the best way for people to get in touch with you or keep up with what you're up to? So my blog has an RSS feed. You can obviously subscribe to that one.

34:50 Best way to reach me is probably on the Tanslake Discord or on Discord in general. I don't really like Twitter DMs because they're a mess, but Discord is fine, so that's the best way, I guess.

35:02 Okay, cool. Sounds awesome. Thank you so much, Dominik. I appreciate your time and hope that everybody has learned some really good tips around contributing and getting into open source and the exciting things coming to React Query and React in the future.

35:18 Yeah, thanks again for having me. It was a pleasure to finally talk face-to-face with you, even if it's not in person, but I'm also looking forward to meeting you in person soon. We'll get there. Yeah, come to Utah for Epic Web Conf. That'll be fun. Oh, I've seen that. Yeah, it looks awesome. Yeah. All right. See you all later.

35:36 See ya.