Fundamentals Chapter 7 flagged that Object.keys() turns an object's property names into a real array — meaning Chapter 6's map/filter/reduce can be used on object data too. This chapter covers that properly, plus the spread (...) and rest (...) operators, which look identical but do opposite jobs depending on where they appear.

Object.keys, Object.values, Object.entries

Each of these returns a real array, unlocking everything from Chapter 6. entries() is the most useful for loops — each item is a [key, value] pair, which destructures neatly (covered below).

Combining Object.values with reduce

This is the cleaner version of the Fundamentals Chapter 7 inventory challenge, which used a manual for...in loop with a separate running-total variable — here, reduce does both jobs in one expression.

Array Destructuring

Destructuring unpacks array elements straight into named variables in one line. for...of (a cousin of the for...in from Fundamentals Chapter 4/7) pairs naturally with entries(), since each entry is itself a two-element array ready to destructure.

Object Destructuring

Object destructuring pulls named properties straight out into variables of the same name — far shorter than writing person.name and person.city on separate lines, especially useful for function parameters (see below).

The Spread Operator (...) — Expanding a Collection

Spread "unpacks" an array or object's contents into a new one. { ...original, age: 36 } copies every property from original, then overwrites age — a clean way to update one field without mutating the original object, the same non-mutating spirit as map/filter from Chapter 6.

The Rest Parameter (...) — Collecting the Leftovers

The exact same ... syntax, in a function's parameter list, does the opposite job: it gathers any number of arguments into a single real array (numbers), rather than expanding something. This is what lets sum() accept any number of arguments instead of a fixed count.

Coding Challenges

Fundamentals Chapter 5 showed a nested function reading a variable from its enclosing function, and flagged that this "remembering" behaviour is called a closure, promising full coverage later — this is that chapter. A closure is simply a function that keeps access to variables from the scope it was created in, even after that outer scope has technically finished running.

The Basic Closure

makeGreeter finishes running and returns the inner function — but that inner function still remembers whatever greeting was at the moment it was created. sayHello and sayHi are two completely separate closures, each with its own private copy of greeting, even though both were built by the exact same makeGreeter function.

This Is Exactly Fundamentals Chapter 6's makeMultiplier Challenge

That earlier challenge asked why the inner function could still access factor after makeMultiplier had already finished — the answer is exactly this chapter's topic. The returned function "closes over" factor, carrying its own private reference to it for as long as the returned function itself exists.

A Closure Holds a Reference, Not a Snapshot

Each call to the returned function mutates the SAME count variable — it isn't reset, and it isn't a frozen copy taken at creation time. The closure remembers the actual variable, live, the same way two object references (Fundamentals Chapter 7) point at the same underlying object rather than separate copies.

The Classic Loop + Closure Pitfall (and Why let Fixes It)

This is the single most famous closure-related bug in JavaScript. With var (Fundamentals Chapter 2's "avoid it" keyword), there's only ever one shared i across the entire loop — by the time any of the three setTimeout callbacks actually runs, the loop has already finished and i is 3. let creates a genuinely new i binding for each iteration, so each callback's closure captures its own separate value.

Practical Use: Private State with a Module-Style Pattern

balance is never a property on the returned object — there is no account.balance to read or overwrite directly. The only way to affect it is through the three methods that closed over it, giving genuine privacy with nothing extra needed: no special keyword, no class syntax (Intermediate Chapter 3) — just an ordinary closure.

Coding Challenges

Fundamentals Chapter 7 built objects by hand, one at a time, each with its own copy of methods like greet() defined inline. class syntax (added in the same 2015 update as let/const) provides a blueprint for creating many similarly-shaped objects, plus a built-in way to extend one type's behaviour from another — JavaScript's equivalent of inheritance.

Defining a Class

constructor(...) runs automatically whenever new Person(...) is called — its job is to set up the new object's starting properties via this. Every other method (greet here) is defined directly inside the class body, with no function keyword and no commas between methods — a more compact form than Fundamentals Chapter 7's object-literal method syntax, but functionally similar underneath.

Multiple Instances, Each With Their Own Data

Each new Person(...) call produces a completely independent object with its own name/age — but all instances share the exact same greet method definition, stored once rather than duplicated per object, which is more memory-efficient than the object-literal approach from Chapter 7 at scale.

Inheritance with extends

class Student extends Person makes Student a more specific version of Person — it automatically gets every method Person has (greet), plus whatever new methods it adds itself (study). super(name, age) must be called before this can be used at all inside a subclass constructor — it runs the parent class's constructor logic first, so this.name/this.age get set up correctly before Student adds its own school property.

Overriding a Method

Defining greet again inside Student replaces (overrides) the inherited version for any Student instance. super.greet() inside the override still reaches back to Person's original method — useful when the subclass wants to extend, not completely replace, the parent's behaviour.

Getters — Computed Properties That Look Like Plain Fields

get area() defines a method that's accessed WITHOUT parentheses — rect.area, not rect.area() — recalculated fresh every time it's read. Useful for values that are always derivable from existing properties (width × height) rather than stored separately, avoiding the risk of them drifting out of sync.

Coding Challenges

Fundamentals Chapter 5 and 7 both flagged this behaviour without fully resolving it: regular functions get their own this determined by how they're called; arrow functions inherit it from their surrounding scope. This chapter makes that precise, covers the situations where this goes wrong, and introduces three methods — call, apply, bind — that control it directly.

The Real Rule: this Depends on HOW a Function Is Called

The exact same function, called two different ways, gets a different this. person.greet() sets this to person, because it's called through person. Once that same function is assigned to greetFn and called on its own, there's no object to its left at the call site — this falls back to undefined (in strict mode/modules) rather than person.

call() and apply() — Explicitly Setting this for One Call

call and apply run a function immediately, with the first argument forced into the role of this for that one call — regardless of how the function was originally defined or attached. They're functionally identical except for how the remaining arguments are passed: call lists them one by one, apply takes them as a single array (similar in spirit to the spread operator from Intermediate Chapter 1).

bind() — Permanently Locking this for Later

Unlike call/apply, bind doesn't run the function immediately — it returns a brand-new function with this permanently locked to whatever was passed in, no matter how that new function later gets called. This is the standard fix for the callback problem above: bind the method to its object before handing it off as a callback.

Arrow Functions: No Own this, Inherited Instead

Had the setInterval callback been a regular function instead, this inside it would be undefined (plain-call rule from earlier), breaking this.seconds++ entirely. The arrow function instead has no this of its own — it transparently uses whatever this was already in scope at the point it was written, which is timer, since start() itself was called as timer.start().

Why Arrow Functions Can't Be Fixed with bind/call/apply

Since an arrow function never has its own this to begin with, call/apply/bind have nothing to override — they're silently ignored for the this argument specifically. This is the one situation where those three methods simply don't apply.

Coding Challenges

Fundamentals Chapter 10 wrapped await fetch(...) in try/catch without explaining the mechanism fully. This chapter covers throw, the complete try/catch/finally structure, and — using Chapter 3's class/extends syntax — how to build custom error types carrying more information than a plain message string.

throw — Raising an Error Deliberately

throw new Error("message") immediately stops the current function (and everything that called it) from continuing normally — unlike Go's error return values (a deliberate contrast worth knowing if the Go course is ever revisited), JavaScript errors propagate upward automatically until something explicitly catches them.

try/catch — Catching a Thrown Error

Code inside try { } runs normally until something throws — at that exact point, execution jumps straight into catch (error) { }, skipping anything remaining in the try block. error.message holds the text passed to new Error(...); every error also has a name property ("Error" by default).

finally — Runs No Matter What

finally { } runs after try/catch complete, regardless of whether an error occurred — useful for cleanup work (hiding a loading spinner, closing a connection) that needs to happen either way. This is conceptually similar to Go's defer from the Go Intermediate course, just scoped specifically to error handling rather than every function exit.

Custom Error Classes

class ValidationError extends Error (Chapter 3's inheritance, applied to the built-in Error type) creates a genuinely new error type carrying extra structured data — here, field — alongside the standard message. super(message) must run first, exactly as with any other subclass constructor, to set up Error's own internal behaviour (including the stack trace).

Distinguishing Error Types in a catch Block

error instanceof ValidationError checks whether the caught error is specifically that custom type (or a subclass of it) — this is JavaScript's rough equivalent of Go's errors.As from the Go Advanced course, letting a catch block react differently depending on exactly what went wrong, rather than treating every error identically.

Coding Challenges

Intermediate Chapter 1 introduced the spread operator for copying arrays and objects, describing it as non-mutating, "the same spirit as map/filter." This chapter shows exactly where that breaks down: spread only copies one level deep, and anything nested still points at the original.

Reference Types: The Root of the Problem

Arrays and objects are reference types — a variable holding one doesn't hold the actual data, it holds a reference (an address) to where that data lives. const b = a copies the reference, not the array — both variables end up pointing at the exact same underlying array, so mutating through either one is visible through both.

Shallow Copying with Spread

{ ...original } genuinely does create a separate object — for top-level, primitive values (strings, numbers, booleans) this is a complete, independent copy. This is "shallow" because it only copies one level deep; the moment a property's value is itself an object or array, the problem returns.

Where Shallow Copying Breaks Down

Spread copied the address property, but that property's value is itself an object — spread copies the reference to that nested object, not the nested object's contents. copy.address and original.address still point at the exact same inner object, so mutating one mutates both. This is the most common real-world "spread didn't work" bug.

Deep Copying with structuredClone

structuredClone() is a built-in browser/Node function that performs a true deep copy — it recursively copies every nested object and array, so the result is completely independent of the original at every level, no matter how deeply nested.

map() Avoids This Problem Entirely

Combining map (Fundamentals Chapter 6) with object spread inside the callback creates a genuinely new object for each element — since name and age are both primitives here, this shallow approach is entirely sufficient; deep copying is only needed when the nested values are themselves objects/arrays that also need protecting from mutation.

Coding Challenges

Every variable in every chapter so far has vanished the instant the page reloads. localStorage is a browser-provided key/value store that survives refreshes, browser restarts, even the computer rebooting — and combined with JSON.stringify/JSON.parse (the same JSON mechanics behind Fundamentals Chapter 10's fetch), it can store more than just plain text.

Storing and Reading a String

setItem(key, value) saves a value under a string key; getItem(key) reads it back. Reload the page and run getItem("username") again — the value is still there, unlike every variable from earlier chapters, which would be reset to nothing on reload.

JSON.stringify — Turning Data Into a Storable String

JSON.stringify converts an object or array into a JSON-formatted string — text that fully represents the original data's structure and values, safe to store as a single localStorage string. This is the same conversion that happens automatically inside a fetch request body when sending JSON data to a server.

JSON.parse — Turning It Back Into Real Data

JSON.parse does the reverse: a JSON string back into a real, usable JavaScript object — with correct types preserved (age comes back as an actual number, not the string "35"). This stringify/parse pair is exactly how Fundamentals Chapter 10's response.json() works internally.

The Complete Save/Load Pattern

localStorage.getItem returns null if the key was never set — checking for that with stored ? ... : null (Fundamentals Chapter 3's ternary) avoids calling JSON.parse(null), which would throw rather than returning something sensible.

Removing and Clearing Storage

removeItem deletes a single key, the direct equivalent of delete obj.key from Fundamentals Chapter 7; clear() wipes every key the current site has stored in localStorage entirely.

Coding Challenges