JavaScript Async/Await Practice

This single fact explains most async/await bugs:

async function getData() {
  return 42;  // Still returns Promise<42>, not 42
}

const result = getData();
console.log(result);  // Promise { 42 }, not 42!

const actual = await getData();
console.log(actual);  // 42

Rule: If a function is async, you must await it to get the value. If you see Promise { <pending> }, you forgot an await somewhere. For a printable quick reference of all async patterns, see the JavaScript async/await cheat sheet.

Sequential awaits in loops are a common performance mistake:

// SLOW: Each fetch waits for the previous one
for (const id of ids) {
  const user = await fetchUser(id);  // 1s each = 5s total for 5 users
  users.push(user);
}

// FAST: All fetches run simultaneously
const users = await Promise.all(
  ids.map(id => fetchUser(id))  // 1s total for 5 users
);

When to use sequential: Only when each iteration depends on the previous result, or you're rate-limiting intentionally.

When to use parallel: Independent operations that don't affect each other.

JavaScript has four Promise combinators. Pick the right one:

Promise.all: fail-fast parallelism

try {
  const [user, posts, settings] = await Promise.all([
    fetchUser(id),
    fetchPosts(id),
    fetchSettings(id)
  ]);
} catch (err) {
  // If ANY request fails, we end up here
  // The other requests still complete, but we don't get their values
}

Promise.allSettled: partial success

const results = await Promise.allSettled([
  fetchUser(id),
  fetchPosts(id),    // This can fail...
  fetchSettings(id)  // ...without losing these
]);

// Each result has { status, value } or { status, reason }
for (const result of results) {
  if (result.status === 'fulfilled') {
    process(result.value);
  } else {
    logError(result.reason);
  }
}

Promise.race: timeouts

const fetchWithTimeout = async (url, ms) => {
  const timeout = new Promise((_, reject) =>
    setTimeout(() => reject(new Error('Timeout')), ms)
  );
  return Promise.race([fetch(url), timeout]);
};

Promise.any: first success

// Try multiple CDN mirrors, use whichever responds first
try {
  const response = await Promise.any([
    fetch('https://cdn1.example.com/data'),
    fetch('https://cdn2.example.com/data'),
    fetch('https://cdn3.example.com/data')
  ]);
} catch (err) {
  // AggregateError: all mirrors failed
  console.log(err.errors);  // Array of all rejection reasons
}

// BUG: forEach doesn't wait for async callbacks
items.forEach(async (item) => {
  await processItem(item);  // These fire but...
});
console.log('Done!');  // ...this runs immediately!

Why it fails: forEach returns undefined, not a Promise. The async callbacks execute, but nothing awaits them.

Fixes

Sequential (for...of):

for (const item of items) {
  await processItem(item);
}
console.log('Done!');  // Runs after all items processed

Parallel (map + Promise.all):

await Promise.all(items.map(item => processItem(item)));
console.log('Done!');  // Runs after all items processed

Modern fetch supports cancellation via AbortController:

const controller = new AbortController();

// Start the request
const fetchPromise = fetch('/api/data', {
  signal: controller.signal
});

// Cancel after 5 seconds
const timeoutId = setTimeout(() => controller.abort(), 5000);

try {
  const response = await fetchPromise;
  clearTimeout(timeoutId);
  return response.json();
} catch (err) {
  if (err.name === 'AbortError') {
    console.log('Request was cancelled');
  } else {
    throw err;
  }
}

Common patterns:

• Cancel on component unmount (React useEffect cleanup)
• Cancel on user navigation
• Cancel superseded requests (new search query cancels old one)

The event-driven nature of async code shares principles with the Observer design pattern, where subscribers react to events they've registered interest in.

When a Promise rejects and nothing catches it:

async function oops() {
  throw new Error('Something broke');
}

oops();  // No await, no .catch()
// UnhandledPromiseRejection warning!

In Node.js: Unhandled rejections crash the process in Node 15+.

In browsers: Logged to console, may break application state silently.

Fix: Always handle rejections. For a deeper look at error handling patterns across languages, see the Python vs JavaScript error handling comparison.

// Option 1: await + try/catch
try {
  await oops();
} catch (err) {
  handleError(err);
}

// Option 2: .catch()
oops().catch(handleError);

// BUG: Error bypasses the catch block!
async function fetchData() {
  try {
    return fetch('/api/data');  // Returns pending Promise
  } catch (err) {
    return fallback;  // Never runs on fetch error!
  }
}

// CORRECT: await ensures error is caught locally
async function fetchData() {
  try {
    return await fetch('/api/data');  // Awaits before returning
  } catch (err) {
    return fallback;  // Runs on fetch error
  }
}

Why it happens: return fetch() returns a pending Promise immediately, before it can reject. The catch block only catches errors that happen synchronously within the try.

The rule: Inside a try block, always return await if you want the catch to handle the rejection.

Note: Outside of try/catch, return await is redundant and ESLint's no-return-await rule will flag it. But inside try/catch, it's required.

• MDN: async function
• MDN: Promise.all
• MDN: AbortController
• JavaScript.info: Async/await