forEach, and when a plain loop is clearer

Every loop so far has had the same shape: some machinery to walk the collection, wrapped around the bit that actually does the work. forEach inverts that. Instead of you walking the array, you hand the array a function and it does the walking, calling your function once for each element.

This is the first array method in the module, and the pattern it introduces is the whole rest of the module. map, filter, find, some, every and reduce all work the same way — you supply a small function, the method decides when and how often to call it. Get comfortable with the shape here, on the simplest of them, and the other six will feel familiar rather than magical.

A function you pass to another function like this is usually called a callback: you are not calling it yourself, you are handing it over to be called back later. Nothing mysterious is happening — it is an ordinary function value being passed as an argument, exactly as you saw in the functions module.

You write array.forEach(callback). The callback is usually an arrow function written inline, because it is small and only used once. forEach calls it once per element, in order from the first to the last, and passes the element in as the first argument.

Read array.forEach((item) => { ... }) as: for each item in array, do this. That is close enough to English that a reader who has never seen the method can guess it correctly — which is a real advantage over a counting loop whose meaning has to be reconstructed from a header.

One caveat worth knowing rather than discovering: forEach skips holes. An array can have genuinely empty slots in the middle, written as [1, , 3], and forEach passes over them without calling your function, while a for...of loop visits them and hands you undefined. Holes are rare and best avoided, but this is why two loops over the same array can disagree about how many elements there are.

forEach passes your callback three arguments in this order: the element, its index, and the whole array. You do not have to accept all three. A function that declares one parameter simply ignores the rest — that is ordinary JavaScript, not a special rule for callbacks.

The index is there for the cases where you do need a position: numbering output lines, treating the first item differently, comparing an item with the one before it. Take it when you need it and leave it out when you do not, because a parameter you never use is a small lie about what the code depends on.

The third argument, the array itself, is rarely useful — you almost always already have a name for that array. It matters mainly because it explains a famous trap you will meet in the next lesson, where a built-in function accepts a second argument that means something completely different from an index.

Writing break inside a forEach callback is a syntax error. break belongs to loops, and your callback is a function — from its point of view there is no loop to break out of. The engine rejects the program before it runs, which is at least an honest failure.

The subtler mistake is reaching for return instead. That is valid, and it does something, but not what you hoped: return ends the current call of the callback, so the next element is still visited. It behaves like continue, not like break. Code that uses return in a forEach believing it stops the iteration is doing all the remaining work anyway, silently.

So if you might need to stop early, do not use forEach. Use a for...of loop with break, or use one of the methods designed to stop on their own — find, some and every all short-circuit, and they are two lessons away.

forEach hands back undefined. Not the array, not the results of your callback — nothing. It exists purely for the effects your callback has: printing, pushing onto another array, updating a counter that lives outside the loop.

That is why const doubled = numbers.forEach((n) => n * 2) leaves doubled as undefined. The callback's return values are computed and thrown away. If what you want is a new array of results, you want map, which is the next lesson, and this specific confusion is the reason map is taught immediately after.

It is also why you cannot write array.forEach(...).filter(...): there is no array on the left of that second dot, only undefined, and reading .filter from undefined throws a TypeError.

forEach is not automatically better than for...of. Prefer a plain loop when you might need to stop early, because forEach cannot; when the body is long enough that a nested function adds a layer of indentation without adding meaning; and when you are working with something that is iterable but is not an array, since forEach is an array method and a plain string does not have one.

Prefer forEach when the body is short, when you are already in the middle of a chain of array methods and want to keep the same rhythm, and when handing the job to the array genuinely reads better than describing the walk yourself.

There is one more honest reason to reach for a plain loop that has nothing to do with performance: a for...of loop is the easiest thing in JavaScript to step through in a debugger, because there is no extra function call between you and the body. When you are trying to work out why something is wrong, that matters more than elegance.

forEach runs a function once per element, passing the element, its index and the array. It returns undefined, so it cannot be chained and cannot collect results. break is a syntax error inside it and return acts like continue, so it cannot stop early — use for...of with break, or find/some/every, when that matters. It skips holes in sparse arrays. Choose it for short bodies and effects; choose a plain loop for early exits, long bodies, and easier debugging.