105 道问答题，一道一卡105 questions, one card each

In one line: this is decided when the function is called, not where it was written. Look at who called it.

Four rules, highest priority first — this order is the model answer:

1. new binding — with new Foo(), this is the object that was just created.
2. Explicit binding — whatever you handed to call / apply / bind.
3. Implicit binding — obj.fn() makes this the obj (look left of the dot).
4. Default binding — when none of the above applies: undefined in strict mode, otherwise window / global.

Arrow functions are the exception; they do not play by those four rules — an arrow has no this of its own, it uses the this of the scope it was defined in, and call / bind cannot change that.

The classic trap: the implicit binding gets lost. Do const fn = obj.method and then call fn() on its own — the dot is gone, so this is gone. Handing a method off as a callback (setTimeout(obj.method), onClick={this.handle}) is the same bug — and it is exactly why React class components had to bind in the constructor.

Follow-up: “What is this inside a DOM event handler?” — in a normal function it is the element the listener is attached to (the same as e.currentTarget); in an arrow function it is the outer this.

In one line: all three change this. call and apply run the function right away, bind hands you back a new one; call takes its arguments one by one, apply takes an array.

How to remember it: Apply takes an Array, Call takes Commas.

Two extra properties of bind they will probe:

• It can preset arguments — which makes it partial application (see #299).
• Bind once and it is locked — another bind or a call cannot change it back. But new breaks through, because new has the highest priority.

Another follow-up: “Is apply still useful?” — spread syntax replaced most of it with fn(...args). It is still the normal way to forward an unknown argument list: fn.apply(this, args) — that is how debounce is written, because you have to forward this and args at the same time.

In one line: JS has one main thread, and the event loop’s job is to pull the next task off a queue and put it on the stack whenever the call stack goes empty.

One full turn — this part is the model answer:

1. Run the synchronous code to the end (the call stack empties).
2. Drain the microtask queue completely — note “completely”: microtasks queued while draining also run inside this same turn.
3. (In a browser) paint a frame if one is needed.
4. Take one macrotask, run it, go back to step 2.

Microtasks: Promise.then/catch/finally, the code after an await, queueMicrotask, MutationObserver.
Macrotasks: setTimeout / setInterval, DOM event handlers, network callbacks, requestAnimationFrame (strictly it runs just before paint, in a class of its own).

The priority in one line: a Promise always runs before a setTimeout, even setTimeout(…, 0).

Follow-up: “Who actually does the async work?” — not the engine, the host environment (the browser’s Web APIs, libuv in Node). The engine only runs JS. This one pairs with #276.
“Is setTimeout(fn, 0) really zero milliseconds?” — no. Browsers clamp it to roughly 4ms, and it still waits for a free main thread. So it means “as soon as possible, but not now”.

How Node differs (a bonus point if it comes up): Node splits macrotasks into six phases (timers / pending / poll / check / close…), setImmediate lands in the check phase, and process.nextTick jumps ahead of every microtask.

In one line: async/await is syntax sugar over Promises — the same machinery, but a chain of callbacks now reads straight down like synchronous code. An async function always returns a Promise.

That “serial by accident” trap is worth its own sentence: two requests that do not depend on each other, written as two await lines, turn into “wait for the first, then send the second”, so the total is the sum of both. Fire them both off first, then await Promise.all.

Follow-up: “When is .then still the better choice?” — for a single step with no intermediate values, or when you deliberately do not want to wait (fire and forget). .then also reads better when you are storing a Promise and passing it around.

In one line: when each async step depends on the last, callbacks nest inside callbacks, the indentation keeps growing, and you end up with a sideways triangle — also called the pyramid of doom.

The real damage is not that it looks bad. There are three problems:

• Error handling gets written n times. Every level needs its own if (err), and one missed check is a silent failure.
• Nothing composes. Making two of those steps run in parallel means rewriting nearly all of it.
• Control flow is expressed only by indentation, so inserting a step means shuffling a pile of braces.

The fixes, in historical order: pull the callbacks out into named functions → a Promise chain (nesting becomes chaining, errors collapse into one .catch) → async/await, which makes it fully linear.

Follow-up: “Which part of callback hell did Promises actually solve?” — mostly error handling and composition; the indentation came along for the ride. Answering that way shows you understand the substance, not just “Promises flatten the code”.

In one line: it runs whether the promise succeeded or failed, so it is where the cleanup goes — turn off loading, release resources, report how long it took.

Three properties to state clearly:

• It sees neither the value nor the error — the callback takes no arguments. Its whole job is cleanup that does not care about the result.
• It passes through — the original value or error continues down the chain unchanged, so the state of the chain is untouched. A return inside finally changes nothing.
• But throwing inside it does override the result — that is the only way it can change the chain.

Why this question earns its place: it maps onto a real bug — call setLoading(false) only on the success path and the UI sits on Loading forever when the request fails. That exact mistake is on the common-errors list for our fetch variant question.

Follow-up: “Is it the same as the finally in try/catch/finally?” — same meaning: it always runs. With async/await just use try/finally; you do not need .finally().

In one line: try/catch for synchronous code, .catch() for Promises, try/catch again for async/await; and always keep a backstop at the very top.

The most important point: try/catch cannot catch an async error thrown inside a callback. A setTimeout callback runs in a later turn of the event loop, and by then the try block is long off the stack.

Four levels of practice:

• Throw when you should throw — do not swallow the error and hand back return null; the caller then cannot tell “not there” from “it broke”.
• Throw an Error object, never a string — a string carries no stack. When callers need to tell cases apart, write class NotFoundError extends Error.
• Only catch where you can actually handle it. Catching and then doing nothing (catch (e) {}) is the worst thing you can write.
• Keep a backstop — in the browser window.onerror plus unhandledrejection; in Node process.on("uncaughtException"); in React an error boundary (see #333); in Express error-handling middleware.

Follow-up: “How do you handle errors from fetch?” — this is a trick question. fetch only rejects when the network layer fails; 404 and 500 both resolve, so you have to check res.ok yourself. That is also the first thing the fetch variant question in the React course tests.

In one line, and history tells it best: callbacks → Promises → async/await, plus events and for await…of for streaming data.

But what this question is really after is how you pick among the four static Promise methods, and they will ask:

The trap in all: it is fail-fast — one rejection and the other requests already in flight are not cancelled, and you never see their results. When bulk work has to report item by item, reach for allSettled.

Follow-up: “How do you put a timeout on a request?” — Promise.race against a Promise that rejects on a timer. Better is AbortController, because it actually kills the request, whereas race merely stops waiting. We walk through that difference in the fetch variant question too.

In one line: the DOM is the tree of objects the browser builds when it parses your HTML — one node per tag. A DOM event is something that happens on that tree (a click, some typing, a load finishing), and you register functions to respond to it.

Be precise about the key point: the DOM is not the HTML itself, and it is not part of the JavaScript language — it is an API the browser hands you (a Web API). That is why Node has no document. This one pairs with #276.

Why “touching the DOM is slow”: reading and writing a property is not the slow part. The cost is that it can trigger reflow and repaint — the browser has to recompute layout and paint again. Reading offsetHeight and then changing a style, over and over inside a loop, causes layout thrashing, and that is the real performance killer.

This is exactly what makes the virtual DOM worth something (see #330): it batches many operations into one and tries to touch only what changed.

Follow-up: “What is the difference between target and currentTarget on the event object?” — target is the element that was actually clicked, currentTarget is the element this listener is attached to. Event delegation rides entirely on that difference, which is the next question.

In one line: propagation is the browser’s mechanism (capture → target → bubble, see #380); delegation is the trick we play with it — put the listener on the parent and use e.target to work out which child was really clicked.

Delegation solves two problems:

• The number of listeners — a 1000-row table with 1000 listeners costs real memory and real binding time; delegation needs one.
• Dynamic elements — children inserted later already have the behaviour, with nothing to rebind. In practice this is often the bigger win.

The key to writing it is e.target.closest() — the user may have clicked a <span> inside the button, so a bare e.target.matches() misses it.

Follow-up, and this is the one that matters: “Are React events delegated?” — yes, and it is central to the design: React attaches events to the root container (to document before React 17, to the root node from 17 onwards, so that several React versions can coexist on one page), then wraps them in a SyntheticEvent to present one event system that behaves the same across browsers.
The consequence: inside React, e.stopPropagation() does stop propagation between React components, but it cannot stop a native listener — the native one already ran. Landing this point scores well.

In one line: the 2015 edition changed the most, and a dozen or so of its additions are things you use every single day.

Ordered by weight — pick five or six and explain them properly, do not recite the list:

• let / const — block scope (#282)
• Arrow functions — shorter, plus a lexical this (#285)
• Template literals — `${x}`, and they span lines
• Destructuring — const { a, b } = obj, used everywhere in React
• Spread and rest — ..., the basis of immutable updates
• Default parameters
• Promise — the turning point for async (#306)
• class — sugar over prototypes (#302)
• ES modules — import / export (#308)
• Map / Set (#286, #287), Symbol, for…of with iterators, generators

Follow-up: “What came after ES6 that you like?” — answering this makes you look like you keep up: async/await (ES2017), optional chaining ?. and nullish coalescing ?? (ES2020), Object.entries (ES2017), Array.flat (ES2019), at(-1) (ES2022), structuredClone.
Optional chaining and ?? are the two most worth naming, because they cut out a mountain of defensive code.

In one line: the module system built into the language — export to expose, import to pull in, one scope per file, and dependencies are known at compile time.

How it differs from CommonJS, Node’s older scheme — this is the part being tested:

Why does “resolved at compile time” matter? Because a bundler can see who uses what without running the code, so it can drop exports nobody imported (tree shaking) and split code. That is ESM’s real practical value, not prettier syntax.

Follow-up: “Named exports or a default export?” — a default export puts no constraint on the name, since an importer can call it anything, which hurts search and autocomplete; named exports are friendlier to tree shaking and refactoring. In practice: default for “one file, one main thing”, named for a bag of utilities.
“How do you use ESM in Node?” — "type": "module" in package.json, or name the file .mjs. That is why Jest needs --experimental-vm-modules in the Federation course.