00:00 Hey, everyone. I'm Kent C. Dodds, and I'm joined by my friend, Sebastian. How are you, Sebastian? Doing good. How are you? I'm doing great. Yeah, very happy to be here. Super excited to chat with you. I always like to start these off introducing the guests and how we know each other.

00:18 So I met you, I don't know that I knew you before React Testing Library. I think that's where we first interacted. But I don't know, there may have been some interactions before then, but in any case, you kind of took over Testing Library for me once I kind of moved on

00:37 to my courses and things. And you've been taking awesome care of it. So thank you so much for that. It's been super awesome. And even actually, when I was still really involved, your input was super helpful, and your contributions since then have just been incredibly helpful.

00:57 People give me a lot of credit and appreciation for Testing Library, and I try to forward as much of that on to you as I can, and other contributors as well. So anyway, Sebastian, can you give us an intro to yourself, like where you come from and what you enjoy doing,

01:13 and so that people get to know you a little bit. Yeah, so currently I'm an engineer at Rocelle working on Next.js primarily. But I'm also part of the React team, and then maintaining React Testing Library, and maintaining the React types. Everywhere in the React system,

01:35 I'm probably involved there somewhere. And at Rocelle and Next.js, my main focus right now is the whole horizontal integration between React, Next.js, and then also making sure it works at Rocelle.com, which is where we do all our production testing

01:54 of the latest React features. And then the other big area that we're currently focusing on is improving the developer tooling around Next.js and how that feeds back into React, because these things are very tightly coupled nowadays, frameworks and React itself.

02:14 Yeah, and you also, before Rocelle, you were working on the Material UI team, right? Exactly, that's kind of like how I got started in the React ecosystem. So it started out when I was doing contract work for local companies,

02:32 and they were working on a scheduling application that was heavily, and they were using the Google products. So they were like, hey, we need a scheduling app. I've heard of Material UI before, and I was already working with React on-site projects. So I was like, yeah, let's just use Material UI

02:52 that's familiar to them. And then it's like the repeating story. I started using the products. There were some paper cuts. I was contributing to it. After like eight weeks or 12 weeks, they were like, hey, these contributions are nice. Do you want to contribute like 20 hours a week? And I was like, sure, let's do that.

03:14 And then 20 hours became 30 hours, and then I was basically doing it full-time. And then became, then came, was it like React 17 or 18 and like forward ref? And Material UI was like, we were migrating to forward ref.

03:33 And back then, everything was written with enzyme. So all these tests started failing. And then React testing library just became like popular a year or so ago. And then I was like, yeah, let's just do that instead, instead of having to rewrite all tests with enzyme and having to do it again.

03:54 If forward ref gets removed like it can do in React 19, let's just rewrite them with React testing library. I did that. Again, small little paper cuts started contributing to React testing library. Then we got to meet and then got invited there.

04:15 And the same story kind of like then happened with React. Like the more you're involved in a component library or on a testing library, and you do want to use like the latest React features, early adopters always get to see the not so polished side of React.

04:34 Then you file bug reports, you fix these bug reports. And yeah, then they were also like, hey, wanna join the React team and work closer with us? Yeah, and that's how it got started there. And then like two years later, Vercel was like, yeah, let's do the Next.js thing.

04:54 I was like, yeah, sure. You know that I like, I'm grateful that you shared that story. It seems like there was never a big leap in your experience. You just like small steps to everywhere that you're at. Now you're at Vercel working on the React team and on Next.js and everything like,

05:15 and you've just made such massive contributions and it all kind of came from just getting in the weeds with whatever it was that you were working with. And so like there's a good takeaway right there for anybody listening. Like just get involved and don't be satisfied with,

05:34 like I think a lot of people will hit a wall with an open source library. Like things aren't so great, they'll find a way to work around it and then they'll just move on. Whereas you were just like, no, I don't think it has to be this way. And you're not afraid of the node modules directory, being like, that's not just magic in there. There's just like regular code

05:54 that I can contribute to and make better. And we're all better for it. Yeah, exactly. And it gets also, it gets easier with time, right? Like the first time you're gonna dig into a library, that is like, that's like a cliff you have to overcome. But as you do that more often, it becomes like very comfortable and then you need to fix like a library

06:13 and it's like done in like 10 minutes. And then you feel like that's, yeah. I wouldn't have done this four years ago. It would have taken me two days. And that's usually when I understand, when I see people struggling with a bug and then they don't report it or then they don't fix it, I'm like, yeah, it was like that. It's like just a big time investment you have to make

06:33 with possibly like no payoff at the end. Like maybe you fix the bug and that's it. And then you never do anything else again. Or like maybe the maintainer is like, yeah, I already fixed it or I don't need the bug and that's it. So I think having a payoff, I'm like super lucky.

06:53 And especially with that streak of like four years. Yeah, yeah, that's a good point. Sometimes you put in the work and so like a lot of it comes down to the maintainers that you're working with as well and developing a relationship there. But I do think that if you are the type of person

07:12 that is active in the community and the maintainers recognize your avatar, then they're gonna take, even if it's not supposed to be this way, they are gonna take you more seriously, just naturally. Because it's like, oh yeah, it's this person. Like they know what they're talking about. I don't have to ramp up on who this person is

07:31 and do they have the skills and things. Because maintainers often will get ideas and pull requests from people who didn't bother to take time to understand the constraints and everything. And so whenever I, as a maintainer, receive a pull request from somebody I don't recognize,

07:49 I have to first like suss out, does this person really understand this project and what our goals are and everything. But if I recognize who it is and I know that they've been participating in the community on Discord or whatever, I know, oh, okay, yeah.

08:05 They know, like I said, maybe it shouldn't be this way, but I just naturally, lots of that, I guess like stuff that stands in the way just kind of goes away because I already know that you know what you're doing. Yeah, I mean, it's still a relationship, right?

08:26 And relationships need trust and you need to build this trust. When somebody comes around with a PR, do you trust them to be like, if they ship it or if you merge it and then it breaks, if there's a bug, do you trust them to be like, come back and say like, hey, this kind of like didn't work. Do you wanna fix it or not? And like, sometimes it's just like,

08:45 I need to revert this and then it stays reverted and you never hear back. And that's kind of like why it just takes so much time and effort from the other side, like from the contributor side to build up this trust. Yeah. It's just, yeah. Yeah, that was one thing that kind of surprised me a little bit when I first got into open sources,

09:04 how much open source is about the people and relationships. I think I've definitely written more characters on my keyboard in talking to people relating to open source projects than actually writing code. And I know that like, there's that famous saying from Linus, talk is cheap, show me the code thing,

09:24 but I can appreciate that. Like, I definitely will sometimes, somebody will say, hey, I need this change. And I say, I'm not sure I understand what you're talking about, but a pull request would help me understand a lot better. And like, so I do sometimes get that,

09:39 but even still, I find myself spending a lot of time working on those relationships and understanding when I'm working in open source. Yeah, I have like this, I'm like now very cognizant how I review PRs, like I noticed that like, depending on the person, I'm like, really, I start on the title

10:00 and then I go down PR descriptions, written tests, and then implementation. And depending on the person I'm facing, I might just stop at the test level and don't even look at the implementation because I know, okay, they know what they are doing. Description makes sense, the test makes sense, that's like good to go.

10:18 And if it breaks, I know they will fix it or something like that. And then some, but for some people I'm like, okay, I really need to double check what they've written here because I need to probably own this area of the code base now. Yeah, yeah, and like often I find myself needing

10:36 to pull it down to like run a couple of things through, especially with testing library, I found myself often pulling it down so I could run like Epic React repos through the changes that were made and things just to make sure that like, am I seeing everything that they're seeing

10:55 and does this break anything? Like I would definitely run it through the bookshelf app in Epic React V1, that was like a really good test for me. Like if it still passes all these tests, then it's not a breaking change, like it's still gonna be fine. And so, yeah, but if it was somebody I trusted,

11:14 then it's a lot easier to just let it go. Yeah, I've done so many like for testing library and for the React type specifically, like at the previous company where I was working, which was like this huge app where like 70 different teams were working on.

11:30 I often find myself like, okay, test looks good and like implementation also looks good, but I still don't trust it because it is like so, especially with TypeScript, it's like so brittle. And then I run like, okay, let's test it on a real repo so that I can have like full confidence that it works. And it's like good to hear that you do this with like testing library,

11:50 that you've found like a setup to do it. It's like not super complicated. Yeah, it's not the easiest thing to do, but luckily I don't have to do it very often. I might grease those wheels if I was doing that a little bit more. Yeah, exactly, yeah. We have like in React, we have like these canary releases

12:09 that are run like on every commit on like main and you even have those on like PR builds so that it becomes like pretty easy to do it. And like the lower the barrier that is, the easier you can do it because for some things it's like not trivial. And that's why I like still JavaScript, it's still king in that area. I just like easiest way,

12:29 I just copy and paste the code into Node modules and run it and that's it. Like I don't have to compile something and then think about different architectures and all that stuff. It's just like, yeah, copy and paste and go. Yeah, that's often what I end up doing as well. And it works out. At Remix, we set up nightly builds.

12:48 And so we just publish every night and that made it really nice for people. But of course like testing library is released when a PR is merged. And so like, which I think is honestly, keep main deployable is good for apps and libraries. And so I really like that a lot.

13:08 Remix is more thoughtful about releases. They don't want releases going out constantly all the time and like that's fine too. Yeah, you even have to be like careful because somebody told me that like, they are like actually like problems on NPM API usages. If you have like too many releases,

13:27 they can become like really slow. Like if you just do like an NPM install react at latest or something like that. And they are like very many releases, like what you would have if you would release on every commit, like this can become slow. Like somebody was showing it to me and I was like, that's concerning because you do want to release

13:45 as often as possible. And with React testing library, you can just do it because like nowadays we maybe merge like every two or three weeks, something. So it's like not that many, but like for React nowadays, like having a release on every commit, that would be considerably slow.

14:04 Yeah, that is wild. That seems like a problem for NPM though, that I mean. That was my first reaction to it. Like I couldn't believe it. Like I was like, okay, if this is really true, that is bad, like you do want people to release it. But I don't know if it's like, if it's like specifically, if you do it on like a tag, like if you do at latest or something,

14:25 or if it was even on like a normal version, but something in there was like really fetching all the releases that are out there. And I didn't need to. Yeah, yeah. Well, there's a contribution opportunity for somebody, go find that and fix it. It's probably on the API side. So I don't even, I think.

14:43 Oh yeah, yeah, that's true. Yeah, I saw like Lauren from the React team was having an issue with like, she wanted to delete something from NPM. And there is like a repo for NPM. But they closed it because yeah, it's on the API side. Please email support or something. And then it's like, okay. Yeah, found that. There you go.

15:02 It's not gonna happen. That's the wall right there. Well, so Sebastian, you're working on the React team. React 19 is coming very soon. That's one of the big parts of Epic React V2 is that this is all updated to React 19. And it's super exciting. What are some of the things

15:22 that you're most excited about with React 19? What am I most excited about React 19? I think as a stepping stone for everything that comes afterwards. Like I think with React 19, I think, because I wasn't so much involved in all of the feature work that was like Josh was doing all of the float stuff,

15:43 like the form, the new form APIs. I think these are like the most outstanding things there. And then like React server components technically becoming stable. That's like a nice thing for people to finally adopt.

15:58 But what people on the React team are currently cooking up with regards to all of the debugging stuff is just crazy to me. This is like magic that I didn't think it was like possible. Because like when we go back React like three,

16:19 four years ago, it was like mostly client side. And that's like nice, right? Like everything is in one place. You have your Chrome dev tools, which are insanely good debugging tools, but then you split it across like client and so on and you lose something there. And while you can attach Chrome dev tools

16:39 to like your server, it's still, okay, you need to go back and forth. What is like happening on the server? What is happening on the client? And that's kind of annoying, like even going back to your terminal. It's not a nice experience, right? But there's like the benefit of having the same,

17:00 not just the same language, but the same library that is both running from on the server and client, we can stitch it all back together. Like when you do log something on the server, we can actually replay it on the client and we can give you a component stack where that happened,

17:19 can give you like an owner stack, something through an arrow on the server, we can display that on the client and then you can click on the stack frame and you get like the server code in your Chrome dev tools on the client, which that's like wild to me.

17:37 Like I saw the implementation for that and I was like, okay, this is like some serious sorcery happening. Is that a React feature? That is a React feature. Like some of that will need help from frameworks, like especially when we talk about the server arrows

17:56 because source mapping is like a build time process. So React needs to ask the server, hey, where's the source map for this code? And that's where the framework needs to come in. And we're currently building this out in Next.js so that you can use it in Next.js,

18:16 but it's really just hooking up different React APIs. That's like always the thing we want to focus on React, that we build like the right building blocks and then you can compose it into something how you see fit.

18:33 Okay, and will these APIs receive documentation? Definitely. It's like always a trade off, right? Like when you document something too early, you need to update the documentation because you find out, oh, it kind of like sucks what we did. But it is, first of all, it's still all open source, right?

18:56 So you can follow along and especially like the top level APIs are like pretty good documented in the PRs, which we also have to be based on, right? Like I'm currently somebody on the Next.js team

19:12 is doing all the integration stuff that I'm like supporting, but they are not on the React team. So they only can go by PRs as well. And then obviously I can help them, but yeah, obviously it's going to have documentation. Yeah, anything when the Next.js integrator asks you a question,

19:32 you can assume that any other framework is going to have the same question. And instead of answering his or her question, you can throw that in to some gist or something or just somewhere that everybody else can see I know that integrating React server components is a real challenge for a lot of frameworks

19:53 because of the lack of documentation of some of the different APIs that are available. Yeah, it's a very, very hard topic to get right because we still think in React like experimentation is like really important for us.

20:14 It's not like there's a big planning committee and then we sit down and we discuss how the feature is going to look. Then we ship it front to back without rediscussing it. So it's like really figuring out as we go and then finding the right time to write documentation is like hard.

20:29 And I think the new docs are great. And then we can build on top and like start with like smaller documentation around these features. And some of them are like even, because now I was talking strictly about like what comes after React 19,

20:50 but some of the newer stuff, like for example, the new uncalled error handlers that you can attach to the root, like these are documented. And these, you can also use these. These are great, like not just for like a framework or like an error overlay,

21:09 but everybody who did like testing for errors is gonna love these. Like the old one was like, even if you have an error boundary, you have to mock out console error and then a sort of that, like all of that is going away. You just add like your uncalled error

21:26 and then it's gonna be like some jest spy in there and that's gonna be it. Yeah, that will be super duper nice. Speaking of the testing aspect, so what parts of React 19 does testing library need to be adapted to, to support React 19 testing?

21:46 And I guess, yeah, what features can we expect coming to testing library to support some of those things? So it already supports React 19 now because like the, everything on the testing aspect was like, there were like no breaking changes. All we did is like removed act

22:06 from like React on test utils, like that is gone and removed it to React. So all we need to do is fix like a deprecation warning. That's it. And then the new stuff, there's a PR open and I have it in my browser tab to go to, to like support these on uncalled error

22:25 and uncalled error things so that you can just pass it to testing library. And then we can like document like a really, a proper pattern for like, this is how you test errors because that's also like a feature request on the testing library repo. Like how do we test errors?

22:46 And I know this also like pretty big topic on the React repo because it is like, React is pretty opinionated about when you have a error boundary, like what is going to happen? Like even though an error is caught by the error boundary, we still gonna do a console error and then also do it like a window on error

23:07 and none of that is like really, like from a testing perspective, it's like super annoying. Yes. It's the right thing to do so that you don't swallow too many errors. But if you're like in a testing scenario, it's like, okay, this is like, I'm gonna, I just want to test like the single line, this throw error,

23:26 and then I have to write like 50 lines of code in a test to do it. Yeah. That's gonna become easier. It was my understanding too that React 19 was going to kind of force our hand in making a render async and even maybe act and things. Is that still the case? Is that coming? Yeah, that's a, there's no satisfying answer to that

23:49 because it kind of, right now it depends. Like you should probably start doing the await act and then the async callback just because like you don't need it to have to be async, but once you start using the use hook, then it becomes like a bit sketchy. And we should probably like,

24:12 it's like one of these things, like do we document the bad intermediate state that we have right now? Or do we just sit down and say like, hey, let's make act async by default and work on that instead? Which is like, that's a big breaking change. Like every time you go from something being synchronous

24:32 to asynchronous, you're in a world of pain because like even if you, like I already started writing a code mode like half a year ago for that, but then it becomes like, okay, I can't just add an await to the act. I also need to propagate it all the way up to where it's used.

24:52 Because like the function that is wrapping the act also needs to become async and then the function that is using that needs to become async. And once you cross like module boundaries, you're like, okay, what do I do now? Yeah. Yeah, and if people have utilities that they wrote themselves and those aren't written into the code mod either.

25:12 And yeah, that is complicated for sure. Yeah. I started doing it and then I was like, okay, this is like so much work. Can we maybe get away with not doing it? Yeah, yeah. But yeah. As time goes on, I suspect people will start noticing it more and then people will be like, okay, I didn't await my act,

25:33 why do I have this warning? Like I shouldn't have to and then we maybe just need to pull the trigger. Yeah, I think though, I mean, last year I launched Epic Web and I made a patch package thing

25:50 so that all of the types said those were asynchronous APIs so that all the exercises, it's async. And because I was assuming that this would be merged like very soon and so it's been like a year now. But that's fine because we know that this is the direction things are going anyway.

26:09 And so yeah, that will be a relatively significant change. And it's not just a matter of adding async await to stuff as well because there's also the reason that we didn't have it be async in the first place was one specific use case that I just couldn't get myself to feel good about.

26:28 And that was you render something and you wanna check the loading state and then you want to await for the loading state to go away. And once you add async await in there, doing that gets to be a fair bit more complicated. Yeah, there is and there are ongoing discussions about this on the React repo

26:48 because what's even worse is if you, because right now if you render something with act that suspends, like even if the promise is already resolved, you're gonna see the fallback. And then if you resolve the promise in your next act, it's gonna show the resolved state.

27:07 The problem is React has this built in heuristic to avoid like layout thrash where like when we just showed a fallback, we're gonna wait 300 milliseconds. And people started noticing this in tests. And this is kind of like annoying because now your test becomes from like,

27:25 okay, this ran in like five milliseconds and now it takes like 300. Yeah. And that's like not nice at all because one test is like fine. A thousand tests of those is like not fine. And so there is like a question,

27:41 okay, like how do we provide the right pattern if you really want to assert on these intermediate states without having it go out of, like it becomes like super complicated if you have to use fake timers and then you need to advance these and like what is gonna be,

28:00 do you need an await here or not? And it's like, every time somebody comes with a test where they're struggling with it, it takes me like half a day to debug. And then it becomes like, oh yeah, that's why, but this is like not scalable. Yeah, yeah. And I'm assuming that you all have discussed like a test mode or a test build of React

28:21 to disable that heuristic. We're generally not a fan of these, like disable this kind of thing for like this one time. It's really like, the problem is you can have, either you have, we don't show the fallback at all, like you wrap it in the start transition and then your test is going to be fast.

28:43 But then what do you really do if you want to, I want to see the loading state and then I want to see the fallback thing and I don't want to see the 300 milliseconds heuristic. And I also don't want to realize or learn that I need to wrap it in a start transition as well.

29:05 Or you could do that in the library, I suppose. Yeah, I mean like it really depends because there was also like, I see this a couple of times on the issues on React where people are like, I'm going to render my application and the promise is already resolved, like why do you show a fallback in the first place? And like on the initial render,

29:24 React will always flush the fallback because showing the fallback as fast as possible is like just better UX normally. But if you don't want to, then you go to the start transition and then you avoid all of that by like, React doesn't show the fallback immediately,

29:42 it's just going to wait before it commits and wait for the data to come in and then commit it. And if you want that, that's also an option. It's just hard to come up with a good default. But the whole testing build was like, I think it was like two or three years ago, there were like efforts to make,

30:02 to build like a lot of what React testing library has into React itself with like a selector API. And then there was like a testing build for React. But whether certain heuristics make sense there, it's like, I don't know if that's the right decision.

30:19 Because it's also hard sometimes to do because there's not like one place in the code base where it's like, if testing waits 300 milliseconds. Right, yeah, it's all over the place. Yeah, it's all over the place. And then when you disable it, like what else is going to break? Yeah, exactly. And now you're running your code against something

30:39 that's different from what your users are running. And so you're taking a step away from that confidence. Yeah, exactly. That's also the thing. But probably like most people, like in my tests, I don't care about the 300 milliseconds. It's like, at least like the normal case where like, I want to render this one single component. It's going to suspend.

30:58 I want to see the loading. Then I want to see the next thing. Then you probably don't want to. It gets more interesting, I think, once you have like nested suspense boundaries and fallbacks, because that's where the heuristic originally came from. That when we reveal some additional content, it's not going to like fall back really,

31:19 like waterfall really quickly. Yeah. Reveal, reveal, reveal. And it's like, it's going to wait a bit and then show more together. That's like where the original motivation came from. And that is probably more interesting to show in a test. If you do like, I'm going to actually measure my test. And then you're like, okay,

31:38 it's like some waterfall in here and that kind of like delays showing some content. Like can I maybe refactor it somehow that it's like, doesn't wait too long. So, yeah. Yeah, I think honestly, it seems to be that testing things

31:56 that deal with transitions is the final boss. Because everything else is pretty well. And even with the errors that you were talking about being a lot easier to test now with React 19, it seems like everything else is really buttoned up. And now it's just how do we test these suspense boundaries

32:15 in a reliable way that doesn't cause our test to add a bunch of time for that heuristic. And the real answer here is like, technically we wouldn't want you to test this at all. Yeah. It just works for you. Like you don't have to. But sometimes if there is something in there

32:34 where it's like there is like a product requirement there why it has to behave a certain way. And then it probably is good to have like these tests out there who are written against this specific behavior. But then it becomes like annoying for us if we change like that's what, let's say for example, these like 300 millisecond heuristic.

32:54 If people would start hard coding it in their tests, like, hey, wait for 300 milliseconds and then assert that the content is there. Like if we change that value, every test is going to break and now it becomes technically a breaking change even though this is like very heavily data driven. Like you just look at like what is good UX

33:14 and then you're like, because I think it was originally 500 milliseconds and then turned it down because it was like too long and we used it in like more scenarios. Yeah, but it's all implementation detail. And that's one of the nice things about the queries as well is that they don't really care about how long we're waiting.

33:35 We're just waiting until this thing is found or whatever. Yeah, it's similar with like act itself because then it becomes like the original motivation was when like use effect was introduced. Then it became from, okay, react was like fully synchronous. Like if you render something, everything is there.

33:53 Even like the component did mount ran, but use effect was always like in the next tick. And then act was like, okay, if you do this, everything that's rendered is gonna be flushed out and committed to the screen. And now it becomes like more with like,

34:08 okay, suspense and like the user and all of that stuff. And then at some point maybe act is like doing too much because now the intermediate states are like gone and then yeah, it's really hard. Yeah, yeah. We're gonna figure it out. Yeah, I'm confident that you will. And I appreciate you giving us some of your time today

34:28 to talk through some of these things. Was there anything else that you wanted to talk about that we didn't get to so far? No, I think we talked about like replaying all of the server on the client, like unifying that. That is like really nice. That's exciting. I think maybe like the one little teaser is like that React components are gonna show up

34:50 in React DevTools real soon. If you wanna try it out, if you use a extension build from main, that works already. Oh. And that was like long in the waiting, right? Like everybody wanted this. Like I needed this like so often, like debugging some issue on vercel.com.

35:10 It's like, what are these components? Where does it come from? It's like server components that are hidden in DevTools and you're like, okay, now I need to learn the code and I don't want to learn about product. Yep, yep, I get it. Yeah, that's exciting. Thank you for working on making our developer experience with React so much better. Yeah, yeah, I mean like most of this stuff

35:32 is like Sebastian Markwoge. It was like the long-term vision and we are all like, I specifically, I'm just here to get the vision out to people, to make it work on Next.js, to make it work on React and figuring out like the little paper cuts everybody has

35:52 so that we can all benefit from the vision, yeah. Awesome. Hey, thanks so much, Sebastian. It's always a pleasure to chat with you and where's the best place for people to connect with you if they would like to reach out? Oh, it's like, it's gonna be on Twitter. It's like twitter.com slash Sep Silverman.

36:13 Or like Silverfox.dev, yeah. Super, all right. Hey, thanks so much, Sebastian. Thank you. See ya, everybody.