Searching and Predicate Methods

## What the two methods actually do `find` and `findIndex` are the predicate-driven search methods on `Array.prototype`. Both accept a callback (the *predicate*) and an optional `thisArg`. The predicate is invoked as `callback(element, index, array)` for each index from `0` upward. Iteration stops at the first index where the predicate returns a **truthy** value — not strictly `true`, any truthy value counts, so a predicate ending in `return u.name` "matches" on any non-empty name. The only difference is what comes back: - `find` returns the matching **element**; if the predicate never returns truthy, it returns `undefined`. - `findIndex` returns the matching **index**; on a miss it returns `-1`. ```js const users = [{ id: 7 }, { id: 9 }]; users.find(u => u.id === 9); // { id: 9 } users.findIndex(u => u.id === 9); // 1 users.find(u => u.id === 42); // undefined users.findIndex(u => u.id === 42);// -1 ``` ## Why -1 is the classic bug JavaScript coerces the search result to a boolean whenever you drop it into an `if`. `-1` is a non-zero number, so it is **truthy**. `0` — a perfectly valid "found at the first position" answer — is **falsy**. That makes a bare truthiness test wrong in both directions: ```js if (users.findIndex(u => u.id === 42)) { // runs, even though nothing matched: -1 is truthy } if (users.findIndex(u => u.id === 7)) { // does NOT run, even though it matched at index 0 } ``` The correct form is an explicit comparison: `findIndex(...) !== -1`, or `>= 0`. The identical trap applies to `indexOf`, `lastIndexOf` and `String.prototype.indexOf`, which is why a boolean-returning membership check is preferred when you only need presence. ## Why undefined is the other bug `find` returning `undefined` on a miss means the very common chain `arr.find(p).prop` throws `TypeError: Cannot read properties of undefined` the moment the data does not contain the row you assumed was there. That is one of the most frequent production stack traces in JavaScript codebases: the code works against the developer's seed data and blows up on a user whose record is missing. Capture the result and branch on it, or use optional chaining plus a default, or throw a domain error that names the missing key so the log is diagnosable. There is also an ambiguity: `undefined` can be a genuine array element. `[undefined].find(x => x === undefined)` returns `undefined` — indistinguishable from a miss by the return value alone. When the array can hold `undefined`, use `findIndex` and compare with `-1`, because `-1` is not a valid index and therefore unambiguous. ## Searching from the other end ES2023 added `findLast` and `findLastIndex`, which use the same predicate contract but iterate from the highest index downward and return the **last** match (`-1` / `undefined` on a miss, same as their forward twins). Before ES2023 the common workaround was to reverse the array first, which introduced its own bug: `Array.prototype.reverse` mutates in place, so `arr.reverse().find(p)` silently reorders the caller's array. `findLast` removes the need for that entirely. ## Holes and mutation during the scan Unlike `some`, `every` and `indexOf`, the `find` family does **not** skip holes in a sparse array. It reads every index from `0` to `length - 1`, so a hole is handed to the predicate as `undefined`: ```js Array(3).findIndex(x => x === undefined); // 0 — holes are visited Array(3).some(x => x === undefined); // false — holes are skipped ``` The range of indices is fixed by the `length` captured when the call begins, so elements appended by the predicate itself are never visited; elements changed in place before their turn are seen with their new value. Predicates should be pure — a predicate with side effects turns a search into a construct whose result depends on iteration order. ## Choosing the right member of the family Use `find` when you want the object itself, `findIndex` when you need the position (to replace or remove by position, or to disambiguate a real `undefined` element), and a boolean-returning check when you only care whether anything matched. Reaching for a filtered array and then reading `[0]` or `.length` does the same job but keeps scanning after the answer is known and allocates an array you throw away.