TMiR 2024-12: React 19 is here 🎉

Transcript from Tuesday December 24th, 2024

Carl Vitullo: Hello people. Thank you for joining us for the December edition, the end of 2024. this is almost this year in React, this time around. [00:08]

But yeah thanks for joining for December's This Month in React, wherewe recap and digest recent developments in the ever evolving React and web ecosystem. Coming to you live from Reactiflux, the place for professional React developers, and supported by Infinite Red. [00:22]

I'm Carl. I'm a staff product developer and freelance community leader here at Reactiflux, where I run community programs like this. [00:29]

Mark Erikson: Hi, I'm Mark. My day job is working at Replay building a time traveling debugger for JavaScript and outside of that I do ridiculous amounts of Redux stuff. [00:39]

Mo Khazali: And I am Mo. I head the mobile team at Theodore. I'm quite active in the React Native ecosystem and I organized the React Native London meetup and conferences. [00:47]

Carl Vitullo: Right into it. I don't really have a job market or conferences coming up this month. I had noted that over the last, six weeks or so, the list of upcoming conferences has dwindled down to zero. I've seen them start to pop back up again. [01:01]

So we've rounded that corner of people getting prepared for next year, but we'll be back with some more conferences. to notify you of next month. [01:10]

Mark Erikson: that is that I actually sat down and started trying to do preparation for applying to conferences for next year. Some of them apparently have already closed for next year. So it's, getting ahead of the timeline process. [01:24]

Carl Vitullo: definitely getting ahead of it. Yeah small fun news for me, I am on staff for SquiggleConf next year, so, I'll have news for that, but it's not until September, so, no rush. Highly [01:36]

Mark Erikson: recommendd folks going to SquiggleConf. It was great. [01:40]

Carl Vitullo: But yeah, into it. Before we get all the way into the main content a note from our sponsor. [01:45]

Carl Vitullo: We are sponsored by Infinite Red, which is an expert React Native consultancy. They've been around since 2015, so like about to be 10 years, Give it another week or so and that'll be ten years. They're owned by Jermaine Holmgren, Todd Wirth, and Gant Laborde. They're our only sponsor in part because they do so much more than most consultancies and most of the companies in the ecosystem. [02:07]

there's just not many other people who operate at the same level as they do. I've been seeing their name for as long as I've been active professionally. And they're still around. They're still doing great stuff. They only do React Native. They've built over 75 apps for companies and startups. [02:21]

And other than great people who've done great things for the ecosystem they're a team of about 30, mostly devs, mostly 10 years of experience or more and they work alongside your team to develop expertise at that company. So if you are spinning up a new product with React Native, or just trying to develop in house expertise with React and React Native, they can definitely help you hit the ground running. [02:44]

So give them a ring. https://infinite.red/. [02:46]

New Releases

Carl Vitullo: cool. Into some new releases. [02:48]

Relay v18.2

Carl Vitullo: First on the list, we got Relay18. 2. They've got an experimental hook for pagination with prefetching and a at catch directive, or the catch directive has been updated so it can be used on fragments and queries and mutations. [03:03]

So just better error handling, looks like. Better pagination, better error handling. [03:07]

React Admin v5.4

Carl Vitullo: There's React. Admin, 5. 4 not a lot of notes here, but it's out, it's new, if you're using it, definitely check it out. [03:16]

Preact v10.25

Carl Vitullo: Preact has a release, 10. 25 looks like stronger types. Support for object interface as a listener, , It looks like the last couple of releases have all been pretty small. So, you know, this is just sort of Preact doing its Preact thing. I'm not really sure if they're still abiding to the original idea of like drop in replacement for React. It's, I think, especially with React server components, they've diverged a little bit. But yeah, there's still use for it for sure. [03:45]

Mark Erikson: Yeah, I've not sat down and tried to do a strict line by line feature comparison, but I think at this point generally support most of the original hooks. But I think beyond that, , they've stopped trying to match things feature for feature. So, if you're doing relatively straightforward things, then, you may have actual compatibility, especially if you like want to use any of the new, like React 19 features or anything with the Preact bundle, then obviously they wouldn't work. [04:14]

Carl Vitullo: right. I guess my mental model for it is this is like, if you're working in a highly constrained environment where you would still like the niceties of React, React is great, but if you're not dealing with a highly constrained environment, then might not be necessary. [04:28]

Mo Khazali: So an interesting one, I guess an interesting use case for Preact is that it's commonly used in TV development. If you're building web apps that are going to run on TVs, where there's a very, very small amount of resources. A lot of times I've seen people use Preact. So some big names in TV apps that you might've known, which I don't know if I should mention, but you know, some big TV apps will be using Preact because a lot of the apps that you have on TVs are web apps, but they need to be constrained in the resources that they use. Mm [04:57]

Mark Erikson: is just ironic how Web app has become the default, way to distribute things everywhere. I [05:05]

Mo Khazali: Yeah. I mean, web is like kind of a standard almost for TV, for TVs. Like if you're building for Samsung, if you're building for LG and a bunch of other TVs, you build it using a web app, so it's pretty cool that it's standardized around that. [05:18]

Carl Vitullo: Yeah, I talked to someone about React Native on TV too, yeah. Neat. Funny. JavaScript eating the world. [05:25]

Playwright v1.49

Carl Vitullo: There's also Playwright 1. 49. Nothing too fancy there, but pretty widely used test tool, so if you're using that, there it is. [05:33]

Astro v5.0

Carl Vitullo: Astro has a major release, version 5. 0. what they're calling content layer, a new flexible and pluggable way to manage content, providing a unified type safe API to define, load, and access your content, no matter where it comes from. Sounds a lot like Gatsby's [05:48]

Mark Erikson: was about to say that, yeah. [05:50]

Carl Vitullo: So fair enough, you know, like that's a real need, you know, loading content from many places. Very real need. Sounds like they're not using GraphQL for it. So, different take. Fair enough. [06:00]

Radon IDE

Carl Vitullo: Yeah, there was Radon IDE. Mo, you want to talk about that? [06:03]

Mo Khazali: it used to be called the React Native IDE, and then they rebranded for obvious branding reasons to Radon IDE, fun little Easter egg. Radon on the element lists is RN. So, anyway React Native traditionally has not had an IDE. So, you know, you build in VS Code, but a lot of the functionalities that, if you were like a Swift or an Android developer, just wouldn't be there. [06:23]

And so, the folks at Software Mansion have created Radon IDE as sort of a way to make your VS Code more of a Full fledged IDE for React Native development. So it comes with a bunch of cool stuff like integrating with like your simulator and then being able to inspect elements that are on the screen and find out where they are in code, which is really, really cool. [06:42]

And it's sometimes a pain in React Native breakpoint support, understanding your navigation tree. They have debugging kind of nailed down, which has been a real pain in React Native, so that's quite cool. And then another thing that was a cool little gimmicky feature, I'd say, is instant replays. [06:57]

So, you know, if something happens on your simulator and you're like, oh crap, that was a bug you can click back and get, like, the last 5, 10 seconds as a replay and then save that , to a file. So some cool little utilities, I'd say that you can use when you're building React Native apps. It is a paid IDE, so You know, it starts at, it's around 20 a month per seat. [07:17]

But you know, so something to consider. So they're going for the paid model as almost a paid extension onto VS code. [07:23]

Carl Vitullo: Interesting, huh? Definitely makes sense. I mean, times I've worked with React Native, the debugging experience was among the rougher sides of it, so it makes sense to have a stronger IDE integration for debuggability things. Cool. [07:37]

and I believe Software Mansion is also Nope, never mind. I was gonna say behind React Admin, but no, they're not. [07:44]

But then Software Mansion does lots of stuff in the ecosystem. They are Certainly, you know, I say not many companies do as much as Infinite Red and Software Mansion is definitely in the running there. A trusted name for sure. [07:57]

React 19 compatibility in react-redux and Redux Toolkit

Carl Vitullo: Yeah, there's also React 19 compatibility release of Redux Toolkit. [08:02]

Mark, anything you want to say there? [08:04]

Mark Erikson: yeah number one, I actually had nothing to do with the work on these. One of the other maintainers, Arya, did all the actual grunt work. in React Redux, we now test against both 18 and 19. you'd think it would be as simple as just bumping the peer dependencies list and shipping, but, you know, you actually want to test against them, you have to check any, any types related issues. [08:27]

in the Redux toolkit case, it's actually caused a ripple effect where we. I merged the PR to support React 19 at, you know, at the code level. And we accidentally ended up, semi accidentally ended up bumping React 19 for our DocuSource based docs website. And that ended up breaking client side interactivity because we were still on DocuSource version two. [08:52]

Which didn't correctly support React 19 somehow. So the doc site built and you could view it, but it was the static, you know, HTML only and all the client side interactivity broke, search, copy code button, everything else. On the one hand, it's like, you know, conceptually, it's simple. On the other hand, there's actually a lot of work involved. And then there's always the, you know, the unexpected ripple effects afterwards. [09:19]

One other ripple effect I've seen, which I don't think we have listed directly, but I've seen a lot of people report problems with Create React App because, you know, like, beginners are trying to I assume beginners are trying to create new CRA projects. They're using, you know, It uses NPM to do the installation by default, and the CRA templates still use an existing version of React testing library that wants React 18 as a peer dependency. [09:50]

And so, what happens is, NPM tries to install the packages, Also tries to install React 19, because that's the latest. And then, NPM being its helpful self, throws an error because there's a peer dependency mismatch between the installed React 19 and React Testing Library 1. 18. So, I've seen a bunch of people report, Why can't I create a new React project? [10:16]

With that kind of an error in the last couple weeks. And so basically CRE's borked at this point. I [10:22]

Carl Vitullo: That is unfortunate, yeah. But also not too surprising. I guess it's a little bit of a matter of time for that. Too [10:28]

Mark Erikson: in theory it could be fixed with, like, someone publishing updates to the templates, but I have no idea who, if anyone, would do that. [10:35]

Carl Vitullo: Not sure how actively maintained that is anymore. [10:37]

Main Content

Carl Vitullo: Alright, into our main content. [10:39]

React 19 is finally out (blog post)

Carl Vitullo: The main, main, main, main, main content of React 19 is out. It is officially released and usable. [10:47]

Mark Erikson: Yay! [10:48]

Carl Vitullo: Yeah, so, we're gonna spend a minute, pretty much everything in these, you know, release notes and, , overview blog posts. , there's nothing brand new, , they've been messaging this, they've been talking about it, they've been, you know, trickling out bits. over the last year and a half. So pretty much everything in this episode that we're going to discuss, at least for React 19, we've already covered in some detail in the past, but we're going to bring it all together. this is the one where we talk about it all holistically. [11:16]

Upgrade guide from April

Carl Vitullo: Yeah, there's a great upgrade guide from back in April. I think that was before they found the issue with Sibling. [11:23]

Mark Erikson: Yep, because that happened at the start of June. [11:26]

Carl Vitullo: So that was when they thought it was going out pretty, pretty shortly. Here we are eight months later, and it's out! [11:31]

Removed things

Carl Vitullo: I'm gonna start with what they took out, because I, it's a lot of things that I, Remember using, I remember fondly. [11:38]

So they removed prop types. There's no more prop types it just silently gets ignored. know, they mentioned prop types were deprecated in April 2017. So here we are seven years later, and it's finally, a deprecated feature is finally being removed. Wow. Likewise, they removed default props for functions. For class components, those still have default props, but for a function component, just give it a default argument. It'll figure it out. [12:05]

Finally removed legacy context. Also, just like prop types, deprecated in October 2018. Six years later, here we are. They removed string refs, the create factory helper, because that was if you can't use JSX, you can use this instead. So yeah, everyone uses JSX. Widely supported. [12:25]

Mark Erikson: I've used a couple different little third party helper libraries for JSX environments, but this was one that was sort of built in. [12:34]

Carl Vitullo: Yep [12:34]

some testutils, removed some deprecated DOM helpers. Or, Render and Hydrate are now removed in favor of their concurrent equivalents, the CreateRoot and HydrateRoot, as well as UnmountComponentAtNode and FindDomNode. They also removed UMD builds, Universal Module Declaration definition. [12:58]

Mark Erikson: Definition, yeah. [12:59]

Carl Vitullo: Yeah, that's not really been super relevant for a very long time now, not sorry to see that go. What was the, what was the main tool that used UMD? [13:09]

Mark Erikson: Well, okay, so, recap for people. So we had, you know, we, originally we had script tags and everything's a global, and then the AMD format, Asynchronous Module Definition, was a, community created module format for use in the browser. CommonJS, loosely put, was designed for use in Node because it requires reading a file off disk synchronously. [13:31]

UMD was a, someone figured out the incantation to wrap the actual code that you cared about in a complex header that basically tried to figure out, am I being loaded as a script tag, a CommonJS file, or an AMD file, so that one bundle could serve as all three formats. Simultaneously. In practice, UMD files have basically been generated for use as script tags loading off of unpackage or something like that. [14:04]

Carl Vitullo: sure, right. Yeah, I was thinking of RequireJS with the AMD module. but yeah, now with ESM and you know, dynamic import and all the bundling tools that we have now, that's, that hasn't really been relevant in six or eight years, something like that. Or it hasn't been cutting edge, at least. Hasn't been the recommended. [14:22]

But yeah, so, cool. That's all the stuff they removed. A lot of old things that haven't really, that have been deprecated for long enough that, yeah, they can go away. [14:32]

Mark Erikson: Yeah, a couple observations there. One, I made the same decision around removing the UMD bundles from the Redux packages when I shipped RTK 2. 0 last year. The difference there is that I replaced it with an ESM format file that had all the process node env references compiled out of it. [14:52]

And the React packages still don't have, quote, proper ESM support. So this, in one sense, they did actually remove something without a direct replacement for it. I've seen a number of suggestions to you that if you need to use React, like, in essence, as a script tag, then the intended replacement is to use a site called ESM. SH, which I actually looked into that a little bit, and what it does is it apparently uses ESBuild to compile various third party libraries with some sort of an ESM wrapper around them. So, even though React itself is still only shipped in common JS format, this site, this service it'll re wrap various packages with ESM around them, even if they didn't ship with it. [15:46]

And then serve that up as, you know, a script tag. [15:50]

Carl Vitullo: Interesting. Yeah, I hadn't heard of esm. sh. Looks like it's maybe sponsored by Cloudflare? It says the CDN is powered by Cloudflare. So it looks like this might be a service, you know, for the ecosystem that they're running. [16:05]

Mark Erikson: and then the other one is, if you look at the issue with people complaining that find DOM node was about to be removed, there's, there's still a number of people who are not terribly happy about that one. they've got cases where their component structure is, it's deep enough, nested enough that they, they needed to rely on find DOM node to Find the right things to interact with and, people are not happy that it's been taken away. [16:30]

Carl Vitullo: That seems a little strange to me. I feel like if you're in that position, there are native browser features that would do you pretty well enough, but okay, sure. I've not been in that situation, so I don't know what the weird technical trade offs involved there might be. [16:44]

Mark Erikson: And then our favorite hidden internal non documented API, SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED, has been renamed to SECRET_INTERNALS_DO_NOT_USE_OR_WARN_USERS_THEY_CANNOT_UPGRADE [17:00]

Carl Vitullo: okay, that's a little more descriptive. It's a little more actionable. I don't know of anyone who's been fired for using those, so, a little more accurate. [17:07]

New things

Carl Vitullo: Yeah, some, getting into some new things, what they're, you know, what they've added now looks like, to me, it looks like the big stuff is mostly around transitions. my mental model for this is a little bit like, for most of React 18, we used like useState and useEffect and like a couple things around there to do basically everything. [17:31]

And I think the core team identified that there was a pretty consistent and tricky use case of what happens when you need to take actions and manage state as components are, mounting and unmounting. That was definitely a little bit painful. Getting the intricate dance of as things unmount and remount, or different things swap in to replace them has definitely been awkward and tricky, especially for little things like animations. [18:02]

Like If you have an animation, you can't actually unmount until the animation is completed, which may, you know, if you have a state change that would remove the component, but you want an animation to finish, then you need to like add in this like extra ceremony to keep it technically mounted while not actually in use, not actually responding to new events and things like that. So that's my mental model for what these transitions are intended to support. [18:28]

Mark Erikson: That feels a little different than my understanding. So I've not used transitions myself, probably because I haven't been writing as much React front end stuff lately. But, like we, you know, there used to be the discussion of, you know, React 18 is going to have a concurrent mode. [18:42]

eventually said, okay, like, having an entire mode isn't what we need, we're going to have concurrent features instead. So my, my understanding is that transitions are, primarily part of that concurrent feature set where you're basically telling React, we're going to start a render, but this is going to be considered low priority. [19:02]

This could be interrupted. It will do the, like, you know, render a tree for five milliseconds and then pause to see if the browser has any events. So, my understanding is that transitions are primarily telling React, do some work, but this is considered a low priority render versus all the normal use state type based rendering. [19:26]

Carl Vitullo: Interesting. Okay, fair enough. [19:28]

so this is where the, you know, confusing verbiage that React introduced around like actions and how now we have many, many, many Actions is a very overloaded term in the ecosystem. [19:40]

Mark Erikson: for Redux, another thing for MobX, now another thing for React Forms. [19:44]

Carl Vitullo: Right, and I remember Astro had an actions thing as well a while back. So, right, there's just many, there's a lot of actions being taken. Yeah, so functions pass to start transition are actions. There's some additional hooks that are also able to tap into those, into the Actions as being used by active transitions. [20:05]

So there's used action state which is a new hook to order actions inside of a transition with access to the state of the action and the pending state. So it, accepts a reducer that can call actions. So this is this smells a little bit like redux, baked into an interaction. a little bit. [20:24]

As well as useOptimistic, which ties into these transitions by letting you update state while the transition is in progress, and it returns the state as well as a set function to optimistically update the state within a transition to be the expected final value. So, you know, like if you're doing optimistic updates within your UI, firing it off to persist in the back end, but immediately updating the local UI as if that has already finished. [20:51]

But then gracefully handling the actual outcome of the of whatever action you took. [20:57]

Mark Erikson: one observation here, you know, less around the behavior and more around the description. When React 19 came out a few weeks ago, the post in the JavaScript subreddit, the main discussion was basically around that paragraph and how hard it is to read for someone who isn't intimately familiar with React already. [21:19]

And You know, a couple of different thoughts around this, like, one is that, you know, React has added a lot of things over time. Another is that there's been some cases where the React team has tried to turn things into proper named nouns in a way. Like, it's not just like, the useEffect hook, there are capital E effects. [21:44]

And so, and so now it's not just, you know, we're going to do a low priority render, it is a capital T transition. And I, I just glanced at the docs. Like I'm, I'm looking at the use transition docs page and it does intro with use transition as a react hook that lets you render a part of the UI in the background, but like it right away starts using capital T transitions without ever defining what that word means. And there isn't really like a conceptual explainer. [22:19]

So, part of it, like I realized that release notes aren't the right place to, you know, to go out and define a bunch of things, but both reading this specific paragraph, as well as trying to figure out how some of these new features are integrated into the docs and the teaching workflow, it feels like they're like, we're kind of missing a bit of a, like a conceptual explainer for some of these terms and how they relate to each other. [22:46]

it's fixable, but, you know, like that, that's just one of the things that stuck out to me. [22:50]

Carl Vitullo: Yeah, makes sense. Yeah, that's fair. it feels like an Apple type of branding. You know, it's not a, it's not an mp3 player, it's the iPod. [22:59]

Mark Erikson: not the, just iPod, iPad, iPhone, whatever. [23:03]

Carl Vitullo: No articles. Sure. [23:04]

Yeah. other than transitions, they got the use hook, which is a little bit old hat by now, accepts a promise or context for accessing resources within render. If you give it a promise it will suspend until the Promise is resolved. [23:19]

Mark Erikson: the naming still feels awkward, like, I don't have a better suggestion, but, in today's world, naming things for Googleability is very relevant, and giving this thing the name use is like the most un Googleable thing ever. [23:37]

Carl Vitullo: There, right, right. [23:38]

And back to my pet peeve about some of the quirks of React 19. This is the use hook, and it says right in the release notes, use can only be used in render, but can be called conditionally. And like, come on, rules of hooks, like, drilled into us repeatedly. Anything called use Use whatever. Cannot be called conditionally. [24:04]

Mark Erikson: With the exception that you could already get away with, you could apparently already get away with calling useContext conditionally. I've never actually done it myself, but apparently, technically that worked. [24:14]

Carl Vitullo: Interesting. I have not either. I don't think I knew that, actually. So I guess, cool, this is consistent with use context. [24:20]

So clearly, I guess, it has its lineage in there. It is the way to use context. it just seems a little strange to me to, like, this seems like it's going to be a very widely used hook, and so for it to break the rules of hooks, quote unquote, quote unquote. [24:34]

Feels like it adds a lot of, I don't know, weirdness, ambiguity, confusion. [24:39]

Mark Erikson: it does I mean, I know that there's plans to hopefully expand that down the line. My, my Redux co maintainer, Lens, who also works on Apollo, has been begging for the ability to pass an observable. to use for a while now. So it's possible that that may happen at some point. It also is kind of one of those things where like they, you know, they needed the rules to be strict originally. [25:03]

And now that the rules are defined and the ecosystem understands them, they can start to tweak it. But as you know, that also leads to confusion as well. [25:11]

Carl Vitullo: Right, right. it's all a game of telephone and this adds strangeness. It adds exceptions to the rules. lots of other convenience features coming out with React 19. You can render metadata tags in components wherever, and they'll automatically get hoisted into the head section, which is great. [25:28]

I, I think I said it when this was first announced, but like, the, React Helmet was, as far as I know, the main way to really interact with head in React, and it was just like not very consistently maintained. I kept running into, like, I feel like every time I used it, every time I was spinning up a new project and trying to interact with the head, it's like, oh, React Helmet, cool. [25:48]

Pull that in. Oh, this does not behave in the way I expect in these many different ways. And so then what I thought was just gonna be a trivial, it works. Was not, was not trivial, did not work. So love that. Love to see that. [26:03]

But yeah, RIP React Helmet. That was, I remember, I remember when that was released. I remember that was announced and going like, what the hell? NFL is releasing an open source project at the bleeding edge and they called it React Helmet. This is perfect. Protects the [26:18]

Mark Erikson: one, definitely one of the best project names ever. [26:21]

Carl Vitullo: Yes, absolutely. So, RIP to NFL's React Helmet. another convenience feature, you can use async scripts. [26:30]

You can render them anywhere in the component tree, and they will be, React will handle the ordering and deduplication of them, which is neat. Yeah, deduplicating async scripts sounds That makes me a little scared. But yeah, I guess it shouldn't be too bad as long as you're not doing any weird stuff with the file name. Yeah, likewise, more head stuff. React 19 will ensure style sheets are inserted into the head before revealing the content of a suspense boundary. So, you know, predictable, Easily anticipated ways of interacting with the head. Also some initial load optimizations. Initial load and transition, page transition optimizations around pre init, pre load, pre fetch DNS, pre connect. [27:14]

These are all, like, kind of low level optimizations that used to be exposed at the level of, like, script tags, where you could say, you could communicate to browser what level of initial connection to try and get ahead of. You know, because it takes a little bit of time to look up the DNS, to connect to the server, to open, you know, begin streaming data. [27:34]

So, it sometimes introduced extra latency that was undesirable. So you can now, in React 19, have a little bit more control over how external assets get loaded in that way. You know, just even like pre fetch DNS and pre connect. Will cut the latency a decent amount. I've used those things in the past. It's a pretty nitty gritty performance optimization, but yeah, definitely important that we can now do that. That's nice. [28:00]

Yeah, a big one, a nice one. One less use case for Refs can now return cleanup functions, so that's definitely big. That's definitely good. I think it had definitely been a pattern to, like, do a useEffect, to do things like setting up event listeners, and that was a little bit weird. [28:19]

I don't know, it's just a little funky, because they're, they're clearly tied to the DOM. It's associated with a DOM node so having to do it in useEffect introduced, it just, extended that distance between the code that was being run and what it relied on. You had to do extra weird deduplication stuff because it was an effect. [28:36]

So now, because refs support cleanup functions, it's just a little bit closer, you can keep it a little more self contained. [28:42]

Ref Callbacks, React 19, and the Compiler

Mark Erikson: Yeah, and there's a, there's a good post from Dominic Torfmeister, the, you know, maintainer of React Query, he had written about dealing with, dealing with refs a couple years ago. And so he kind of revisited that topic and showed that, you know, hey, there, here's, here's cases when, You know, now you can do things like setting up a resize observer in a ref, and you don't even have to have a useEffect plus a useRef to manage that. [29:10]

Carl Vitullo: another very small convenience feature, you can now render just context instead of context. provider. That's nice, that's good. Very small, very petite. React 19 also has support for custom elements, i. e. web components. For the first time in React's history we discussed that at much greater length in previous episodes. I don't know if there's that much more to say, web components. If you're using web components, cool, great, now you can use React as well. [29:36]

Mark Erikson: it's still really complicated You know, a lot of it boiled down to, like, React can, in theory, render any arbitrary HTML tag. React have a hard coded list of element types that it knows are part of HTML. But, React 18 and earlier had issues with properly passing complicated props into web components. [30:02]

And that's because of the whole difference between HTML attributes versus JavaScript DOM node properties, which I still only partly understand myself. But think part of the issue was React wanted to pass in. properties, but a lot of these things expected attributes instead. [30:23]

And so there, there was a mismatch in, in how things would get passed down as well as issues with setting up event listeners as well. And from what I've read, went into the, the mile long discussion threads, they're like the web component spec does not necessarily define how a given web component receives this. [30:42]

it's It's implementation dependent on a per web component basis. So it's literally how it's almost as if every single web component author, as they write that component decides, how is this component going to get its data or trigger its events? And so, different libraries, different wrappers, different authors take different approaches. [31:09]

And so, part of the issue with implementing this was trying to find a reasonable set of heuristics that would work most of the time, and also allow React to pass this web component in framework compat spec that had been put out there. And after React 19 came out, I saw a couple more people posting complaints that certain scenarios didn't work right. [31:34]

Like, I guess if you define a function field on your web component class. And then you also try to pass in a prop with that name. React will happily overwrite the function because it just assigns the field name, but ultimately it seems like web component authoring is a very inconsistent and per component basis kind of a thing. [32:00]

And there's a lot of edge cases with the interop and so they're never going to make everybody happy. [32:06]

Carl Vitullo: Awesome. Sounds great. Yeah, the finer points of attributes versus properties is, my eyes began glazing over at that point. [32:13]

Mark Erikson: Yep. [32:14]

Carl Vitullo: Yeah okay. a convenience that got me a little excited in React 19. Hydration errors will now be collapsed into a single error, even if there are multiple mismatches. [32:23]

Like, nice. [32:26]

Just [32:26]

Right, just having my console be blasted with, like, 30 stack traces because, like, obviously this hydration did not match is, yeah, very happy to have that just be didn't work, not here's every point at which hydration did not work. That's nice. [32:44]

So kind of subtle, I don't quite, I don't understand the, the precise details here, but errors in render are not rethread. If they're not caught by an error boundary, they're reported to window report error, not logged with console error. There's also, they've introduced onUncaughtError and onCaughtError methods to the create root and hydrate root. APIs to customize how those errors get handled. So I guess they're kind of stepping back from like automatically handling every error and logging it to the console to saying, if you have a boundary, we'll log it. [33:18]

If you don't have a boundary, you can configure how it gets handled on your own. [33:23]

Mark Erikson: You know, that's interesting. This, this might be the kind of thing that libraries might end up caring about more, but I, I actually feel like I need to go back to those React 19 compat PRs that I did not write myself, but I did merge. Because I, I think we had some tests where we had, like, assertions that, like, if an error happens while doing, like, a React Redux render or something, that errors would either get thrown of rendering or get logged somewhere. [33:50]

So now I'm actually curious how we, how those PRs ended up handling them. [33:54]

Carl Vitullo: Sure. Right. You can never know what you don't know. obviously that's the majority of our, I think that's the majority of what we wanted to get to today. [34:01]

But uh, yeah, Mo, tell us about React Native screens. Hang [34:07]

React Native Screens 4.0.0

Mo Khazali: Major version of the React Native Screens library, version 4. 0, came out. So, you, as a React Native developer, probably don't interact directly with React Native Screens. If you use React Navigation or ExpoRouter, which uses React Navigation under the hood, you will be using React Native Screens. [34:23]

React Native Screens is native layer implementation of screens on iOS and Android for your app so that you're not creating JavaScript views and not handling the view transitions on the JavaScript layer, rather you handle them on the native layer. And so a few updates here that will likely be picked up by the React Navigation libraries. [34:43]

React Navigation and ExpoRouter libraries. One is that they're adding more support for the forum sheet presentation. So this is kind of the bottom sheet interaction that you'll be used to on phones. And previously it wasn't supported on Android. And now there's an Android support. It was supported on iOS but you had a limitation. [35:02]

So if you ever played around with those bottom sheets, you can kind of pin them to certain points, and they'll kind of stick. They call these detents, I think. [35:10]

Carl Vitullo: This is like the sort of mobile version of a modal, where it's like an overlay that you slide around. [35:16]

Mo Khazali: Yeah, exactly, those ones. So the ones that come from the bottom, and, you know, you've got a little modal, and the screen behind it is still kind of visible, and you can adjust how big the modal is. they call them sheets, I guess, in mobile development. Modals, when you're talking about in a mobile navigation world, it's the ones that kind of fully cover the screen. [35:35]

Not the ones that can partially cover the screen. So you've got some of these pop ups that fully cover the screen. Sometimes you'll see them on, like, login pages or something like that. And so, a lot of these sheets, you can kind of control where they are, so you can pin them to different locations. [35:47]

So, with this new API, you are able to, on iOS, set as many points to kind of have these snap points. And on Android, I believe, there's three different snap points. That you can define. So this is kind of sticking true to the iOS and Android APIs on the native layer. They've also made some minor improvements on animations when it comes to iOS to make it a bit more smooth. [36:11]

And one of the other things that they've done is that if you've got a screen that's now detached, from the main tree of your navigation, so it's no longer rendered. You can preload these screens, and so this will kind of happen through React Navigation so that if you know a user is going to go onto a specific screen, you preload it, render everything, create the native views, and so you won't have this delay in getting the screen loaded onto the app, which is quite a nice feature, and I think this is great. [36:39]

Quite important for optimizing your app and making sure that everything is smooth, quick, and snappy. So those are kind of some of the things. You won't really be implementing any of these yourself. You'll probably use React Navigation, so keep an eye out on the React Navigation docs and the ExpoRouter docs, because some of this stuff will be landing. [36:56]

Some of it's already been landed as well. [36:58]

Carl Vitullo: Nice. Makes sense. Yeah. [37:00]

React 19 and React Native, and PR

Carl Vitullo: Tell us about React 19 and React Native. [37:04]

Mo Khazali: so taking a step back, React Native just released the new architecture. So that was the, big release that they've been kind of working on for many, many years. And so, I think they're going through a stabilization period right now. They are I think waiting to make sure that everything is smooth, stable with the last two versions of React Native that have been released. [37:26]

I suspect this will be some point in early to mid 2025, sometime in the next two releases of React Native, where they'll actually support React 19. I know that there's been some issues with supporting React 19 anyway with React Native. I think there's been some internal testing, but they haven't conclusively made sure that everything is working as expected. [37:46]

So, I think there's just going to be some delay on this. But I think it's not something that we haven't seen in the React Native ecosystem. There's sometimes a lag with these major version upgrades anyway. [37:55]

Carl Vitullo: Yeah, that makes sense. And especially, I'm just, I'm kind of connecting dots of what you were just talking about with like React Native screens, adding support for like preloading. And that sounds adjacent to, like, some of the use optimistic or use transition hooks that have popped up now as, like, first class APIs. [38:15]

So I wonder if that's maybe some of the tension there, is that now that it's a first class API, a feature of React 19, React Native needs to figure out how to implement it [38:28]

Mo Khazali: Because it's not just JavaScript there's also an element of, you know, how do you map those to native functionalities, right? So if you're transitioning to allow a native component to be rendered, well, how do you handle that on the native layer? [38:41]

So there's a lot more support that needs to happen, it's not just the browser. But you need to also make sure that at least iOS and Android support those features, not to even get into the whole out of tree platform shenanigans where you've got a bunch of other platforms that are maintained by the community and they also need to support it. [38:56]

So yeah, it has a long tail. [38:58]

Expo experimental support

Carl Vitullo: But it looks like Expo has experimental support. [39:03]

Mo Khazali: this is probably one of the musings of Evan Bacon over a weekend just hacking away, but yeah, there's a lot of these sort of, like, Expo kind of goes ahead of the curve with some of these things and tries to push the React Native ecosystem forward, which is great so, I'm not surprised that this is supported with some sort of flag in Expo. [39:21]

So yeah, it's the experiments. reactCanary, setting that to true. In Expo SDK 52, it works. These are very much experimental. Don't try these for any production apps, but it's just kind of trying to see what the effects would be ahead of time. I mean, we've seen this pattern, like Expo supporting RSCs with the bundler, with some custom changes to the bundler ahead of time before it's even, you know, supported, in any capacity officially by Meta. [39:46]

So, it's cool to see it, but it's still a long way to go for production apps. [39:51]

Carl Vitullo: Sure, yeah. Makes sense. [39:52]

Next.js experimental CSS inlining

Carl Vitullo: Well, I have a very, very small bit of React, er, a very small bit of Next. js news. They've added a experimental CSS inlining feature. And now, if you are generating, you know, if you're, you're, if you're pulling in CSS styles, instead of it being compiled into a CSS asset and Loaded with a link tag. You can configure next so that it will just inline those styles in a style tag Yeah, this takes advantage of the React 19 precedence in deduping You know, CSS features. [40:28]

So I guess this is enabled by React 19 But yeah, definitely pretty small, relatively minor performance optimization. [40:37]

Next 15.1

Carl Vitullo: guess a larger bit of news. Thank you, Mark. There's also Next 15. 1 that's out Yeah, last episode we talked about how Next 15 was stable and now they're up to 15. 1 [40:50]

Mark Erikson: The biggest one here is that because React 19 is now actually out, they've switched to using React 19 everywhere. So actually, it's kind of funny because for now they're on React 19 stable, but there's a good chance that they will continue using those canary releases in future versions of Next down the road. [41:10]

So this may actually be only a temporary problem. you know, period of time where they're, where the version of React they use actually exactly matches the stable version. [41:20]

Carl Vitullo: Right. I didn't know they have, you know, One of the headers on the 15. 1 release notes is React 19, parentheses stable. So yeah, right. They've been on Canary for forever. [41:33]

React Native Fast IO

Mo Khazali: Cool. So, next up we've got the pre release version of React Native Fast. io out. So this was sort of first showcased at React Native London Con in November. So this is made by Mike Grabowski, who is the co founder and CTO of Callstack. And so it's basically built on top of the Nitro modules package that we've seen and talked about in the past few months that's been made by Mark Roussevy. [41:59]

And so it's a way to create native libraries that are super, super fast to execute. And so, Mike from Callstack has been working on trying to get some of the I. O. functionality in React Native implemented with Nitro modules so that they're as fast as possible. And hence, React Native Fast I. O. [42:18]

So he started off with WebSockets but he eventually wants to target WebSockets, Fetch, FileSystem APIs, Blobs, and Streams. And so the whole idea is you can use the WebSockets or the Fetch that comes from React Native Fast. io and in theory it should beat all of the benchmarks for any other implementations of I. [42:36]

O. related functionality in React Native. So this isn't anywhere near production. But it's something that you can give it a shot and play around with and just run some benchmarks on and eventually at some point it should land and it could be quite interesting to see what that means for the whole ecosystem because these are quite core functionalities, right? [42:54]

Carl Vitullo: Yeah. I uh, definitely pretty low level. If that gets much faster, that enables a lot of other interesting experiments. [43:00]

Mo Khazali: Exactly. And I think The, one of the things with this is that it's one of the, like, first implementations of an actual library with Nitro modules. So, so far Nitro modules have been very hypothetical in terms of what you can achieve. Mark's been using it on a few of his libraries, but nobody else, sort of, in the community has adopted it to this degree to build an actual package. [43:20]

So, it can really start to push a lot of people towards Nitro modules when they're building native dependencies. [43:25]

Carl Vitullo: Neat. Cool. [43:27]

NPX Create Target

Mo Khazali: In other news, and we talked about Expo's random demos that they release with some cool features and going ahead of the curve. Evan Bacon in a very truly Evan Bacon fashion has been working on a new CLI tool specifically for iOS called NPX Create Target. And so the whole idea with this is, is that there are certain parts of an iOS app that you can't build with React Native and you need to build in the native layer. [43:51]

So what are those? Those are things like widgets, live activities. Lockscreen widgets, and there's a whole host of things that are not part of, like, the main app that you use, but are almost extensions on top of on top of your main app. And so, the whole idea with this is, is that it's been quite difficult to get these up and running with React Native so far, because you need to go into Xcode, add those, widgets and then kind of do the binding between your React Native app and the widgets that you create or those targets that you create. [44:19]

And so the whole idea with this is is that it's a simple NPX command that you can run and you choose the type of target or widget that you want to use and then it kind of bootstraps all the code, links it to your React Native app, has a way for them to communicate between each other, and all you need to do is just write the Swift code to basically implement that on the native layer. [44:37]

And so it's a much easier way to add these targets to your existing application to your existing Expo application. So it's a pretty cool thing. It's, it's it's nothing that you couldn't do before, but it obviously was a lot more work. And this just makes it significantly easier to get up and running with those features to make your app feel even more interconnected within the OS, within the person's phone. [44:55]

I [44:55]

Lightning round

Carl Vitullo: Alright, that's all of our main content. Let's jump into the lightning round. Moe, you're up again. [45:02]

React Native demo for Android XR

Mo Khazali: So, quick thing. Android released some new features. Cool mixed reality stuff Android XR. So there's a whole release on that. And of course someone had to create a demo of React Native running on it. So there's a quick tweet showing React Native running on Android XR. [45:17]

We'll see how this expands, but it's always within days that someone creates a demo of React Native running on any new platform or any new APIs. [45:25]

Carl Vitullo: Nice, cool. Okay, so this looks kind of like Android version of Apple Vision. [45:30]

Mo Khazali: Yeah, it seems like it's a competitor to Vision OS, basically but Android's really trying to standardize the way that XR goggles are built with Android. [45:41]

Carl Vitullo: right, cool. Good luck. [45:43]

If Not React, Then What?

Mark Erikson: Another post from Alex Russell was going around in the last few weeks. Alex generally is on a one man crusade against client side JavaScript and the React ecosystem in particular. This one was titled, If Not React, Then What? And most of it boils down to most sites shouldn't be single page applications. [46:04]

Most sites shouldn't be using react. I guess there's other client side libraries that you can use, but generally they shouldn't be client side in the first place, which is frankly, like, like my own summary is actually a, like a reasonable stance to take. And if he phrased it that way, he would probably have more people listening to him. [46:23]

But the vitriol and the vehement and the anger that he puts into these posts, even when he has valid points, makes it really hard for people to actually listen to what he's saying. [46:33]

Carl Vitullo: Sure. I haven't read this in depth yet. I would like to but yeah, he like very strongly states that, let me pull a direct quote. " React is a legacy technology, but it continues to appear in Greenfield projects. In short, nobody should start a new project in the 2020s based on React. Full stop." That is uh, not something I'd agree with. Strongly stated. [46:57]

Mo Khazali: reading the About Me page, and Alex Russell, I didn't know this, works at Microsoft. And he's a partner project manager on the Edge team. [47:05]

Mark Erikson: he was previously at Google and he also basically invented like two thirds of what we now know as the web component spec as well. I. [47:11]

Mo Khazali: Yeah, I wonder how Microsoft feels about these stances. all of these posts are, these are not my, you know, employer's opinions. These are endorsed by no one except me. [47:22]

Carl Vitullo: I randomly, I was just trying to refresh my memory on who Alex Russell is. Cause I, I recognize his name, I know his Twitter handle is slightly late, and I have seen him for years, as like, somebody in the ecosystem. So I was just trying to refresh my memory more specifically, and I quickly found A random Hacker News comment that describes him as early member of the Chrome team, three time elected member to the W3C from 2013 to 2019, and representative of TC39 from 2006 to 2017. [47:52]

this is from two years ago, and it says, Lately, he's been very critical of single page apps in React, going as far as to call the past ten years a lost decade. guess he's been on this for a minute, but has some, like, Drawing deep credentials to, on, you know, web technologies. So, interesting. [48:08]

Curious. But if he's on, if he's coming at this from a web components perspective, that adds a lot of color to my understanding of the situation and his arguments. [48:19]

Mark Erikson: my take on it is like, he, he absolutely has the technical credentials to back up most of his opinions as well as statistics on like how bad, I mean, like many website bundles actually are like, he's not wrong about that, but he then goes from that to say that anyone using react is doing it wrong. Basically any single page app is wrong and the people who push react have been doing so with malicious intent from day one. Which is way over the line. [48:49]

Carl Vitullo: Yeah, I'm gonna, I would disagree strongly with that. I feel like in, I feel like I can understand his macro perspective there, cause like, I have used a lot of like news websites that are like clearly using React very badly. It has been, it has been put in a lot of contexts that I don't know that it was the best tool for the job, because it was a popular tool that was easy to hire for. So I guess I can empathize with the perspective a little bit, but, I don't know, the nuance there, I feel like there's more nuance [49:18]

Mark Erikson: no nuance, and that's the issue. [49:20]

Mo Khazali: Well, just to go a little bit more into this. I just read his Rebuttal to if someone says, well, what about React Native? And I'm just going to read this verbatim. "React Native is a good way to make slow apps that require constant hand tuning and an excellent way to make a terrible website. It has also been abandoned by its poster child, [referring to Airbnb]". And then he goes on to suggest that you should use Capacitor and Cordova instead. Cordova is The poster child of making awful applications. [49:47]

Carl Vitullo: everything he just said applies way more to Cordova than to React Native. [49:51]

Mo Khazali: yeah, his, he seems to be pushing you to make web apps and use those on mobile with responsiveness. So I've at least on the native side, I think his opinions are incredibly unvalidated. He's probably has more credentials on the web, but that is a bizarre take to then go and say Capacitor and Cordova are better options. [50:10]

Carl Vitullo: Oh yeah, yeah, definitely agree with that one. [50:13]

Mark Erikson: Moving right along. [50:14]

Vitest vs. Jest

Carl Vitullo: Great post titled Vitest vs Jest. I think this is Very needed. I think this is a great post. Just it starts with like just like a raw feature comparison comparing what does Vitest support and what does Jest support. And just goes into a bit of like a oral history of like, why did Jest appear? Why did it succeed? always appreciate some oral histories. I think it's really useful to understand how things came about. [50:41]

Like I remember when ultimately Jest succeeded because it got open sourced. Also by Meta right, like within six months after React came on the scene. So like people had started using React, people had started using all of the everything Facebook was putting out, Facebook at the time was putting out React and Flux and then like, Oh sure, Jest. [51:06]

So it definitely got a huge, huge, huge boost by the timing of its open source release. I never really got a ton of professional experience using other tools like Mocha or Chai and all of those. I don't really know what the comparison is from my perspective like functionality wise they all seemed about the same and But I don't know I used Jest because I was early in my career and I didn't have opinions and it seemed popular So why not? [51:31]

Yeah, over the years definitely it became It, it became not a preferred tool of mine because I found myself needing to maintain parallel bundle configurations for, a production build, and then for Jest, and then for like end to end testing, and then, and so it's just like, it just became like one more target that made upgrading instance, like, new webpack or new, I don't know, any new core technology, I found updating Jest was just a huge pain in the butt. [52:03]

So it became not my preferred tool for that reason. And Vitest seems to be a little bit better about that, but But I have not had that same professional experience of, I'm on a team with 15 other engineers trying to update a core technology without breaking everything or stopping work. So that's really the litmus test for me on a tool like Vitest or Jest. [52:23]

And I've had negative experiences with Jest and no experiences with Vitest. Ergo, Vitest is obviously better. But [52:29]

Aiden Bai “render-shaming” sites while working on React Scan

Mark Erikson: there's a young engineer named Aiden Bai, who I, I think is, I could be wrong on this, might not even be 20 years old yet. But he's the creator of a tool called Million. js, which is kind of like a, almost like a proto version of React compiler where you could isolate parts of your component tree and it would optimize like the text updates in there. [52:50]

And he's since gone on and been working on a bunch of other React related performance tools. Some of them have been branded with Million as well. I think there's a like a million lint and like a a million VS code extension that try to highlight some React performance issues. But he's working on a tool called React Scan, and it loosely put pretends to be the React DevTools in the browser in order to get access to React saying, I just got done rendering, here's the new component tree. [53:24]

And he's been advertising this with a tweets that are kind of render shaming. Sites like he did one where he pointed out that like typing in a search input in Twitter Makes basically every component on the page Rerender and those naturally got a lot of circulation and stuff going around So he called out a number of sites that way And it's, it's both really, really clever marketing, as well as, you know, a bit of an example of ways that React does not necessarily lead to a pit of success kind of a thing you know, just because of, you know, React's default render behavior. [54:07]

I've very briefly dug, you know, dug into the source code just enough to see that that's how it's hooking into React's updates. I've not tried to go through the code and see how the rest of the analysis is implemented. But this feels very similar in spirit to some of the work I've done at Replay over the last couple years. [54:24]

So I, I always approve of people digging inside React's internals in ways they're not supposed to. [54:28]

Carl Vitullo: Yeah, I small reaction. I saw one of the site, one of the render shaming tweets he put out was about GitHub. [54:35]

Mark Erikson: The list view that is used to render source code was re rendering all the list items every time you scrolled. And so, scrolling performance was relatively bad. And he tweeted it, tagged someone at GitHub, and they did actually fix it like a day or so later. [54:53]

Carl Vitullo: yeah, that's worse than I was thinking. I thought it was uh, something about typing, but scrolling, ooh, rendering every line of code on a diff while scrolling. Yeah. That's, that's, that's not going to do good things. [55:03]

Mark Erikson: it's virtualized, so like it wasn't rendering like 50, 000 lines of code at once. But even just what was on screen could be, you know, relatively slow. [55:14]

Lenz’s Weber’s testing-library/react-render-stream-testing-library

Mark Erikson: And then the last one plug for a friend uh, Lenz Weber is co maintainer of Redux Toolkit and works on Apollo Client. And he'd been putting in a ton of work to try to write tests for Apollo in conjunction with React Suspense and ran into all kinds of problems. And this is one of those things that is, it's a library maintainer problem. [55:36]

This is not an app developer. But, you know, like we've, we've had lots of tests in the React Redux code base over the years that say, okay, I'm going to render a component, do an update. And I expect React will have re rendered this many times in the process. And as React's internal behavior changed over time, we kept having to go in and tweak those assertions, you know, like when, when React 18 switched to batching by default, like the number of render counts changed in a lot of our tests. [56:07]

And in fact, at one point we had to say, like, if it's 17, then we expect that this test will render four times. If it's 18, we expect it'll render three times, et cetera. So like, this is not the kind of thing that an application test would need to care about, but a lot of library tests needed to care about this thing. [56:26]

And, you know, we always implemented it with basically. You know, having a, having a variable outside a component, the components defined inside the test and you count how many times it rendered. So in the process of working on the test for Apollo, Lens came up with a new approach, which he's called the React Render Stream Testing Library, and it actually got included in the testing library. [56:52]

organization, part of the, like the RTL group that we all know and love. And this takes a different approach where it actually kind of buffers up all the renders that occurred. And then you can say, okay, give me almost like a wrapper for the contents of the next render in the sequence. [57:12]

And then let me write assertions against the contents of the DOM as it happened in that render. So you're still doing the usual testing library approach of, like, let me look for a button, let me, you know, assert that certain text is on screen. But rather than kind of conceptually testing it against a, quote, live version of the DOM, You're asking for a series of snapshots of it, and this library does the work of kind of buffering those, and then you can just sort of take the next one, do some assertions, take the next one, do some assertions. [57:47]

I actually tried making use of this in a test with Redux Toolkit the other day. And it required a bit of a mental model shift to try to use it that way, but it actually ended up being much more consistent, and like, I didn't have to write any waitfors, because it wasn't timing based anymore. So, again, if you're not writing libraries, you probably don't need this, but if you are writing libraries, this might be useful. [58:13]

Outro

Carl Vitullo: All right. That's all the news we have for you this month, this year. Woo! Thanks for joining us. We will be back next month on the last Wednesday of January here in the live stage, or back in your podcast feed just as soon as we can. [58:28]

Mark Erikson: And Mo was worried we wouldn't have enough to talk about. [58:31]

Carl Vitullo: Haha, it's gonna be a short episode. [58:32]

Well, [58:33]

Mark Erikson: all. Yeah look forward to talking with you folks next month, and enjoy the break, everybody. [58:39]

Carl Vitullo: yeah. Happy holidays. [58:40]

Mo Khazali: Always a pleasure. Hope everyone has a lovely time off, and enjoys the festivities, and uh, looking forward to what next year's got in store for us. [58:48]

Carl Vitullo: 2024 was good to you. Good to you all. It was good to me. It's been a, it's been a weird year for me, but a good one. Yeah, end of episode. Personal updates. this has been the first year of my life when I accepted for myself that I'm queer. I'm not straight. It's been a good year for me, I hope it's been a good year for you. [59:06]

Thanks so much. We gather sources from This Week in React, Bytes. dev, React Status, Next. js Weekly, our React. js, the subreddit, here in Reactaflux, and direct from those publishing articles. If you see anything newsworthy, definitely let us know at hello at reactaflux. [59:21]

com. Bye! I read every email that comes in, even the spam, so send me an email. I'll check it out. If this is a show you get value from and want to support, the best way you can do so is by submitting a review wherever you listen, and by telling your friends and co workers about it. Cheers. Thanks for listening.