Working fluently with Data in React

Hi.

Now that the awkwardness has passed, my name's Tejas, that's pronounced, I used to say it was pronounced like contagious before the pandemic, didn't go so well for me.

So now I say advantageous, whether or not.

this talk is advantageous to you.

We'll find out at the end.

Let me know.

@ me on Twitter or whatever it is you do.

Mastodon, I don't, use that, but, I actually won't, I have opinions about this.

I love Twitter.

Anyway.

I used to work at a company, as an employee, but, now I'm just an independent YouTube content creator.

So I do this now.

I'm trying it out.

If it's worth it, you let me know by, subscribing or letting me know, but that's not what, we're not here to talk about me.

Listen, this is not the Tejas show.

Okay.

Today we're here to talk about handling data at scale for React developers or alternative title working fluently with data and React.

I didn't do the second title because I'm actually writing a book called Fluent React that's coming out soon.

don't buy it.

I don't know.

Whatever you want.

but this is about data specifically and I'm really thankful for the last speaker.

Thank you, for setting the stage with data fetching, how remix, how next, how hydrogen, how these frameworks do it.

We'll look at that, we'll look at what they do under the hood fundamentally, and why you shouldn't do it yourself.

thank you again.

I appreciate that.

but first, let's, draw a diagram.

To understand and appreciate the complexity that goes into working with data at scale.

Okay?

I'm gonna switch over here to the, computer.

Oh look, it's keynote now.

You see all my slides, spoilers.

I'm gonna go to my browser and open TL draw.

How many of you have heard of used TL Draw?

Wow.

Nobody.

It's great.

it's a great diagram tool.

I like it.

Excalidraw, have you heard of used X?

Yes.

Way more people.

Okay.

I root for the underdog.

So let's go for TLdraw.

and let's, let's pretend we have.

We're, doing data, okay, in a React app.

So we usually have some type of, UI that is a user interface, talks to some type of API, and eventually, talks to the data storage, db, let's just call it db.

And so your front end could be called the UI, talks to an API, which probably some other team is gonna maintain and the database.

That is like the most simplified representation of data, of a data layer with the React app, the API piece anyway.

but is it actually this in practice?

No.

the complexity grows, right?

You usually, you'd have multiple API servers just so you don't have a single point of failure.

You can load balance between them, et cetera.

Okay, so we're getting a little bit more complex.

what's the database story?

So databases, at scale have been a hard problem because there's multiple ways you can do it.

You can scale vertically.

That is by adding a lot of resources and memory and disc space.

So you scale like this, but at some point you have a very beefy database Server.

And really you shouldn't even have one machine anyway, because it's a single point of failure.

So what's the alternative?

You scale horizontally.

So now you have multiple Database replicas and maybe one, or a few primary instances at scale.

Cool.

is this data infrastructure, is this data still representative of like large enterprise or tech companies at scale?

would Uber have something like this?

No, it's more complex.

Databases usually, run into performance problems and you want to make things fast.

How, do you do that?

It's typically slower to read from what than from what?

Typically slower to read from disk than from memory and databases traditionally, and even today, like, Postgres, MySQL, whatever, their storage engines usually end up storing on disk.

And so reading from random access memory, it's optimized for random access.

So reading from RAM is gonna be faster.

So what you'll do then at scale is you'll add some type of, some type.

Can I enter text in here?

Some type of in-memory cache, and this will be distributed as well.

So now you've got more complexity.

You've got to have your API when it receives a request, check this, do you have the data for me?

Fast?

Good.

Get it.

If not, get it from the database.

Okay.

But there's more like this is an inf, this is a, honestly, it seems like infinite complexity because once you accumulate a ton of data volume, you have a lot of data, what do you eventually need?

Think about it like TikTok, Instagram, Google, Facebook, Twitter, mastodon.

with enough data, what do you usually ... you need search.

You need some way to, to find stuff.

Okay, so now we need a search engine.

We need like Algolia, we need elastic search.

We need something like this search engine.

And that's going to be distributed as well.

It's gonna be optimized for quick reads and writes.

So something probably, schemaless.

And so now your API has got to talk to this thing, but your, database, your main data store has got to replicate itself into the search engine.

So now you're talking about some type of replication story with some type of queuing system.

Wait, let's, go.

Q, I can spell some queuing system.

And look at, and this queue is probably also gonna be distributed with workers there.

so if we talk about data at scale, if we talk about data infrastructure at scale, this is usually what the backend systems will look like.

But this is one instance of them.

There's multiple instances of this in multiple different regions and availability zones across the world in multiple clouds, usually if you're at scale.

Okay.

and what I, why did I draw this?

What I want you to notice here is that I find personally very interesting is the backend complexity, the data infrastructure, the data complexity has grown significantly.

But where is the UI?

Yeah, the, UI is the ui, it's a React app.

It's a next JS app.

It's a remix app.

are we considering the APIs we're talking to, are we considering caching?

Are we considering static generation?

Are we considering how we're fetching our data?

So this is the React track of this six track conference.

And honestly, I could give this stock at the backend track and focus heavily on like, how do we deal with this one specific database replication story.

But since this is the first, front end track, We're actually not gonna talk about any of this backend stuff and just literally zero in here.

Okay?

How do we talk to these systems in React in a performant way that provides excellent developer and user experience for our people?

Okay.

Does that sound good?

That was the intro.

I hope your appetite is whet and if it is not, there's the door.

Okay.

Anyway, um, I wanna highlight for you three ways to fetch data in React, and that's literally only because we have 40 minutes.

I could do this all day on under set your time.

Three ways of fetching data in React.

Number one is, render then fetch.

This is what we do often.

This is what.

If you like, get into a React app.

If you make a new React app with Create React app, this is where you're gonna start.

have y'all done?

How many of you render and then you've, yeah.

Okay.

Two of you.

And now more of you woke up.

Welcome to the talk.

so how this works is you have a component useState, and you'll have useEffect you fetch.

And when the promise resolves, you set state.

The, this is the most common way to fetch data on React on the Web.

I'm not sure that it's the best.

because you have to wait for the rendering work of your component to be done before you start fetching and rendering work can take time.

So really what you're doing is leading to performance waterfalls and things get slow.

And as we know, slow things are not good things.

Okay?

they never have been, unless it's like growth.

Slow and steady growth actually may be good.

but on the Web like network stuff, not the best.

Number two, another option is to fetch, then render.

How many of you do this?

this, I, yeah.

Jed.

One.

One and, you.

What's your name?

Sam.

Sam.

And you, what's your name?

Ben.

Ben, Nathan.

David.

Nathan.

Nathan, Lord.

Okay.

okay, three of you in this room, fetch then render.

The benefit of this is you start fetching early.

So before React does the work of rendering your component right.

you just fire off a fetch request.

Start that promise.

Network's busy.

CPU's busy.

When network finishes.

Then user setState, so you, because you're fetching early time to actually getting an app, getting a component with data is quicker.

Big benefits, pitfalls here.

We'll talk about that.

Mainly if, you're, fetching, stateful, things on a Server rendered application.

Shared state on a Server is just never a good thing because one Server services multiple clients and it's easy to get wrong.

Number three, this is the premier way in React 18 onwards to work with data fluently in React.

Render as you fetch.

So like CPU's doing work.

Meanwhile, interleaved with the work of rendering, you're also fetching and React 18 exports and supports new primitives that make this possible.

In fact, that's what powers next js.

That's what Powers remix, that's what powers hydrogen and all of these cool meta frameworks we're starting to see.

Okay, so, render as you fetch.

that's cool, but let's code this.

Let's make it a little bit more practical.

And what I'll do is, we'll, build these first two rendering modes of render then fetch, then render, and then we'll look at render as you fetch.

Okay?

that's one of the few slides I have, like just, eight more slides because we're just gonna be coding.

let's go here.

I made an app called The Jokes.

It's an app of jokes, developer jokes.

Lord knows we need to laugh a bit.

now that the pandemic's kind of settling down, I'm not calling it over.

cuz I, I tried that once and then it came back.

so this app, it's called The Jokes, it's a curated list of jokes by Sruthi Kapur, one of the titans of the React industry.

I can recommend giving her a follow.

she curates jokes.

her content is phenomenal.

what you can see here though, is that there's no jokes here.

because they live in a database and we're not fetching data yet.

In fact, if we walk through the code, Um, this is very zoomed in if we walk through the code, standard React app.

So we're importing React, creating a route, and putting our app in there.

It's, this is what you'd get with a new React app.

we're not Server rendering, we're client rendering here.

and in the, he told me not to roll my own Server renders.

I'm not doing that yet.

we go to apps and we support a search.

As we can see here, there's a little search field.

But we're not actually getting any data.

This is just markup.

In fact, if we bring this beside this, what we'll see is H one.

The jokes is there, the input is there, the P is here, and then there's a jokes component that isn't really doing its job.

Let's take a look at the jokes component.

alright, so here we have, we're mapping over something.

But we're never calling set jokes cuz we're not doing a network request.

So let's do that.

Welcome to the talk everybody.

I'm not shaming you for being late.

Come on.

I wouldn't do that.

so these jokes live in a database.

where's the database?

The database is on, my former employer's application.

This is not an like advertisement for it.

I just used to use it a lot for work.

this is Xata.

it's a database platform and I have a database here of dev jokes and in this I have multiple developer jokes.

So when this loads just, tons and tons of jokes sourced from Shruti's repo.

What I'm gonna do is I'm gonna query this database.

I'm gonna get code snippet here and, this looks cool, so I'll just copy.

do they have type script fetch?

They don't.

okay.

That's why I quit.

I'm just kidding.

I'm just kidding.

and so what I'm gonna do is I'm gonna fetch data.

So we'll useEffect.

This is, classic, fetch, then render or render, then fetch rather.

And we'll add nothing to the dependency array and we'll just paste that fetch.

And instead of console logging the response, I will set jokes to response records.

And this should give me what I want, except there's an API key missing.

So I'll just go add one quickly.

Boom.

and I have this, I don't mind sharing this API key with you because it's gonna expire probably.

And if it doesn't enjoy the jokes, save.

And so now we go back to the jokes app.

There we go.

And cool.

We have jokes.

What is the most used language in programming?

Profanity.

That's awesome.

I love it.

why don't keyboard's sleep?

Because they have two shifts.

I, okay.

Anyway, our search doesn't work though, so let's, fix that.

And, really what we're doing is keep in mind we're rendering the component, then we're fetching.

Okay.

we'll just add a quick little filter here.

So we'll say, do we, have search?

And if we do, we'll send different parameters.

We'll send, um, we'll send something that says, filter.

Joke, that's two two colons joke contains search.

I think this should be fine.

I'm missing a curly, I suspect here.

That was right.

Excellent.

And of course we'll run this effect every time the search changes.

do I feel confident in this?

Absolutely not.

Let's try it.

oh, it does work.

Married life of a developer wife, right: 100%.

Okay.

Cool.

So this totally works.

I dig it.

But here's the problem, like, the previous doc mentioned, there is not gonna be SEO here at all.

And I'm client rendering, I'm fetching after the component renders.

It's good, but it's not as good as it can be.

how many of you have done this pattern in React before?

Client render?

Just, know, useState usEffect.

Nobody, or you're not paying attention door's right there, I'm telling you.

let's see how we can improve this by fetching then rendering.

And to do that, what we're gonna do is literally just like copy all of this up to the promise resolution outside the scope of the component.

So all of the, keep in mind this is happening, we start fetching in useEffect.

But what if we start fetching outside the component in module scope?

So then when it's imported, if you code split or when your bundle is pulled down immediately, you just fetch outside.

So we'll do something like const promise we fetch here.

and then we'll just do promise dot then and useEffect.

Make sense?

So we're just like fetching earlier.

of course here we don't have things, we don't have access to search because we're outside the state, we're outside the closure.

we'll need to improvise that by actually just commenting search out for now.

let's, The point I'm trying to make is not about search, so it's totally fine.

we'll do promise equals, okay.

Excellent.

So now notice we still have the data, arguably marginally faster because we start fetching early.

The problem is it's still client rendered, on a Server rendered app again, you may run into state problems, et cetera, but these are the two approaches it has been shown with, large payloads that fetching early, helps a lot, although with 15 jokes.

Maybe not.

I'm okay with that.

But now let's pivot.

how am I doing for time?

Am I good?

Yeah.

Excellent.

he's you could do this all day.

Thank you.

I will.

let's, look at the new premier data fetching style in React.

but before we do that, I mean we, we talked about render, then fetch, talked about fetch, then render.

This is the hotness.

Okay.

This is The way, this is the way frameworks do it.

This is the way if you're, if you like pain and rolling your own.

Sure.

but a disclaimer.

You see the React team is very explicit about things.

if you look at their re React 18 release thing, blog post, they have a heading here that talks about this, that talks about, Using Data fe suspense and data framework.

So in React 18, it's production ready.

It's not beta.

You can use suspense for data fetching, which facilitates render as you fetch.

but look, they say it's, you can start using it in frameworks like Relay Next Hydrogen or Remix.

Anyone use Relay here?

Wow, really?

I didn't think people used this.

Okay, cool.

relay, Next js, hydrogen, remix, but look what they say.

Ad hoc was technically possible.

But still not recommended as a strategy.

Okay?

So I'm about to do exactly that, just to demo to you and show you what the frameworks are doing under the hood so that you understand, you learn, you take something away that benefits your career and your understanding.

Okay?

that's the intention is education.

But I'm not saying go do this yourself, but if you did want to build a framework, This will help you do that.

And if you just wanna understand, React better.

Okay, so I, should change the slide.

It's, yes, let's code, but also this is just a massive hacking session where we learn, what React does, what frameworks do under the hood.

Okay.

So let's jump into our jokes app.

Hopefully my token hasn't expired.

Is this working?

Yes.

Excellent.

So render as you fetch.

To do that, to use suspense for data fetching, we use a newer primitive in React called a suspender because suspenders suspend.

And then you can use suspense with suspenders that suspend using suspense boundaries.

Suspense is the buzzword.

Okay.

so how do we create a suspender?

let's write a function.

Let's just call it createSuspender.

Okay.

And what createSuspender is gonna do is gonna take a function that accepts as an input parameter, something that returns a promise.

Okay?

I'm a fan, by the way of naming your stuff like that, because then your team can read it and it's explicit, oh look.

Also, GitHub co-pilot can read it.

Thanks.

and so how does a suspender work?

I'm afraid co-pilot might spoil my amazing like live coding session cuz it has done this in the past.

we'll see what co-pilot does.

Hopefully it doesn't like spoiler you.

what is it?

Oh damn it.

Co-pilot.

Why?

Hi.

Fine.

We can just walk through.

I was gonna impress you with my awesome typing and anyway, whatever.

So let's I press tab.

GitHub serious.

Anyway, what's happening here?

we have, some flags.

We have the status off the suspender and it starts in a pending state cuz like it hasn't done anything.

And the result where we store, whatever happens when the promise resolves.

The suspender itself calls the promise and immediately sets state when the promise either resolves or rejects.

So when it resolves, you just set your flags, it succeeded.

The result is R, if you've error, you set the status to error and the result is the error.

Okay?

That's what it does.

It just it.

It waits for the promise to resolve and then sets things, but we're not using a weight here.

This is important for you to know.

This fires off immediately and this fires off later.

So this function, because React doesn't support asynchronous hooks, asynchronous internal stuff, this function cannot return a promise.

That's fundamentally important.

Well then what does it return.

It returns an object with a read function that switches on the status.

Okay.

If the status is pending, this was controversial.

If the status is pending, uh, React takes the suspender and just throws it.

Isn't that so people lost their.

I don't wanna swear, but you know what I'm saying.

They lost their stuff about this earlier because they're like, how could you do that in JavaScript?

You should just throw errors because we're programmers who do things by the book.

And React was dude, you can throw whatever you want.

I could, throw myself at JavaScript.

In fact I do.

It's called a career, but they, so we just let's just throw the suspender.

Okay?

but if it's an error, then we throw the result.

And if it's actually a promise is finished and the data is available, we return.

There's, this is what a suspender looks like, so let's use this.

Now we have a suspender and it takes something that returns a promise.

I know what returns a promise.

Let's, create a resource.

Let's call a function called createJokeResource.

Okay.

And we'll just have it call createSuspender and it.

Wow.

Awesome.

and we'll take our fetch from earlier here.

This one, and we'll just put it down there.

In here.

Excellent.

So we're just moving things around.

Nothing big is happening.

It needs to return a promise.

So we'll just return promise.

Okay.

So now we've created this thing and we've given it this function that returns this promise.

we can also add search now, by the way, so we can in our, createJokeResource.

We can add search as an optional parameter, and we will uncomment this now.

Look, we have a function, so we have state it's phenomenal.

this looks excellent.

Now how do we, how does this change our React component code?

For starters, we don't need useState anymore.

Hallelujah.

there's a great talk by my friend David Khourshid.

some of you know may know of him as David K Piano.

He has a talk called Goodbye useEffect.

yes.

Amen.

so what do we do instead?

we, you, we will create a joke resource, but in module scope.

So we'll say initialJokeResource and we'll do this and we'll just use that.

So we'll do, initialJokeResource.read.

That's it.

that is way simpler cuz we've moved the complexity outside the component.

Okay.

Save this, please don't let my token expire now.

That would be okay.

thanks.

I will go grab a new token.

You know what, let's just go get an, API key instead.

let's do it.

So add a key Web directions.

Excellent.

This will never expire, and go find wherever.

I'm hard coding that.

Don't do this in production.

Really.

This is just a hacking session.

Wow, that's nice and smaller.

Awesome.

So now let's go back to the jokes app.

Reload.

Okay.

I still have, wait, I think I know what the problem is.

I am not get returning dot records.

Exactly.

So dot then, uh, response.

Look, this covers my, like text.

It's very inconvenient.

Response dot records.

That's what I want.

Records save.

Now this should work.

There we go.

Excellent.

so we are now rendering, and while rendering is happening, we're fetching and they're both interleaved.

And as a result, check this out.

As a result, there's no, flash of content.

It's either already.

Or none of it's ready.

Okay.

And because I'm doing this using a suspense boundary, I can selectively choose which parts of my user interface I want to show.

Do I want to deliver the entire UI with jokes at once?

Do I wanna deliver?

Let's a, let's just play, man.

I'm, I don't want to talk.

Let's, code.

So if we go to now our containing app, we have the jokes component.

What we can do is we wrap a suspense boundary around this thing.

Okay?

Save.

And now if we reload, just the jokes don't show up because that's the suspense boundary.

When React throws that promise, where does it throw it?

The suspense boundary catches it and stops rendering underneath until the promise resolves.

And then it continues.

Does that make sense?

Excellent.

It's like a try-catch, but with promises.

what if we want to hide the paragraph, instead?

So now look at that.

The paragraph goes away.

We could even hide.

Here's a question for you.

Should, the search field be visible if there are no jokes?

Yes or no?

Yes.

Why?

Because what's the point of typing something if there's nothing to filter on?

Excellent.

that, yes, but then we'd have to cancel the initial request.

And then do a f a filtered request.

Absolutely.

I've asked this question before, and the room has been mixed.

There's been mixed opinions about this, because some would say yes.

Anyone say no to that?

I'm just curious.

you okay?

Yeah, you as well.

Some would say no because you're like, they don't know what to expect.

And then what sense does it make to tie?

So it's been mixed.

So let's say we want to hide the, input.

We just save, reload, no input.

We bring the suspense boundary lower, we save, reload, we have it.

So using the suspense boundaries and render as you fetch React can literally just stop where you want it to stop.

Fetch data continue.

massive implications of this because how many of you have been hurt by layout shift?

Yeah.

You, go to click a, you go to click a dismiss button, but then, oh, buy, now.

And then it's oh, I've lost $50.

Sneaky.

you can prevent Cumulative Layout Shift.

You can have applications that behave in, what you decide to be amazing user experience.

And that's the point, like facebook.com used to have a bunch of stuff flying in and now, React being a Facebook property if you've used it lately, it's not shifty.

It's pretty nice.

that's the whole intent behind suspense, by the way.

excellent.

So we're not done yet because I can't search for my favorite joke.

search doesn't work.

Thankfully, when we create our resource, we are accepting a parameter.

So if I go back here, createJokeResource does take an argument, so we just have to use it now.

the initial resource has no state.

It's fine.

We can make this in module scope, whatever.

How we do this have it respond to the search property, is we recreate the resource every time search changes.

Okay, so let's go here and we'll do const, oh gosh.

Co-pilot, really.

this is wrong though.

so what we'll do is we'll useState and we'll, we'll pass in the initial joke resource first, but then as search changes, so we're back to useState, useEffect.

when the search changes, we'll just recreate it.

So we'll, um, setJokeResource, right?

setJokeResource.

So we'll set joke resource two, and we'll just create another one with search this time.

And then we'll of course replace this with the actual joke resource.

This make sense?

So good.

save.

So now we're gonna recreate that resource.

Of course, there's nothing, with, Peg would be funny if there was a joke with that.

but no, this seems to work now.

And look at that.

It's pretty, snappy.

the problem is it does go away.

And it would be cool if look, that's, that would be really annoying if, we went with the hide input field when data is loading something like this.

watch this Amazing user experience.

Okay, ready?

Wait, let's reload.

This is, prima, so ready.

Oh my God.

One keystroke.

That's the, ah, this nasty.

and some would say if the search field was there, cool.

at least then the search field isn't going away.

Let's, let's, I'll humor you.

let's move the suspense boundary once again.

And now, okay, but I'm typing and I still this flash, yuck.

Are you with me?

I don't Nasty.

Nasty, nasty.

And the reason it's nasty is because the reason this specifically is nasty is because my text input is a much higher priority update than whatever data fetching is needed.

Okay?

When I type that input needs to be what I wanted as a user, right?

Text input is like highest priority.

You do not block text input, you do not interrupt text.

It's like golden rule of ui.

Okay?

how can we tell React to prioritize text input and deprioritize recreating this resource and data fetching.

How can we give React Priority hints?

useThrottle.

thankfully the wifi is slow enough that you see the, flicker that I don't need to, no, that, that's good though.

But using throttle will, yes, it'll defer the network requests, but the flashes will stay the same because we'll do requests per, we could then cancel the request and only do the latest one.

still not ideal because, but then we start fetching after keystrokes have finished for a while.

there is a way using another newer React primitive.

I have five minutes left so I could really draw this out cause it's the end of my presentation.

but I will not do that.

I know you would love that.

I see some of you going do it, anyway.

Yeah.

Who said that?

Use it.

Nice.

yeah, so the, internal primitive, the, new one is useTransition.

Exactly.

so what we'll do is we'll do a function called, I don't know, whatever useTransition.

And useTransition returns you two things.

It returns a function called, really, a function called startTransition.

And this just says do this when you can.

not, so important.

And the second property isTransitioning.

we're not gonna use isTransitioning really.

but we will use, startTransition.

So instead of immediately setting the state causing a re-render, we will start transition and then we'll wrap this in a function.

And, that's it.

What, do you want, boolean?

Oh, it's is, it isTransitioning.

And start tra… Sorry I'm teaching you wrong stuff.

there we go.

It's happy type script y'all.

Amazing.

Okay, so now we're telling, React, recreate the thing, do the fetch, but later, okay, let's take a look at how that, works.

So now in the initial load, yes, there's some shift, but now look at this.

I can type anything I want.

and it doesn't go away.

It notice on the initial load, my, my text input is not available.

But once it's loaded, It never, ever goes away because the fetching and everything is, a secondary subject.

And when it, when the promise resolves, I get my stuff.

phenomenal stuff.

this feels much better, yes?

We can, do even better with a, fallback.

so we can s we could add a fallback prop saying, Stuff is loading.

Ideally here you would put a skeleton UI so the user can orient themselves with what's coming.

I'm lazy.

And so now you can say stuff is loading and, play.

And this user experience has gone from okay to good to great.

Yes.

Excellent.

let's wrap up.

Let's talk about what we've learned.

We've learned about what is hap.

We've learned about three of the ways to fetch React going from how we used to do it, to how we started doing it by fetching early with fetch, then render.

And finally the, modern, the today, the way of doing it, rendering and fetching in an interleaved way.

So that why, do we do all of this so?

That our users have the best possible experience on the Web that they can.

and that's really the motivation.

That's my motivation of giving you this talk.

I hate using the Web sometimes.

Seriously.

Like I go on, like I don't wanna name websites, but I go on some website and, there's layout shift.

It takes too long to load data fetching.

I have to wait for something to render.

Even something as simple as twitter.com.

Client rendered.

So I just, I opened the page.

There's three, four spinners at the time.

no.

And so the motivation behind all of this is how we can work fluently with data and React to provide the best experience to our users that we can.

How do we use this stuff?

are you expected now to go home and write suspenders and build your own next js?

no.

But now you know where the blocking happens at the IO CPU boundary and how you can, if you need to optimize for interleaving network and CPU for the benefit of your users.

It's just really head knowledge that will at some point come in handy.

But more than anything, it's an understanding that, that you don't really, you don't realize you need it, but then you're thankful it's there when you do.

with that, I wanna say thank you so much for having me.

This has been really a lot of fun, Web Directions Summit.

I really appreciate it.

before, before I go, I do have one more thing, to say.

There's nothing really big.

I just, I want to, set up the next speaker.

good friend of mine, Mark Dalgleish, when he comes on stage.

This is his first talk since the beginning of the pandemic.

Okay.

so I'm gonna need you to like, give him some real support.

Anyway, with that, hey, thank you so much for having me.

it's been an absolute pleasure.