The programming language of the web: variables, functions, the DOM, arrays and objects, and fetching data from APIs.

JavaScript Essentials

## Why this matters

Some work takes time: loading data from a server, reading a file, waiting for a timer. If JavaScript stopped and waited for each of these, the whole page would freeze: no scrolling, no clicks, nothing. Instead, JavaScript starts the slow work, carries on, and deals with the result **later**. This is called **asynchronous** code. Every app that talks to an API depends on it, so you need to be able to read and write it confidently.

## The problem in one example

```javascript
console.log("1. start");
setTimeout(() => console.log("2. timer done"), 1000);
console.log("3. end");
```

The output is `1`, `3`, then `2` a second later. `setTimeout` does not pause the program; it **schedules** a function to run later and returns immediately. Any value produced inside that function is not available on the next line.

## Callbacks

The oldest pattern is a **callback**: you pass in a function to be called when the work finishes.

```javascript
function loadUser(id, callback) {
  setTimeout(() => callback({ id, name: "Ada" }), 100);
}

loadUser(1, (user) => {
  console.log(user.name);  // "Ada", 100 ms later
});
```

Callbacks work, but when one step depends on another you end up nesting them inside each other ("callback hell"), and handling errors at each level gets messy.

## Promises

A **promise** is an object that stands for a value that will arrive later. It is in one of three states: **pending**, **fulfilled** (it has a value) or **rejected** (it has an error). You attach what should happen next with `.then` and `.catch`:

```javascript
function wait(ms, value) {
  return new Promise((resolve) => setTimeout(() => resolve(value), ms));
}

wait(100, "hello")
  .then((text) => text.toUpperCase())
  .then((upper) => console.log(upper))   // "HELLO"
  .catch((err) => console.error(err));
```

Each `.then` returns a new promise, so steps chain top to bottom instead of nesting. One `.catch` at the end handles a failure at any step. Most browser APIs, including `fetch`, return promises, so you will mostly **use** promises rather than create them.

## async and await

`async`/`await` is a nicer way to write the same thing. Inside an **`async` function**, `await` pauses *that function* (not the whole page) until a promise settles, and gives you its value:

```javascript
async function shout() {
  const text = await wait(100, "hello");
  return text.toUpperCase();
}

shout().then((result) => console.log(result));  // "HELLO"
```

Two rules to remember:

1. **`await` only works inside an `async` function** (or at the top level of a module).
2. **An `async` function always returns a promise.** Whatever you `return` becomes the promise's value, so callers either `await` it or use `.then`.

## Sequencing dependent steps

Suppose `fetchUser(id)` and `fetchPosts(userId)` both return promises, and you need the user before you can load their posts:

```javascript
async function loadProfile(id) {
  const user = await fetchUser(id);        // wait for the user
  const posts = await fetchPosts(user.id); // then their posts
  return { name: user.name, postCount: posts.length };
}
```

That reads like ordinary step-by-step code, which is the whole point of `await`.

## Running independent work in parallel

If steps do **not** depend on each other, awaiting them one by one wastes time. `Promise.all` starts them together and waits for all of them:

```javascript
async function loadNames(ids) {
  const users = await Promise.all(ids.map((id) => fetchUser(id)));
  return users.map((u) => u.name);
}
```

Three requests of 100 ms each take about 100 ms in total with `Promise.all`, instead of 300 ms in sequence. `Promise.all` keeps the results **in the same order** as the input, and rejects as soon as any one of them fails.

## Errors

A rejected promise inside `await` throws, so you can use ordinary `try`/`catch`:

```javascript
async function safeLoad(id) {
  try {
    return await fetchUser(id);
  } catch (err) {
    console.error("Could not load user", err);
    return null;
  }
}
```

The final lesson of this module goes deeper into errors and fallbacks.

## Common mistakes

- **Forgetting `await`.** `const user = fetchUser(1);` gives you a pending promise, so `user.name` is `undefined`.
- **Using `await` in a normal function.** It is a syntax error; mark the function `async`.
- **Expecting an `async` function to return a plain value.** It returns a promise; `await` it.
- **Awaiting independent work in a loop.** Use `Promise.all` to run it in parallel.
- **No error handling.** An unhandled rejection fails silently in the UI; add `catch` or `try`/`catch`.

## Quick recap

- Asynchronous work finishes later; the rest of the code keeps running.
- Callbacks were first; promises chain with `.then`/`.catch`.
- `async`/`await` makes promise code read top to bottom; an `async` function returns a promise.
- `await` for dependent steps, `Promise.all` for independent ones.

## Try it

Open the **Do** tab: use `await` to load a profile in order and `Promise.all` to load several users at once.


Understand why some work finishes later, and sequence it clearly with promises and async/await.

Callbacks, promises, async/await

JavaScript Promises In 10 Minutes

The Async Await Episode I Promised

## Why this matters

Most web pages do not contain their data; they **ask for it**. A weather widget asks a weather service, a shop asks its product API, this site asks its own backend for your courses and progress. In the browser, the standard way to ask is **`fetch`**. Combined with `async`/`await` and the DOM skills from module 2, it lets you build pages that show live data.

## What an API request looks like

An **API** (application programming interface) is a set of URLs that return data instead of web pages. You send an HTTP **request** to a URL and get back a **response** with:

- a **status code**: `200` OK, `404` not found, `500` server error, and so on;
- **headers**, such as `Content-Type: application/json`;
- a **body**, usually JSON text.

## fetch in three steps

```javascript
async function loadUsers() {
  const res = await fetch("https://api.example.com/users");  // 1. request
  if (!res.ok) {                                            // 2. check the status
    throw new Error(`HTTP ${res.status}`);
  }
  const users = await res.json();                           // 3. parse the body
  return users;
}
```

1. `fetch(url)` returns a promise for a **Response** object. `await` it.
2. Check **`res.ok`**, which is `true` for status codes 200–299. This step matters because `fetch` only rejects when the network itself fails (offline, DNS error). A `404` or `500` still **resolves** normally, so without this check your code would try to use an error page as data.
3. `res.json()` reads the body and parses it as JSON. It also returns a promise, so `await` it too. (Use `res.text()` for plain text.)

## Rendering the results

Once you have an array of objects, turn each one into an element. Use `textContent` so data from the server is shown as text and can never inject HTML:

```javascript
function renderUsers(users, listEl) {
  listEl.replaceChildren();          // clear old items
  for (const user of users) {
    const li = document.createElement("li");
    li.textContent = `${user.name} (${user.email})`;
    listEl.append(li);
  }
}
```

`replaceChildren()` with no arguments empties an element, so rendering twice does not duplicate the list.

## Loading and error states

A request can take a while or fail. A good interface tells the user what is happening:

```javascript
async function showUsers(listEl, statusEl) {
  statusEl.textContent = "Loading...";
  try {
    const users = await loadUsers();
    renderUsers(users, listEl);
    statusEl.textContent = `Loaded ${users.length} users`;
  } catch (err) {
    statusEl.textContent = "Could not load users. Please try again.";
  }
}
```

Three states (loading, success, error) are the minimum for any data-driven component. You will see the same pattern in React later.

## Sending data

`fetch` can also send data. Pass an options object with a method, headers and a JSON body:

```javascript
await fetch("/api/notes", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ title: "My note" })
});
```

## Passing fetch in (for testing)

In the activity, your function receives the fetch function as a parameter, `loadUsers(fetchFn, ...)`. The practice sandbox has no network access, so the page provides a `fakeFetch` that returns a real `Response` object with sample data, and the checks can pass in a failing one. This pattern, called **dependency injection**, is also how professional teams test code that talks to servers without calling the real server.

```javascript
const fakeFetch = () =>
  Promise.resolve(new Response(JSON.stringify([{ name: "Ada" }]), {
    status: 200,
    headers: { "Content-Type": "application/json" }
  }));
```

## CORS in one paragraph

When you call an API on a **different domain** from a browser, the server must allow it with CORS headers. If it does not, the browser blocks the response and you see a CORS error in the console, even though the request worked in another tool. That is a server setting, not a bug in your `fetch` call. Many public APIs allow it; for others, requests go through your own backend (this site's frontend proxies every call through its own `/api` routes for this and other reasons).

## Never put secrets in frontend code

Anything in browser JavaScript can be read by anyone who opens DevTools. API keys that cost money or grant access belong on a server, never in a `fetch` call in the page.

## Common mistakes

- **Forgetting to check `res.ok`.** A 404 is not an exception for `fetch`.
- **Forgetting the second `await`.** `res.json()` returns a promise.
- **Using `innerHTML` with API data.** Use `textContent`.
- **No loading or error state.** The page looks broken while waiting or after a failure.
- **Rendering without clearing.** Old items pile up; clear the list first.

## Quick recap

- `await fetch(url)`, check `res.ok`, then `await res.json()`.
- `fetch` rejects only on network failure; check HTTP errors yourself.
- Render with `createElement` and `textContent`; show loading, success and error states.
- Keep secrets on the server.

## Try it

Open the **Do** tab: write `loadUsers` so it fetches a user list, renders it, and shows a status message (including when the request fails).


Request JSON with fetch, check the response, and render the results to the page safely.

Fetching data from an API

Learn Fetch API In 6 Minutes

Asynchronous JavaScript Tutorial #9 - The Fetch API

## Why this matters

Code that only works when everything goes right is a demo, not software. Real users type letters into number fields, lose their connection halfway through a request, and paste text you never imagined. Real data arrives empty, incomplete or malformed. Professional code expects this: it **validates** input, **handles** failures without crashing, and gives the user a clear way forward. This lesson brings together everything in the course with that mindset.

## try, catch, finally

When code might **throw** an error, wrap it in `try`. If anything inside throws, control jumps to `catch`, and the error object tells you what happened:

```javascript
try {
  const settings = JSON.parse('{"theme": dark}');  // invalid JSON
  console.log(settings.theme);
} catch (err) {
  console.error("Could not read settings:", err.message);
} finally {
  console.log("This runs either way");
}
```

- `catch (err)` receives the error; `err.name` is the type (`SyntaxError`) and `err.message` the description.
- `finally` runs whether or not there was an error, which is handy for cleanup such as hiding a spinner.
- Code after the whole block keeps running, so one bad value does not stop the page.

## Fallback values

A very common pattern is "try it, and use a sensible default if it fails":

```javascript
function safeParseJSON(text, fallback) {
  try {
    return JSON.parse(text);
  } catch {
    return fallback;
  }
}

safeParseJSON('{"a":1}', {});   // { a: 1 }
safeParseJSON("not json", {});  // {}
```

(`catch` without `(err)` is allowed when you do not need the error.)

## Throwing your own errors

When a function receives input it cannot work with, the clearest response is often to **throw** an error with a helpful message, instead of returning a confusing value like `NaN`:

```javascript
function parseAge(text) {
  const age = Number(text);
  if (text.trim() === "" || !Number.isInteger(age)) {
    throw new Error(`"${text}" is not a whole number`);
  }
  if (age < 0 || age > 150) {
    throw new RangeError(`Age ${age} is out of range`);
  }
  return age;
}
```

The caller decides what to do: show the message next to the form field, ask again, or log it. Throwing an `Error` object (not a string) gives you a stack trace showing where it came from. Built-in types like `TypeError` and `RangeError` say what kind of problem it is.

Note the empty-string check: `Number("")` is `0`, not `NaN`, a classic edge case.

## Errors in async code

With `async`/`await`, a rejected promise throws at the `await`, so the same `try`/`catch` works:

```javascript
async function loadWithFallback(fetchFn, fallback) {
  try {
    const res = await fetchFn();
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    console.warn("Using fallback data:", err.message);
    return fallback;
  }
}
```

Note the `return await` inside `try`. Without `await`, a rejection would escape the `catch` and reach the caller instead.

If you use `.then` chains, add a `.catch` at the end. An unhandled rejection does not crash the page, but whatever was supposed to happen next simply never happens, which is confusing for users.

## Thinking in edge cases

Before you call a function finished, ask what happens with unusual input. A checklist for most functions:

| input | ask |
|---|---|
| empty | `""`, `[]`, `{}`: is there a sensible answer (0, null, a message)? |
| missing | `undefined` or `null` arguments or properties |
| wrong type | `"5"` instead of `5`; an object instead of an array |
| boundary | 0, negative numbers, the first and last item, very large values |
| failure | the network is down, the server returns 500, the JSON is broken |

For example, an average function:

```javascript
function average(nums) {
  if (!Array.isArray(nums) || nums.length === 0) return 0;
  return nums.reduce((sum, n) => sum + n, 0) / nums.length;
}
```

Without the guard, `average([])` is `0 / 0`, which is `NaN`, and `NaN` will then appear on screen as "NaN".

**Optional chaining** and **nullish coalescing** help with missing data:

```javascript
const city = user?.address?.city ?? "Unknown";
```

`?.` stops and gives `undefined` instead of throwing when something is `null` or `undefined`; `??` supplies a default only for `null`/`undefined` (unlike `||`, which also replaces `0` and `""`).

## When not to catch

Do not wrap everything in `try`/`catch` and ignore the error. A silent `catch {}` hides real bugs and makes debugging much harder. Catch where you can **do something useful** (show a message, use a fallback, retry), and let unexpected errors surface so you find them.

## Common mistakes

- **Empty catch blocks** that swallow errors with no message or fallback.
- **Throwing strings** instead of `Error` objects (no stack trace).
- **Forgetting `return await`** inside `try` in an async function.
- **Trusting `Number()`** without checking for `NaN` and empty strings.
- **Showing raw error messages to users.** Log the details; show a plain, helpful sentence.

## Quick recap

- `try`/`catch`/`finally` handle errors; fallbacks keep the page working.
- Throw `Error` objects with clear messages for input you cannot handle.
- Async errors are caught at `await`; add `.catch` to promise chains.
- Check empty, missing, wrong-type, boundary and failure cases; `?.` and `??` help with missing data.

## Try it

Open the **Do** tab and make three functions robust: a JSON parser with a fallback, an age validator that throws, and an async loader that falls back when the request fails.


Handle failures with try/catch, throw clear errors, and plan for empty, missing and invalid input.

Errors and edge cases

try, catch, finally, throw - error handling in JavaScript

Javascript Error Handling | Handle Errors in Javascript | Try Catch Finally

Promises and async/await, fetching data from APIs, and handling errors and edge cases.