Audio Edit - Aurora Scharff
===

Paige: [00:00:00] hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. I'm Paige Niedringhaus, and today I am here with Aurora Sharf, a software engineer on the Next.js team at Vercel, here to talk about designing the in between states with Async React. Welcome back, Aurora

Aurora: Hello. Hi. Thank you for having me back here. This is very exciting.

Paige: ~We're, yeah, I mean, it's been,~ there's been a lot happening with Next.js lately, so we are excited to have you here to talk about some of ~the, ~the new up-and-coming features. So let's just dive right into it. Can you tell us what you mean when you talk about designing for in-between states?

Aurora: Yeah, so it's kind of, I guess, a weird terminology that I just decided to name my talk, but ~it's, ~it's a nice way to summarize the problem that when you're doing something typically on the web and you have an interaction that a user is,~ like,~ clicking something, you need to think about what happens between the click and the result of that click, which is like the in-between state

Paige: So basically ~a lot of, ~a lot of what the web is, to be[00:01:00] 

Aurora: all of the web you have to think about this, which is why the web is, it's easy in a way, but it's also really easy to mess up. 

Paige: ~So, you know, ~talking about clicks or maybe form submissions or loading states or things like that, why do you think that this is more of ~kind of ~a UX problem than maybe a DX problem?

Aurora: ~Um, ~I guess I can go a little bit back and just talk about directly where you might have noticed this. So for example,~ uh,~ typically you would encounter this ~in, ~in different parts of the stack. If you're like in GitHub, you might have felt that you're like navigating around and,~ uh,~ it doesn't really respond that quickly.

You might have thought that GitHub is slow. And in most cases, the apps are not usually that slow, but if you have just a progress bar at the top or something that isn't localized, that's when you feel that the app is slow, even though the server is responding quickly. So the key here is really like lo- local feedback.

Paige: That's what I was gonna say. You know, as a developer, if you're doing some local development on your web application, because your database might be [00:02:00] right there and your apps are all running locally, it's not necessarily an issue. But as a user, caching from a CDN from somewhere in the world, probably gonna be a little bit slower

Aurora: Yeah, and then there's also the other side of this where if you're building in a client side React app, everything is already client and you're used to adding loading states, but then maybe you don't think so much about how you're doing it. So even though you have something happening, it might not be the best experience for the user and it might feel jittery or,~ uh,~ weird, or the user might not even know why it feels not great to interact with your app.

Paige: So what are some of those unmanaged states that can show up between maybe the event, the render, the commit when async can come into play?

Aurora: So you're probably familiar with the React render cycle, which is like, ~um, you have, uh, ~you click something and then React will re-render the result of whatever it needed to do and then commit that to the DOM, and that's pretty simple when it's sync. But once you have async, you get these gaps in between all of [00:03:00] those parts of the render cycle, which is,~ uh,~ the unmanaged states between event render and commit, ~I guess.~

~Um, ~so this is where you typically get this janky experience

Paige: And what can go wrong when people handle these states with useEffect and useState and some of kind of the boilerplate hooks that React provides?

Aurora: ~So, ~useEffect isn't really the main problem. It's just that we don't really coordinate the asynchronous work that ~we're, ~we're lacking inside of the states that appeared now because of the async work in the render cycle. So, you have like, is loading, that's fine. ~Um, ~but if you're doing asynchronous work, you're calling,~ uh,~ APIs, maybe they would come back in a different order.

You might have race conditions, and this is where it typically is not enough to just do useEffect and useState. And,~ uh,~ we don't really have ~a, ~a built-in way in React to handle this before or before 19, but now w- with what we call async React or with what the React team calls async React, there's a way to coordinate this out of the box

Paige: Do [00:04:00] you wanna talk a little bit more about how that coordination works?

Aurora: ~Um, ~yeah. So the idea is that when you're using,~ uh,~ transitions, which were introduced,~ uh,~ first in 18, but also now in 19 for asynchronous work,~ um,~ you can wrap whatever interactions you want to coordinate in a transition and then have React handle the coordination of that automatically. ~Um, ~and this is ~kind of ~the key,~ uh,~ for coordinating basic work, but then you have additional primitives that are a part of Async React to,~ um, kind of ~fill the gaps in the render cycle.

~So, um, ~for, let's say you're clicking a button, you want typically to show something right away that could be a loading state or it could be,~ uh,~ an optimistic value. So you have,~ uh,~ use optimistic to fill that gap. And then,~ uh,~ you're probably familiar with suspense, but suspense lets you,~ uh,~ fill the gap of when you're loading the data.

And then,~ uh,~ finally,~ uh,~ they also introduced view transitions, which are not yet stable, but that's a way to animate,~ uh,~ the done state of those interactions.

Paige: Nice. [00:05:00] And so you talked a little bit about ~kind of like ~the different ways to manage it, but do the states disappearing on fast networks, like I know when I'm debugging, I can slow down my network calls to kind of get to those in between states, but does it matter on fast networks how you design for them as well?

Aurora: Yeah, so what's really cool about Async React is that because it's coordinated with transitions, it's ~kind of ~very resilient to whatever network's conditions you're on. So of course you need to think about ~the, ~the worst case, which, ~I mean, ~it's not really that bad, it's just any time you have some latency you're gonna feel it because there's like this threshold, I think like 100 milliseconds, where even if ~it's, ~it's not really that slow, but it feels delayed if your click is not responding instantly there.

So you need to,~ um,~ almost always think about this, right? But when you do have ~like ~a very quick connection,~ uh,~ it will just feel synchronous because it's all batched together and responds as if it was a sync interaction.

Paige: So you talked, you touched briefly on [00:06:00] Suspense, but how do Suspense and maybe the cache components work together within the Next.js App Router?

Aurora: So suspense and cache components is ~kind of ~two different topics where suspense is a React feature that we already had for a while,~ um,~ which I can get back to. And then cache components is a new,~ uh,~ relatively new model that we have in the app router. So some of the background of this is that in the app router, caching used to be really confusing.

So we had ~like ~the fetch cache, router cache, data cache, all of these different caches. It was ~kind of ~a meme actually. And then, so you would ~like ~build an app and then deploy it, and suddenly you don't know why things felt stale. You didn't know how to make it fresh. So what we've been trying to do is ~kind of ~reverse that to be more of the developer, the natural developer mindset, which is that it's the opposite.

It's uncached, and it's just fresh data by default. So we have this,~ uh,~ thing called cache components, which flips that default. And in cache components, nothing is cached unless [00:07:00] you define it to be cached, so it's,~ uh,~ a lot easier to work with. ~Um, ~and then you would rather opt in to caching when you need it.

So we have,~ uh,~ directives. It's-- Or it's one directive, it's use cache, and then APIs to handle,~ uh,~ revalidation and,~ uh,~ freshness,~ which, which, ~which is cache tag and cache life. So this is like ~our, ~our latest investment, and we really wanna make the app router ~a, ~a good,~ uh,~ experience. And users

Paige: actually set different cache lengths for different pieces of data within an application?

Aurora: Yeah, yeah. Any piece of any function or component, you would be able to define a cache life, how fresh it's gonna be, and then also tag it with something inside of that scope,~ uh,~ and then revalidate it, for example,~ uh,~ on an interaction. So it's a very small set of APIs. It's just-- It's a bit different if you're not used to it, of course, with anything that's new.

~Uh, ~but,~ uh, it's, ~it's a lot simpler than what we've had before, I think.

Paige: Nice.

Aurora: ~And, uh, I can actually,~ if you want me to continue a bit further on this, because that's not really the whole story. ~Um, ~because another thing we encountered when [00:08:00] we were, like, transitioning to this model is that it's really easy to make mistakes still if you're,~ uh,~ blocking some sort of the page on some data.

~Uh, ~that's also been a complaint before. So we're working on adding the developer tooling missing to make this easier and,~ uh,~ we just actually launched the 16.3 preview,~ uh,~ two weeks ago, which we have features like instant insights, which will show you where you're doing something to hurt the performance of your app, and then give you,~ like,~ very actionable patterns to fix it.

~So, uh, ~so far there's been pretty good feedback, and ~it's, ~it's really nice. So it's really,~ like,~ the missing piece to make all of this easier to learn and to reason about

Paige: So that was another thing that was tripping developers up, is that they would potentially cache things that really shouldn't have been or vice versa

Aurora: ~Uh, ~yeah. Or that, yeah, they would make the ~wrong, ~wrong choice or they just wouldn't know where they were missing something. ~So, uh, ~we have, like there's basically there's three different options. You would stream it with suspense, which I guess we didn't talk much about yet. We can back, get back to that.

But you [00:09:00] can stream a piece of data or you can cache it so that you don't have to,~ uh,~ wait for it, or you can ~like ~acknowledge that you want it to be slow, but that's like ~an, ~an opt-in basically

Paige: Got it. Do you wanna talk a little more about the streaming option?

Aurora: Yeah. So suspense is ~a, ~a React feature, right? ~Um, one second~

~Um, yeah. So Suspense is a, is a React feature~ which you can use for a bunch of different things, not only with App Router. ~Uh, ~typically people might have used it for like lazy loading things, so it has a bunch of different triggers,~ uh,~ like async server components or like the use API. And,~ uh,~ App Router is like a Suspense first transition, first framework, so we're very tightly integrated to ~this, ~this new React model.

So whenever you're loading,~ uh,~ data, you would typically use,~ uh,~ load it on the server with a server component and then use,~ uh,~ streaming server-side rendering to incrementally show more and more of the page with Suspense

Paige: ~Got it. Um, let's see. Let me get back into the notes. Oh,~ so there's something called the action props pattern. Could you talk a little bit more about what that is and how it works?

Aurora: So the action proc pattern is something that was, ~I guess, ~formalized more with,~ uh,~ as- the Async [00:10:00] React talk at React Conf last year. Because a lot of us have been seeing these features, like the transitions, the useOptimistic, and ~it, ~it hadn't really been, like, a coherent story. We didn't really know how to use them.

So that was a very important, at least for me who was, like, researching this, a very important talk to understand what was the intention behind all of it. ~So, um, ~the idea is that in React,~ uh,~ 19, you can run a function in a transition, which is what I talked about earlier, and then that would be, ~uh... ~It has,~ like,~ a terminology, which is,~ like,~ an action.

So that means that you get a lot of things under the hood,~ like, um, ~optimizations or coordinations built in. So you have the pending state, you get error handling, and then you can easily handle optimistic updates. And this goes further into ~the, ~the fact that you can expose these as properties from design components or any component library that you might be using, so that you can get this behavior built in and even have the design system define how your spinners look like, because it's a design concern.

It makes sense to have it in the [00:11:00] library. ~Um, well, ~that's,~ like, the, ~the goal at least. ~So, uh, ~it's ~a, ~a pattern that's been,~ um, kind of ~formalized and now is possible to add ~into, ~into,~ uh,~ open source libraries.

Paige: So are you seeing this being incorporated into libraries like Radix UI or Base UI or anything?

Aurora: So this is actually very interesting. I know that previously there wasn't much adoption and,~ um,~ there's a lot of reasons for that, and we're, we're-- I'm also h-hoping to contribute more to help that e- make that easier. But,~ um,~ just a f- I don't remember when, maybe last week, there was this new component library by Meta.

I don't know if you saw it, like Astrix. Did you hear about this? As- yeah. However you say that. And I was looking into it, and they actually do use this pattern, so you can,~ uh,~ use, for example, in a toggle button, you have a press change action, so that you can easily get all the benefits of Async React without building this by yourself.

So it's ~kind of ~the missing piece to ~the, ~the suspense and the transition. ~Uh, ~so you have like data loading with suspense, and then you have routing with transitions, and then you have actions in the [00:12:00] component libraries. And it requires adoption, of course. So ~it's, ~it's gonna be interesting to see how this continues to,~ um,~ to be implemented ~in, ~in libraries.

But it re- it's really cool to see that ~they're, ~they're adding this.

Paige: Yeah, and ~I mean, the, ~the Meta,~ uh,~ new framework that they just open sourced called Asterisk, it's been... They say it's been running 13,000 apps within Meta, so that seems like a pretty good indication that it's,~ uh,~ pretty battle tested. ~Uh, ~we'll see if people get onto it and want to adopt it for their own

Aurora: Yeah. I was actually like,~ uh,~ making a PR there 'cause I was like, "Hey, they're not using caching components. We should ~like ~make this better." So we made a PR and then it got merged and then now their like,~ uh,~ docs page is faster. So that's pretty cool. So we're, I guess we're kinda also collaborating a bit now with ~like, uh, ~how to u- make our, use our stuff to make,~ uh,~ their stuff better.

So that's fun when you have like real world adoption. Yeah.

Paige: Do you actually get to contribute much to the React code base or to the Meta code bases with, ~you know, ~working on Next.js?

Aurora: it was, like, very random. I was like, "Hey, what is this new framework? I wanna see [00:13:00] if I can try this." 'Cause we were really working on,~ like,~ developer tooling recently for Next.js, and I built ~a, ~a skill to,~ um,~ to automatically add,~ like,~ use cache components in your app because it's a flag, you have to,~ like,~ do some refactoring.

And I was like, "Oh, I need to try more apps with this," and it was, like,~ uh,~ the perfect case.

Paige: ~Mm-hmm.~

Aurora: ~Uh, ~so it's nice to be able to automate these processes because of course most developers want ~their, ~their,~ uh,~ migrations to be, like, easily to do now with AI.

Paige: So that skill, that sounds like something that would be useful to other developers. Are you planning to open source it or provide it somewhere that people ~can, ~can opt in?

Aurora: ~Yeah, ~yeah. It's a part of our,~ um,~ our preview. So you can use it today if you wanna try out cache components. ~Uh, ~highly recommend it. It should be ~a, ~a really good experience now,~ uh,~ at least if you tried it before and it wasn't-- you weren't super happy with it. It's,~ um,~ we're really working on the developer tooling and making it approachable for developers

Paige: It seems like skills have become the new way to do code mods for a lot of code bases

Aurora: Yeah. So it actually uses a code mod as well, so the skill [00:14:00] calls the code mod so that the AI doesn't have to... So that your agent doesn't have to,~ like,~ manually put, ~you know, ~5,500 lines of code. That would be a bit of a your token budget, I think. So ~it, it's, ~it's fun to experiment with and see how we can,~ uh, uh, ~improve,~ uh,~ developer tooling.

Paige: Are there other skills that you, that have come out of this exploration that you could talk about or that you'd like to share?

Aurora: ~Um, ~yeah, we're still figuring out,~ like,~ what's the best way to,~ uh,~ help developers use Next.js with agents. So we have ~a, ~a lot of improvements that we're working on. ~Um, ~so skills is just like one of, one of those things. And,~ um,~ definitely gonna be seeing more of that as we,~ uh,~ want to automate typically migrations or specific-- or optimizations.

We have some skills for that too, to make your app faster or,~ uh,~ the perceived loading state,~ uh,~ faster.

Paige: Cool. ~Um, ~so one question ~kind of ~going back to the transitions and animations and things like that is, how do transitions make it safe to interrupt a navigation mid-flight?

Aurora: So transitions are like a feature [00:15:00] from,~ uh,~ concurrent rendering, which has been,~ uh, in, ~in progress or been in the works for a while in React. And,~ uh,~ navigations in frameworks like Next.js are already transitions, so that means that React will do whatever,~ uh,~ work is at the transition in the background at a lower priority without really committing anything, and then keep whatever you're doing,~ uh,~ mounted.

So that if you go somewhere else, you can just throw away that in-progress work,~ um,~ and you still have ~a, ~a responsive ~and, ~and smooth page. And when you do want-- So basically, if you have a navigation and then you, let's say you click to a page, and then you change your mind, you can click to a different page, and it's not going to block you ~on, ~on whatever page you clicked first.

So it will just throw away the work. So this is like a feature of use transitions that lets you do routing,~ uh,~ in a smoother way.

Paige: Nice. And is there, in your opinion, is there a time when you should use view transitions or when it's just ~kind of ~like extra animation noise?

Aurora: ~Right. ~So let's get to view transitions. This is ~kind of ~confusing also 'cause they're [00:16:00] both called transition. But view transitions are animations, right? That,~ uh,~ React,~ uh,~ created this component built on the view transition API, which is like React,~ uh,~ a React way to make animations with this. Of course, it's using components, so it's a component that you can wrap in your, wrap around your components.

And,~ uh,~ it builds on Async React, so when you have some sort of interaction that is async, you can coordinate it with the transition and then finally add an animation at the end of that coordination. So you can think of, like in iOS, you have,~ uh,~ like a slide between pages, or you have ~like ~a morph between, let's say a photo in detail or a photo in full screen.

So these are really nice ways to add,~ um,~ meaning to your different parts of your app. ~Um, ~yeah. And the way you would,~ uh,~ do-- add this where it's ~like ~not noise, typically it's really nice if you have a suspense reveal, you can animate with a crossfade or some si- some sort of,~ um,~ effect to make that [00:17:00] smoother when your data loads in or, yeah, as I said, you can swipe between pages or even when like an item moves in a list when you're doing filtering, it's a very natural place to put animation.

So all this is very easy with view transitions.

Paige: Nice. And,~ uh,~ another thing that was ~kind of ~touched on was use optimistic and using it for handling rollbacks. So can you talk a little bit more about, about what that is? 'Cause that's a hook that people might not be as familiar with, and then ~when you would, ~when you would use it basically.

Aurora: Yeah, so ~I, ~I kinda s- sped through it earlier, but it's like ~the, ~the hook that lets you add instant feedback to your async interactions when you coordinate with Async React. So yeah, it's like th- think about a like button or you're on Twitter and then you want to like or save a tweet or,~ uh,~ you're gonna expect to click it and instantly get that feedback even though the server is not done processing that change.

So this is like the very typical,~ uh,~ place where you want,~ uh,~ optimistic feedback because you're-- it's very unlikely ~that ~[00:18:00] that is going to fail. ~so, uh ~Hold on

I was just thinking something, sorry. ~Um, ~yeah. And another really cool thing about useOptimistic is that it coordinates multiple actions. So typically if you're in React and you are clicking, ~like ~let's say you're increasing how many items are in your cart. If you click that many times, maybe there would be some race condition happening, whereas with useOptimistic and some of the other,~ uh,~ features, you can provide instant feedback on the clicks and then have that all coordinated and settle as ~like ~one update in the end.

~Uh, ~and oh yeah, for the rollback feature. So it's a bit different than what you might be used to with something like a React query if you have the optimistic queries there, where you basically store a copy and then you put it back. Whereas with useOptimistic, it's just like a temporary state that you,~ uh,~ c- that you keep for a certain time until or while the as- async work is happening, like inside your transition, how long that is running, and then it will just get rid of that afterwards.

So whatever you're left with after [00:19:00] that fake, you could say, UI, is like the true state, right? So it ~doesn't, ~doesn't have to-- You don't have to roll back anything. It's just like settling into,~ uh,~ what's the result ~of the, ~of the interaction.

Paige: Are there any,~ um,~ opti- or,~ like,~ anywhere where you would not wanna use this type of optimistic update?

Aurora: Yeah, so at least with something like useOptimistic, it's a hook, it's like ~a, ~a localized component thing. It's not a global, ~um... ~It's a bit different from maybe React Query in that sense. ~Um, ~so anywhere where you have ~an, an, ~an action that is most likely to succeed, you can throw it in there. ~Um, ~but if you're doing like an irreversible delete or you're navigating away from something, it's really hard for you to roll back to that state, right?

~So, uh, ~if you, if basically, if it's something that's likely to succeed and it's not,~ um,~ destructive, yeah

Paige: Yeah. Got it. ~Uh, ~so another thing that you talked about in your talk was,~ um,~ routing background updates through transitions and how that makes things like polling features feel free. Can you talk a little bit more about what you [00:20:00] mean?

Aurora: Yeah. So when I did this demo at React Miami, I just wanted to showcase,~ like,~ some cool animations and,~ uh,~ background updates. And what's nice is if you're using transitions and you have the router, you can just,~ like,~ call a refresh in a transition and have that happen in the background,~ uh,~ in a, ~in an, ~in an interval.

So it's a really... It's, ~I don't, ~I don't... wouldn't s- say it's a hack, but it's a very simple way to just get this background update if somebody else is manipulating the same UI. And it looks really nice with animations because if you have a view transition around those items and then ~they, ~they,~ like,~ appear,~ uh,~ animated, it feels really alive even though ~it's, ~it's very simple code, right?

It's just,~ like,~ checking if there's something new. ~Um, ~but in ~real, ~real apps when you're doing something like s- that's really real time, probably ~you, ~you wouldn't use that. You would probably do,~ like,~ a client fetching thing or a data library like React Query or SWR ~to, ~to actually have it like a proper live or WebSockets even

Paige: Yeah. ~Um, ~one thing that you said was that teams th- should think about perceived performance versus actual measured performance, [00:21:00] so INP versus CLS. What do you mean ~when you, ~when you describe that?

Aurora: ~So, um, ~when we're, like, designing in-between states, ~I suppose, ~like we've been talking about here, that makes the app feel faster for your user,~ um,~ because you're giving them this low-class feedback. ~You're, ~you're making it responsive. But a lot of the time that is also improving your actual performance, right?

~Um, ~so typically Core Web Vitals, you said,~ uh,~ INP, responsiveness, you would be improving that. And,~ um, for, ~for the Largest Contentful Paint, if you're using streaming,~ uh,~ with Suspense, you might get a bigger, a better LCP also, because you can reveal parts of the UI as they become ready. But of course- ~Mm ~... if you are doing streaming, you also have to think about CLS or cumulative layout shift, because I f- for sure a lot of people have,~ like,~ gone to an app and then it just feels awful.

You're not sure where to click because things are, like, jumping around, or you're clicking a button- ~Mm ~... and then it moves, and then you click the wrong thing. It's just the absolute worst, right? ~So, uh, ~if you're doing any sort of loading state, even in a SPA without Suspense, you still have to think about,~ uh,~ [00:22:00] how do you design your loading state to avoid cumulative layout shift.

Paige: Yeah. And these patterns ~and, ~and things that you're recommending people keep in mind, do they work outside of Next.js?

Aurora: Oh yeah. ~Uh, ~so these are like React features. ~Um, ~but we do integrate with them very tightly in Next.js because we believe in React's model. We want ~to, ~to work the way-- ~like, ~to go in the direction that they're going. ~Um, ~but you need a router that runs navigations through transitions, and then you need a data layer that works with suspense, which a lot of frameworks are doing.

~Um ~Yeah, and Next.js kind of leans all the way into this, as I mentioned earlier. So you could-- There's also other ways to solve these same problems, of course, but ~that's, ~that's the way we have decided to go, where we're, like, following this declarative model of React. ~Um, ~another thing that I ~kind of ~forgot earlier was maybe about the actual performance of server or,~ like,~ running on the server instead of on the client.

So when you're using Suspense and you can stream, you get to keep your data fetching on the server, right? So you [00:23:00] can-- ~Well, ~you can ship less, less JavaScript, but it is also a lot faster to fetch on the server. And there's been some really interesting benchmarks around this, which was, like, I think it was ~a, ~a throttled app by Nadia Makarevich.

She's done some really nice benchmarking where I think here, based on what I've been reading, it was like,~ uh,~ four times faster actual performance when you load on the server and then you stream it. And what's nice is that you get to keep this declarative,~ uh,~ localized React model where you can fetch data inside your component while still getting the s- speed.

~Uh, ~yeah, and you get to also integrate with Suspense so that you can make nice loading states that are not causing CLS and have a intention behind them.

Paige: So do you think ~that ~that's ~kind of ~where the industry is headed at this point, is more server side when possible, but client side just when it, in, in, in specific instances, ~I guess?~

Aurora: ~Well, ~it's a really hard question because, ~I mean, ~we used to be, we used to be building apps on the server and then for ~like ~[00:24:00] 10 years we did spas because they feel nicer to use, they're fast, they're interactive, and people like them, and that's fine. But I don't think that should stop us from innovating and,~ like,~ trying to make what's better 'cause it's a bit boring if you're like, "Oh, this is fine.

We'll just keep doing this forever," when there might be a better way. You just have to find the right balance first. So ~I mean, ~it's already-- A lot of frameworks ~do ~do this with,~ like,~ loaders and,~ uh,~ server components is one way that,~ uh,~ gets you more benefits of the server. ~So, uh, ~yeah, it's a very interesting shift, I think, and,~ um,~ we should keep on innovating here.

Paige: So what is still missing from Async React, do you think, before it becomes ~kind of ~the default way that people will build React apps?

Aurora: ~Well, ~I think a lot of what's been missing recently that I just touched on is,~ like,~ documentation because it's been... And maybe education, ~I guess, ~because it's been a lot of hooks that you've seen maybe in the React docs in the API reference, but that's kinda hard to understand how to use it in your app.

And that's been a lot of my goal [00:25:00] too, to just help people learn how to use this stuff. ~Um, ~so hopefully,~ uh,~ I'll get to contribute more ~to, ~to this. And there's this Async React working group, which anybody can help contribute to this,~ um,~ this movement of,~ like,~ getting Async React more,~ uh,~ educated and into apps.

And it's really nice to see As- Astrix doing the,~ uh,~ action props pattern as,~ like,~ the first real library to showcase that ~this is, ~this is possible. So yeah, I g- it's more about slowly implementing it and teaching it and making sure the docs are there.

Paige: So if people are interested in getting more into this, what kind of things would you recommend for them? Like documentation to go check out or videos, or where can they learn more, ~I guess?~

Aurora: ~Well, ~I would first just recommend,~ um, kind of ~like realizing that there are more things to learn. Because React is really great and it works perfectly the way it already is, but it's also ~a, ~a good idea to kinda research what's next and watch the new talks and,~ like,~ check out the Async React from React [00:26:00] Conf, and maybe try the hooks and,~ uh,~ hopefully just s- stay up to date on ~what's, ~what's been, what's happening.

~Uh, ~yeah, it's very exciting. It's exciting when we are working ~in a, ~in a framework where it's still innovating. We shouldn't take that for granted.

Paige: No, and ~I mean, ~it's, it seems like it might even start innovating faster now that it's become part of the React Foundation and is out from under Meta, just Meta by itself.

Aurora: Yeah, I don't know,~ uh,~ much about that, but,~ um, I'm, ~I'm very excited to, to help make it better

Paige: ~Well, it's, ~it's been great talking to you, Aurora. Is there anything that we haven't touched on that you want to make sure people or listeners are aware of or when it comes to Async React ~and, ~and everything that we've just talked about a little bit?

Aurora: ~Um, well, ~I'd love for everybody here to just,~ uh,~ check out what we've been doing recently in Next.js because we are really working hard on making it,~ uh,~ better for everyone. ~So, ~and,~ uh,~ hear your feedback so we have some discussions on that. That would be great. And,~ uh,~ improve it before the release

Paige: Awesome. ~Well, ~if people wanna get in touch with you or find out more about React and Next.js and what's coming down the pipe, what are the best [00:27:00] places to,~ uh,~ find you online?

Aurora: I'm very active ~on, ~on X. You can follow me there. And I'll, I also respond on LinkedIn, but maybe a bit slower. ~Um, ~yeah, I think that's ~my, ~my most active... And I have a blog, but that's like ~for, ~for seeing what I share. But if you wanna talk to me, I'll,~ uh,~ I'll be on X.

Paige: Awesome. ~Well, ~thank you so much for joining us. It's been great talking with you today

Aurora: Thank you. Thank you very much