Promise Flow Control, Concurrency, Libraries, TypeScript and Deferreds - Part 3

Oh, welcome to Syntex. On this Monday, hasty treat, we're gonna be hitting you with part 3 of 3 in our series on promises. We're gonna be talking about some new stuff, like, with resolvers.

We're gonna be talking about, you know, practical stuff with fetch. We're gonna be talking about flow control, concurrency, throttling, queues, all of those types of things. Basically, we got the basics. We got the intermediate kind of syntax stuff.

Now here's what we want. We wanna learn how to get even deeper with this. And if you're getting deeper into any type of new topic or code, you're gonna make mistakes. You're gonna cause bugs. Potentially, you're going to end up, with some performance issues as well. And to track all of that stuff and make sure that you have a handle on it, you're gonna want to use century@century.i0.

That's Wes e n t r y Scott I o forward slash syntax.

Sign up and get 2 months for free. And, seriously, just, just give it a rip because once you get used to those dashboards and once you get used to those dashboards in your your project, in your application, it's really hard to live without that visibility and to just kind of be flying blind on what your users are actually hitting in your site. So let's get on into it. I have deferred the starting of this episode long enough. We're gonna be talking about the first thing, deferred promises.

In talking about with resolvers, which is newly available. So, Wes, do you wanna I I've not used with resolvers. I'm super interested in what this is and and how to use it.

Yeah. So previously, if you wanted to access a promise and its resolve and reject methods outside of the promise body, what you've had to do is you had to create a variable outside of the scope of that promise. And then when you get inside of it, you have to update the variable that's outside.

That works really well. That whole pattern is called a deferred, and that's something we've had since jQuery had deferred for a while.

Or it still does. And it's it's not a new concept in in programming, but it's not something we've had in JavaScript. And there's lots of libraries out there that were just made for simply making a deferred.

And let's talk about, like like, why might you want that? I've talked about this on the podcast before JS if you want to instead of having to pass your work into a promise Mhmm. So often when you're you're doing a bunch of stuff, what you'll do is you'll make a function, you'll return a new promise, and then all of the work needs to happen inside of that. And sometimes it makes a little bit more sense to instead of passing your work into the promise, you want to pass the promise itself along with its controls, its resolve and reject methods.

You wanna return that from a function so that you can wire it up to buttons. You may wanna pass it to a success callback of another API and promise that with the resolvers will will do that for you. It it Scott of surfaces the resolver and check methods alongside the actual promise.

Where this is is really useful is in streams. If you want to be able to with streams, the way that it works is that you you get a stream, you listen for what's called chunks. I know, Scott, you're working with the get user the webcam API right now to stream in video chunks. Is that what it is? Yeah. Yeah. And I'm sending them to over HTTP to a Wes,

process, which is then collecting them all in a temp file.

And then once the process is overriding that temp file to a video file with FFmpeg.

So, yeah, currently doing that. That's that's really cool because with in the browser with media recorder, the way that it works is that you you create a media recorder, you listen for chunks, which is basically every I don't know. You can Sanity how many seconds, but imagine it was 3 seconds of video. You get a chunk every 3 seconds. And then the way that it works is you you put those chunks into an array, and then you wait for it to be finished. And then when it's finished, you take all those chunks and you put them together and you get a a video file at the other end. Right? Yeah. That streaming API is based on events. It's like on data. Right? Mhmm. And when you work with streaming APIs, it's it's not a promise. It's chunks. But if you just care about the output result, you can use the promise that with resolvers to you can say, like, on error and on cancel of the media recorder is equal to reject. Oh. And then on unfinished, you give it the resolve method, and you can you can pass the the chunks to that. So it it's not again, it's not something we could never do before.

It was very easy before. It was just like 1 more level of indentation inside of a promise, but that's 1 Wes nested promise, one less weird scoping issue that we need with this sorta helper method. Yeah. And it it's actually funny, Wes, that you say that because I've used

libraries to collect a stream before as a promise, like collect stream to promise. Because when working with Braintree, every single one of their search APIs returns a stream rather than you can't just, oh, async await. You can't just await for the data to come in. And that's obnoxious as hell when you're doing like, oh, let me just do a quick HTTP call, and I don't wanna have to return the stream back to the UI. I just wanna collect the data and send it to the UI when it's done. Yeah.

That's actually, I've been wanting to make this for a while. It's like some sort of, like, custom class that extends the promise, and it gives you both the stream events, and you can await it. Yes. Because sometimes I care about both. I want the output, but I also wanna listen for the actual end. Like, a chat g p t would be a good example. Right? I care about the end text that I get from chat g p t, but I also wanna display the text as it's being streamed in from the server.

So I kinda want both. So I'm I'm sure somebody has already built that. It wouldn't be it wouldn't be too tricky.

Let's talk about fetch. We know we've talked about fetch before. Fetch, you pass it a URL, returns a promise. The kinda interesting thing here is that the first promise of a fetch is responds as soon as the server comes back with its headers. So the way that a web request works is that it requests something from a server, and the server is going to come back to you immediately with a some information. It might not be all of the information, but you do get the initial headers back. And in that, you can check for the header response code.

You can return. Most commonly, we all are doing Scott JSON.

Right? And people have often wondered, like, why why is fetch 2 promises? The first Node, and then you immediately from that, you return response dot JSON, and then you have access to the actual data. And that's because that's that's the way servers work. You you you get the the initial headers first. And then if you want all the the whole payload of the body of the response, you have to sometimes wait a little bit longer for all of that to to sort of come in. So most likely, you're checking for a response code. You're getting Scott text or JSON, but you are also we did a whole episode on streams.

You may be streaming in the result or using server sent events from the Vercel. Whereas, like like, chat g b t, a lot of these things are as they are generating the actual output, they are streaming it to the browser. So I used to think, like, while you're using chatty gpt, they're just doing this, like, fake typing to make it feel real. Mhmm. And the actual answer to that is that's actually not true. It's it's literally coming up with the result Yeah. And firing it out the door before it even knows that it is done.

And I I even I've been sorry. Go ahead. No. And that's one of the reasons why ChatGPT isn't great at commenting code if it's also creating the code. If you tell it to create code and comment the code, it always puts the comments below the code it just wrote. Because unless it's writing the comments first, maybe you could tell it to do that. It it's kind of like coming up with what it's trying to do as it's doing it. Yeah.

I don't even know when I'm gonna be Deno, but here's what I've got so far. And I've I've noticed on I use Raycast.

They just rolled out Claude Haiku support. Mhmm. And I noticed using the Claude one, sometimes it's, like, 8 or 10 words into the response, and then it just clears it and puts something different in. And it must be because as it's coming up with the result and as it's imagining more of the sentence, it goes, you know what? Those first 8 words I said were not Could be a bit better, and it it replaces it. So I thought that was kinda interesting with with streaming.

Flow control.

How do you how do you flow through promises? First of all, looping over promises, you can use a four of loop and you can await inside of a four loop. This makes everything synchronous, meaning or or or series is often a good word for that because the word synchronous in in JavaScript often means that it's blocking.

But in our case, you simply are just, like, pausing the four loop as you're doing it. And that is a good use case if you wanna do one thing after another. Like, we we talked about me downloading 10,000 files a couple episodes ago. I initially had wrote a four loop, and that was kind of slow because you download 1 file, you wait for it to finish, then you do the next Node, then you do the next one. In in reality, there's some probably some sort of use case in between doing them in series, which is Node after another, and doing them all at once with promise to all settled, which is 10,000 at once. There's some sort of middle ground, and we'll talk about that in just a second.

Yeah. I I can think of, like, some APIs too. They return things in pages.

So you could say, hey. Go off and fetch page 1. Alright. Page 2 has come back. Sometimes what they do is they give you, like, a, like, a key for what the page JS.

So then you pass that into the next fetch call, then you like, the data that precedes

it matters for the data that you're trying to get next. So that'd be a good reason to do a follow-up. Yeah. Yeah. That that's a great use case because sometimes the API will tell you how many pages there are, and you can fetch them all at once. Mhmm. But often, they don't know. You just they don't know. You just you just keep going until there's no more. And often, the only way for you to tell that is the next time you fetch 1, the result is empty.

And they're like, oh, well, there's nothing here. I must have reached the end of the road, and I no longer have to to keep doing that. Right. And, also, in cursors, that's something we haven't talked about a lot as well Wes sometimes APIs are not based on pages. They're based on cursors.

Meaning that in order to get the items after the ones you need, like, a cursor ID Mhmm. And you you can't do it until you have the cursor from the the page before it.

You can't use, like, a map. If you have an array of, like, names and you wanna fetch like, you have Scott, Wes, and CJ, and you wanna go to the GitHub API and fetch all 3 of our profiles, often what people will do is you'll map over each of those strings and return a promise, like return a fetch request that goes to those those 3 URLs, and then you'll wrap the ad in a promise to all settled to get all 3 of them. Those run concurrently, meaning they run at the same time. It's not technically. We have a whole show on that, but it you can think of it as that.

A while loop. Again, a a while loop is not something I reach for all the time, probably a couple times a year, but you can await inside of a while loop, which can be useful if you want to just wait for the the next item to come through.

While loops. Yeah. I don't find myself using while loops that often, but the other day, Node did come up, and I I while looped it. That's for sure.

Concurrency throttling queuing. So I find myself getting into this area a lot where I need to make a whole bunch. It's almost always with fetch. You know? I need to download a whole bunch of files. I need to hit an API a bunch of times to get all of this data, and you find yourself ESLint a situation where it is way too slow to do them in series Node after another.

But it is not possible to run them all at once because that will like, your Internet provider will probably shut you down or you'll hit some Scott, like, thing. If you send 10,000 requests to download files to an API, you're probably gonna get in trouble.

So there are some really nice packages out there, specifically p map, p limit.

Sanity Sohras has, I don't know, probably 15 different p dash things, and they're all, like, little utility libraries. Quite honestly, I forget which one I need every single time, and I have to read the docs.

But, like, something like p map will allow you to create an array of possible promises.

So loop over this list of 10,000 files and return a function that will download a file once it has been triggered.

And you give all of those to npm map and you say, run 5 at a time at most. And what it will do is it will simply just it'll fire off 5. And then as as as the first one finishes, it goes down to 4, and it starts the next Node, and then it starts the next one. That's that's better than chunking because chunking will do, like, 5 at a time, wait for them all to finish. And then another Another 5, wait for them all to finish. Yeah. Whereas, like, concurrent mapping will always be running 5 and always tearing off a new one as soon as there's a single spot. Yeah.

Nice. Yep. It's pretty handy. I used to use this thing called Async JS for callback based architecture, but I don't use it all the time. And I don't use it anymore because between promises, prompts all settled in these little helper functions, I find them to be more than enough.

There's also, like, p limit, p throttle, p debounce.

These will allow you to only run them at after a certain amount of time or at most every 2 minutes.

So often you will only be allowed to create 60 requests per hour. So you wanna say or or or 60 requests per minute. So, like, okay. Well, don't run more than 60 in this time span or don't run this function or or run it at most once every 1 minute. You know? And that kind of stuff can be really, really funky or retrying is another one. There's there's libraries out there for run this promise. And if it fails, retry it up to 6 times. And if so, then finally reject.

And having that all built in is really, really nice. Yeah. I have not I mean, it's funny. I I I have used throttling and debouncing, but I haven't used any of these p tools before. They're often scraping for me. It it's funny.

So maybe, maybe that's where you'll you'll have to hit it. Or, like, the OpenAI API only allows you to run it a certain amount per Sanity.

And Yeah. Sometimes these APIs will return to you how many calls you have left and and when your call amount refreshes. And if that's the case, I'll just look at the header and say, alright. If I'm out of calls, throw a 500 milliseconds wait wait in there, you know, and then and then fire it off.

But if that's not the case, they don't tell you how many are allowed. They only tell you if you can't run it. If that's the case, then you have to, like, use one of these libraries to and put in the hard limits so that it won't run it too too frequently.

TypeScript and promises. This is the last thing we have here is just how to use promises in in TypeScript. Right? Because promises are a generic in TypeScript. It's it's built in, and you'll often see that in TypeScript. It's promise angle brackets and then the actual type of the value that you want. And if you if you fetch something with a specific type, you'll see its promise square bracket, whatever. And if you put in a weight in front of it, it will unwrap the promise and actually give you the real type. Yeah. And and so to be clear, the reason why you do that promise with the brackets around it, that is essentially saying, hey. This thing does return a promise,

but then the promise itself will return that type.

Exactly. It'll eventually resolve to that amount. And a couple times, I've needed to get the type from a function that returns a promise.

And if that's the case, like, you're using, like, a a type of a specific function, sometimes you wanna take the promise off. Like, you wanna unwrap it. Like, this function returns a promise that is of a user.

You're like, I don't care about the promise part. I want the type of user.

And if that's the case, you can wrap it in the awaited TypeScript helper, and that will take the the promised part off and and give you the, the actual type there.

Promise that all settled filtering.

This is just like a a TypeScript thing in general, and I bet this will be fixed soon, but I've also been saying this for a while.

If you have a an array in typescript and you try to filter it, by default, if you don't use any, like, patching libraries or anything like this, the filter does not actually narrow the types for the items that you filtered it in, which is annoying. So you have to add a type guard to your filter to actually tell TypeScript, Node. I am I'm filtering it down. And I run into that a lot with promise dot all settled because it will return again the fulfilled and the rejected values. And if you wanna just filter for the rejected to display some errors and you wanna filter for the successes to display the data, then you'll have to write a quick little type guard. And there are I think there's a type called promise all settled result, and then you can write a type guard that will check for either the reason or the status property on there.

And lastly, there's no way to type the rejected value of a promise, and that that's a little bit of a pain as well. That's it can be nice to use that. In the last episode, we talked about that, writing, like, a wrapper function that will do collecting and give you a tuple error first, data second.

You can extend that a little bit further and internally do a type assertion, and you can say, alright. Well, if it does return an error, you can use a generic to say this is what the error will look like. And that is really nice because now and then you're you're not doing the whole, like, if error is an instance of error and or if error has a message property, then you you just know exactly what the error type is.

Wild. Yes. I think that's it for promises. Wild world. I'm impressed that we're able to get 3 episodes out of this, but there's a lot of funky stuff to learn about promises, and it's it's good to know. Can you imagine if we would have had to do this episode on

promise libraries before promises existed? Yeah.

It would have been there's so much like, with the promise libraries back in the day, you had to, like, wrap everything. Even in Node. Js before, like, like, like, the file system APIs didn't have promise versions of it, you had to, like, wrap their callback based APIs in a, like, util Scott promisify.

I did not get it. Yeah. I I I got actually got to wait until promises landed in the browser before I had to deal with Promises. I I just used callbacks until then. I was like, you know what? This doesn't seem worth it to me. That too. Yeah.

Awesome. Alright. Well, thanks everybody for tuning in. Tweet us your promised tips at Syndax event. We'd love to hear them.

Take