JS Promises Fundamentals - Part 1

you are going to enjoy it. I promise you. I was about to make that same joke.

you'll want to check out Sanity at sentry.ioforward/ syntax. You can sign up today and get 2 months for free. Sentry is just a really incredible tool for not only tracking your performance, making sure your application has no bugs, but even just seeing what goes wrong when something goes wrong because things go wrong all the time when we're coding. And you don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to reduce entry.ioforward/ syntax. Again, we've been using this tool for a long time, and it totally rules. Alright.

I think this is a great idea, though, because, you know, I remember when I first learned about promises black back when they weren't in the browser, you had to use q or Bluebird or one of those. Right? Yeah. I remember being very confused about why they're a big Deno, what makes them interesting, how is it different than something like a callback function, What's the deal with promises? So I think this will be a really great episode. And in this episode, and specifically yeah. We're getting into promises 101, creating and waiting on promises. So I think we can start this off with the first question.

anything. The most common one being you wanna take this 1? Yeah. And I think the one that most people have used is fetch calls.

If you go off and you know, there used to be libraries, and now we have a standardized fetch API.

If you go off to grab some data from anywhere, and you're most likely using fetch. And if you've ever tried to access that data immediately, you'll know that it returns a promise.

When you go off to do a fetch, it it doesn't know how long that's going to take. It says, I'm gonna go get some data. I'll be right back.

And then and you say, alright. Let me wait for that data. Or when when the data does come back or perhaps you failed to get to the store, then you can, you know, bring that data back, and now we can do something with it. So you've gone off to a trip to the store. You've now come back with the goodies that you you ordered.

anytime something could be blocking, we use a a promise. So that way, it takes something that could be blocking and makes it so it does not block the execution of other things, which is one of the reasons why we have to do the whole the whole then thing with promises that we'll get into.

Another thing could be, requesting the user's permissions for things, like co webcam. Right? The reason why these have to be returned as promises because you're, again, you're waiting for something to come back from the user's computer, whether that is prompting them to do the permissions acceptance or whatever.

Yes. And I don't think this necessarily fits ESLint there, but there's also so you resolve or reject a promise, and and those things connect very firmly to Wes we're working on promises.

We'll talk about this in a bit, but that those connect directly to the then. Right? The then method is called once a promise has been resolved. The catch method gets called when something is rejected, and then finally gets called no matter what. We'll then we'll talk about those more in a second. So, next step is creating promises. So how do you create your own promise? Oftentimes, we're consuming promises. Right? We're using a a dot then. We're using a async await. We're we're not necessarily writing them, but you can write your own promises using new promise. And you can create a promise, and that gives you a callback where you can use the resolve or reject methods to, like, Wes mentioned moments ago, either resolve and complete the promise or reject and fail the promise. Yeah. You are often creating your own promises

Yep. And here's a a small little thing for people who find themselves doing this.

If your function returns a promise, what you don't wanna do is you don't wanna mark the function as async and then await that promise and then return the result.

You just return the promise from that function, and you're returning a promise from the function rather than having to create a new promise and and do it that way. So like I mentioned, we're then gonna get into, like, the waiting on a promise bit of this because, again I got sorry. I got one more thing to say about that.

thens that that will be an issue for you. Do you think there is any sort of performance implications there? I I don't know if there is. I'm just wondering. I don't I don't think so. Often,

Word.

Alright. Well, let's talk about waiting on a promise then because like we mentioned, a promise is you know? Yeah. It's a commitment to come back and and you know? I'm promising to to go to the store and get some candy cigarettes. When I come back, I better have those candy cigarettes. Do you remember those, by the way? Did you ever get those in Canada? Yeah. It's it's pretty wild that we just, like, had cigarettes, and they're, like, red on the tips. Like, clearly, you're trying to make these fake cigarettes. But I said you're supposed to, like, keep keep them in your mouth. I just chomped them up. That's what I did. They're, like, chomping. I can't. Yeah. I can't do that.

Alright. Well, let's talk about waiting on those promises. Right? So the main way that a lot of people have done it is with a dot then method.

So instead of using a sync await or anything like that, you have your promise, then you say you have a function call, right, obviously, and then you chain a Scott then to the end of that.

Dot then has a callback, and then that callback has the data that's available to you if that promise is resolved correctly.

If the promise rejects, you would then need to also chain a dot catch.

I don't know why. I I Wes I don't know why I said that, you know, apprehensively.

You then need to chain a a dot catch in which the error will be available in the callback function. And then there's also, a third one that a lot of people don't use, which is finally, which this will go no matter what. So if you find yourself duplicating some logic, maybe, like, you're waiting for a value and then you're setting a state toggle based on that value, if that state toggle is toggled Deno matter what, if there's an error or a fit a success state, you could put that in your finally. So the finally is gonna run no matter what after the catch and after the then.

Yeah. My default is it is funny because it sometimes it feels haphazard in which I I'll be like, oh, I'm not inside of an async function. I don't feel like making this function async, so I'll just throw a dot then on there.

I to me, it depends on, like, what I have to do with that data. The thing that's always bugged me about the then methods is that you're now going another layer deep. Right? If you wanna access that data outside of the promise, you have to create a variable and pass it and worry about the default values before and after the the promise return. So almost always, I'm using await just because it reads more like how I would expect it to work, and then I can access the values where I want to access them. Alright. Wait for the value. It's there. Now I can do something with it. But, you know, there certainly are times where I am using a a catch or a dot then as well. I do use a dot catch even on await instead of doing a try catch, though.

Sick.

I look forward to your promise of future episodes. Promise it will be good. Peace. I can't