for...of and for...in: items and keys

Look back at the counting loop from the last lesson. Three-quarters of it is bookkeeping: declare a counter, compare it to a length, add one to it, then use it to look a value up. Only the last part had anything to do with the job. The counter existed to reach the items, not because anybody cared about positions.

That bookkeeping is also where the bugs live. Every off-by-one, every accidentally reversed comparison, every counter that was incremented twice — none of those are possible in a loop that has no counter. So JavaScript has a loop that hands you each item directly and manages the position itself.

Think of the difference between being told 'the folder is third from the left in the second drawer' and having someone put the folder in your hands. Both get you the folder. Only one of them can send you to an empty slot.

for...of is the second one. You name the variable you want each item to arrive in, you name the collection, and the loop does the rest. There is no position to get wrong, and the loop stops exactly when the collection runs out.

The shape is: for (const item of collection) followed by a block. On each pass, item holds the next value. Use const for the item variable, because you are not reassigning it — a fresh binding is created for each pass, so const is not a problem here even though the value differs every time.

for...of works on anything JavaScript calls iterable, which for now means arrays and strings, and later Map and Set from the data-modelling module. Iterating a string gives you its characters one at a time, which is genuinely useful and saves you from indexing into text by hand.

It is not a loop for plain objects. Writing for (const value of someObject) throws a TypeError, because a plain object does not describe how to step through itself. That is not a gap you need to work around — it is what for...in and Object.keys are for, and they are next.

break and continue behave exactly as they did in a for loop. break leaves immediately, continue moves to the next item. This matters: it is the reason a for...of loop is still the right answer when you might need to stop early, even after you learn the array methods later in this module.

An object is a set of named properties, and sometimes you need to visit all of them without knowing their names in advance — summing every value in a record of scores, say. for (const key in someObject) does that. On each pass, key holds the name of one property, and you read the value with someObject[key].

Two facts about those keys decide how you use them. First, they are always strings, even when they look like numbers. Second, for...in visits inherited enumerable properties as well as the object's own — properties that come from further up the prototype chain, not from the object literal you wrote. For the plain object literals in this module there is nothing inherited to worry about, but when you start working with objects other code created, the defensive form is to test each key with Object.hasOwn(someObject, key) and skip the ones that fail.

The order is defined: integer-like keys come first, in ascending numeric order, and then the remaining string keys in the order they were added to the object. So an object written as b, a, 2, 1 is visited as 1, 2, b, a. Do not lean on that if you can help it — code that depends on key order is fragile for the humans reading it even when the engine agrees — but you should not be surprised by it either.

for...of and for...in look almost identical, and swapping them on an array produces a bug that runs without complaint. for...in over an array gives you its indices — and because for...in keys are always strings, those indices arrive as "0", "1", "2" rather than 0, 1, 2.

The damage shows up the moment you do arithmetic. With a string index, index + 1 is not 1, it is the text "01", because + on a string concatenates. A total built that way turns into a long piece of nonsense text instead of a number, and nothing throws an error to tell you.

There is a second reason to avoid it: for...in visits every enumerable property, and an array is an object, so any extra property somebody attached to it is visited too. Use for...of when you want the values and a counting for loop when you genuinely need the positions as numbers.

Three loops, three questions. Do I need each value? for...of. Do I need each property name of an object? for...in, or Object.keys if you want an array of names you can work with. Do I genuinely need the numeric position — because I am comparing neighbours, or stepping two at a time, or counting backwards? Then a counting for loop, and only then.

Choosing the narrowest loop that does the job is not stylistic fussiness. A loop with no counter cannot have a counter bug, and a reader who sees for...of knows immediately that positions are irrelevant here. The loop you choose is a message to the next person about what the code cares about.

for...of gives you values, works on arrays and strings, needs no counter and cannot run off the end. It throws a TypeError on a plain object. for...in gives you property names as strings, includes inherited enumerable properties, and visits integer-like keys first. Using for...in on an array hands you string indices and is almost always a mistake. break and continue work in both.