Why does [...user] throw a TypeError when user is a plain object, while {...user} copies its properties without complaint?

## Same three dots, two unrelated operations The `...` token appears in several places in the grammar and does a different job in each. Two of them look alike and behave nothing alike. **Array and argument spread** — `[...x]`, `f(...x)`, `new C(...x)` — is defined in terms of iteration. The engine gets an iterator from `x` and drains it, appending each produced value. **Object spread** — `{ ...x }` inside an object literal, standardised in ES2018 — is defined in terms of *property copying*. It performs the same abstract operation as `Object.assign` on the target: it reads the source's own enumerable string-keyed and symbol-keyed properties and defines matching own properties on the new object. One asks "can I walk you as a sequence?", the other asks "what own properties do you have?". A plain object answers the second question happily and cannot answer the first at all. ## Why the array form throws Spreading into an array is roughly: ```js const out = []; const it = user[Symbol.iterator](); // TypeError here for a plain object let step; while (!(step = it.next()).done) out.push(step.value); ``` `user[Symbol.iterator]` evaluates to `undefined`, calling `undefined` is a `TypeError`, and it is thrown before a single element is produced. The exact message text is engine-specific — V8 says `user is not iterable` — so assert on the error type, not the string. The same failure hits every other iteration consumer for the same reason: `for (const x of user)`, `const [a] = user`, `new Set(user)` and `Promise.all(user)` all throw on a plain object. ## Why the object form does not ```js const user = { id: 1, name: 'Ada' }; const copy = { ...user }; // { id: 1, name: 'Ada' } const empty = { ...42, ...null }; // {} — no properties to copy, no error ``` Object spread tolerates primitives and even `null`/`undefined` sources: there is simply nothing to copy. It is a *shallow* copy — nested objects are shared by reference — and it copies values, so a getter on the source is invoked once and its result stored as a plain data property on the target. Non-enumerable properties and anything inherited from the prototype chain are skipped. ## Getting an array out of a plain object The three static helpers each answer a different question, and all three return genuine arrays that spread and loop normally: ```js Object.keys(user); // ['id', 'name'] Object.values(user); // [1, 'Ada'] Object.entries(user); // [['id', 1], ['name', 'Ada']] ``` Note that these consider only *own enumerable string-keyed* properties, so symbol keys and inherited properties are excluded — a different filter from what array spread would have applied had the object been iterable, and worth stating out loud in an interview. ## Making the object itself iterable If the object models a collection rather than a record, the honest fix is to implement the protocol. The cheapest implementation delegates to something already iterable: ```js const bag = { items: ['a', 'b'], [Symbol.iterator]() { return this.items[Symbol.iterator](); } }; [...bag]; // ['a', 'b'] for (const x of bag) {} // works const [first] = bag; // 'a' ``` One method makes the object work with every consumer at once. Note the reverse does *not* hold: adding `Symbol.iterator` changes nothing about `{ ...bag }`, which still copies `items` and the symbol-keyed method rather than producing elements. ## The array-like near-miss A frequent follow-on is an object with a `length` and numeric keys, such as `{ length: 2, 0: 'a', 1: 'b' }`. It looks like an array, and older index-based helpers like `Array.prototype.slice.call(x)` handle it, but it has no `Symbol.iterator`, so `[...x]` still throws. `Array.from(x)` accepts it, because `Array.from` falls back to the length/index reading when the iteration protocol is unavailable. That asymmetry is the reason `Array.from` and spread are not interchangeable. ## What this tells you at a glance When you see "X is not iterable" in a stack trace, the diagnosis is mechanical: something reached for `Symbol.iterator` on a value that has none. The usual culprits are a plain object where an array was expected, a value that is `undefined` because a fetch or a destructuring default did not fire, or an API that returned a record when the caller assumed a list.