Search for a command to run...
It's not always needed.
Software developer since 2004. Web/front-end expert (HTML, CSS, JS). O'Reilly and Apress author. Freelance tech writer. Blogger. Bridging code and communication in tech.
No comments yet. Be the first to comment.
This series will give you some tips for working with the `Promise` APIs more effectively, and avoiding common pitfalls.
Promise chains You can create a chain of Promises by returning new Promises from a then handler. Here's a simple example that chains 3 promises together: Promise.resolve(1) .then(id => { console.log(`Success: ${id}`); return Promi...
Using semantic HTML elements has several benefits over using plain divs.
Vibe coding is a new way to code that is gaining popularity. But is it the future?
Looking back on my journey as a published author, from Apress to O'Reilly.
Learn how to use media queries to learn about certain device settings.
You’re working on a bug fix and find some bad code that causes a bug. The git blame command will tell you who the last developer was that modified that line, and when they modified it. But what if you don’t know what code introduced the bug? For thes...
Promises are pretty ubiquitous these days, but sometimes Promise based code is more complex that it needs to be.
Consider this getUserDetails function:
function getUserDetails(userId) {
return new Promise((resolve, reject) => {
fetch(`/users/${userId}/details`)
.then(response => response.json())
.then(data => resolve(data));
.catch(error => reject(error));
});
}
This function returns a Promise that will be resolved when the fetch call is complete and the JSON response is received.
We make the fetch call and extract the JSON in the first then handler. response.json() also returns a Promise, so we call then on that too. Once we have the JSON result, we can resolve our returned Promise.
If there is an error, we reject our returned Promise.
Here's a somewhat rough analogy, but bear with me here. Suppose you want to buy an item listed on eBay. The above code is sort of like if you purchased the item, and the seller shipped it to eBay. Then, once eBay received it, they shipped it to you. Sounds overly complicated, right?
Client code that calls getUserDetails looks like this:
getUserDetails(userId).then(details => {
doSomethingWith(details);
});
We are calling then on the outer Promise that was returned from getUserDetails.
We can do better! If the asynchronous thing you are doing already returns a Promise, as fetch does, you don't need to wrap it in your own Promise.
The above function can be written much more simply:
function getUserDetails(userId) {
return fetch(`/users/${userId}/details`)
.then(response => response.json());
}
This function has the same net result! In both listings above, getUserDetails returns a Promise that resolves to the user details object.
To return to the eBay analogy: This approach is how eBay actually works: you purchase the item through eBay, eBay tells the seller, and the seller ships directly to you.
In the first example, we are creating our own Promise which wraps the asynchronous operation. The difference with the second example is that we are just returning the Promise that response.json() gives us.
Promise?There are some cases where rolling your own Promise is unavoidable, for example when working with a callback or event based API.
Let's make a quick and dirty image loader! This function will take an image URL and return an img element, but not until the image has loaded.
function loadImage(url) {
return new Promise((resolve, reject) => {
const image = document.createElement('img');
image.addEventListener('load', () => {
resolve(image);
});
image.addEventListener('error', error => {
reject(error);
});
image.src = url;
});
}
Because the image element doesn't provide a Promise itself, in this case we have to roll our own. Depending on which event listener is fired, we either resolve the Promise with the now fully loaded image, or reject it with the error encountered while loading.
This is easy to use:
loadImage('/logo.png').then(image => container.appendChild(image));
Some older APIs are still callback based. You might want to make a "promisified" version of such an API. For this, you will need to create a Promise.
Consider this simplified example of an API. It follows the typical Node.js callback pattern - it takes two callback function arguments. The first will be called if there is an error, and the second will be called on success. We use such an API like this:
db.findItem(123, error => {
console.log('oops, an error:', error);
}, data => {
console.log('got data:', data);
});
Callbacks can be a little painful to work with, so we can wrap this API with a Promise:
function findItemPromise(recordId) {
return new Promise((resolve, reject) => {
db.findItem(recordId, error => reject(error), data => resolve(data));
});
}
This can actually be simplified a bit more. Since the resolve and reject handlers take a single argument, which matches the arguments of the error and data callbacks, we can just specify those functions themselves as the callbacks:
function findItemPromise(recordId) {
return new Promise((resolve, reject) => {
db.findItem(recordId, reject, resolve);
});
}
Now we can use the findItemPromise API:
findItemPromise(recordId)
.then(data => console.log('got data:', data))
.catch(error => console.log('oops, an error:', error));
In fact, if you are working with Node.js, you don't need to do this wrapping yourself. The Node.js API includes a promisify utility function that does exactly this!
Promise, you most likely don't need to wrap it in your own new Promise. Instead, you can just utilize the existing Promise.Promise which wraps the API call, and calls the resolve and reject handlers accordingly.promisify utility function that will convert any callback-based function (that follows the Node convention of (error, success) callbacks) into a Promise based one.