Closing the previous lesson left a very concrete to-do list: finding the first task that meets a condition cost you an entire function, grouping by status cost you a loop inside another one, the summary cost you three accumulator variables, and sorting the board by due date you did not even know how to do. All those operations are so universal that JavaScript ships them ready-made and with names of their own. In this lesson you will learn the full arsenal for querying a list: find, findIndex, findLast, some, every and filter for searching and selecting; sort for ordering —with the language's most famous trap, the one that makes [10, 9, 100] sort wrongly—; and reduce, the most powerful and worst-explained tool of them all, which we will take slowly and through four real cases. At the end you will assemble the Taller Nómada weekly workload report, the deliverable Marta has been asking for since Module 1.

1. The starting point: the canonical backlog
2. Finding one element: find, findIndex, findLast
3. Checking the whole set: some and every
4. Selecting several: filter
5. The searching table
6. sort: the numbers trap
7. The comparator function
8. Sorting by number, by text and by date
9. Descending order and sorting by several criteria
10. toSorted and toReversed: sorting without mutating
11. reduce, slowly
12. Four real cases of reduce
13. Object.groupBy, Map and Set
14. Chaining filter().map().sort() and its cost
15. Worked example: the weekly workload report
16. Common Mistakes and Tips
17. Exercises
18. Conclusion

Everything that follows works on the same backlog from 04-01. We repeat it in compact form to keep it at hand:

Every method in this lesson takes a function as an argument: they are the higher-order functions you studied in 03-06. The function that returns true or false to decide whether an element "counts" is called a predicate.

find(predicate) returns the first element that meets the condition, or undefined if there is none. And it stops as soon as it finds it.

Compare it with the function you wrote by hand in exercise 2 of the previous lesson:

The only behavioral difference is that find returns undefined where your function returned null. Since the result may not exist, always protect yourself with ?. or ??:

findIndex(predicate) returns the position instead of the element, or -1:

It is what you need when you are going to modify the array by position, for example with splice:

findLast and findLastIndex do the same thing walking from the end:

Remember, too, the limitation of includes and indexOf you saw in 04-03: they compare with === and are therefore no use with objects. find is, because you write the comparison yourself:

Sometimes you do not want the element, but a yes-or-no answer about the whole list.

Both short-circuit, just like the && and || operators from 01-06: some stops at the first true, every stops at the first false. That makes them the correct —and fastest— way to validate.

Two behaviors with an empty array that are surprising and worth knowing:

That true is called vacuous truth and is mathematically correct ("every unicorn on this list is blue" is true if the list is empty). In code, keep it in mind: every over an empty list never flags anything.

Applied to the project, validating the backlog before saving it:

filter(predicate) returns a new array with every element that meets the condition. It does not mutate the original and, unlike map, the length of the result does change.

That last detail matters: filter never returns undefined, always an array (possibly empty). That is why filter(...).length === 0 is the correct check, and not if (result), which would always be true because an empty array is truthy (01-07).

Differences from find, which are often confused:

A frequent mistake is using filter when you wanted find:

Let us start with the disaster, because it is the best way to make sure you never forget it:

This is not an engine bug. sort() with no arguments converts every element to a string and compares them alphabetically, character by character. Since '1' comes before '2' and '2' before '9', the result is dictionary order: '1', '10', '100', '25', '9'.

And there is a second, equally important trap: sort mutates the original array, as the 04-03 table already warned.

Two rules follow from this, and you should always apply them:

1. Always pass sort a comparator function. No exceptions, not even with numbers.
2. Copy before sorting, unless you really do want to mutate: array.slice().sort(cmp) or, better, array.toSorted(cmp).

The comparator receives two elements and returns a number answering the question "which one comes first?":

The a - b trick works because the subtraction already produces the right sign: if a is smaller, the subtraction is negative. It only works with numbers; with strings you have to compare some other way (section 8).

A comparator written out the long way, to see what happens inside:

And a warning: the comparator must be consistent. If you say A comes before B and also that B comes before A, the result is unpredictable. Never use Math.random() inside a comparator to "shuffle": it can produce biased orderings or even errors.

By number (the case of estimatedHours and id):

By text. Subtraction is no use with strings ('a' - 'b' is NaN). And the < operator compares by character code, which misplaces capitals and accents. The correct answer is localeCompare, which compares according to the language's rules:

localeCompare returns a negative number, zero or a positive number: exactly what sort needs. The second argument is the language; the third accepts options such as { sensitivity: 'base' } to ignore case and accents:

By date. Here a design decision from Module 1 pays off: dueDate is an ISO string 'yyyy-mm-dd', and that format sorts alphabetically exactly as it sorts chronologically. So comparing strings is enough:

With the format '30/09/2026' this would be impossible without converting each date first. That is exactly why the model chose ISO.

To reverse the order, reverse the comparator (do not sort and then apply reverse, which is two passes for nothing):

When there are ties, you move to the next criterion. The technique is to evaluate the first criterion and, if it gives 0, return the second:

Notice the PRIORITY_ORDER object: it is the same lookup dictionary pattern from 04-01, used here to turn a piece of text ('high') into a sortable number. Without it, 'high' < 'low' < 'medium' would give alphabetical order, which is not what Marta wants.

With more than two criteria, the pattern generalizes by chaining with ||, taking advantage of 0 being falsy:

Read it like this: "use the first criterion; if it gives 0, try the second; if that gives 0 too, the third". It is a direct application of the || short circuit you studied in 01-06.

One last detail: since ES2019, sort is stable, which means elements that tie keep their original order. That is why sorting first by date and then by priority also produces a correct result, although the combined criterion is clearer.

You have been using them throughout the previous section. They are the immutable versions of sort and reverse, available in modern JavaScript:

If you work in an older environment that does not have them, the equivalent is to copy first: array.slice().sort(cmp). What you must never do is sort the backlog itself just to display it a particular way: the data list and the presentation list are different things.

reduce is the most powerful method in the arsenal and the one most poorly explained. The idea, in one sentence:

reduce walks the array carrying an accumulated value, and returns that value at the end.

Nothing more, nothing less. It is exactly the accumulator pattern you learned in 02-02, packaged into a method. Its signature has two parts:

The simplest version, adding up hours, compared with the equivalent loop:

The piece-by-piece correspondence:

Let us follow the execution pass by pass, which is the only way to really understand it:

Why the initial value matters so much. If you leave it out, reduce uses the first element as the initial accumulator and starts walking from the second. With loose numbers that still works; with objects, it does not:

And there is a worse case still: with no initial value, an empty array throws an error.

Rule with no exceptions: always supply the initial value. And choose it carefully: 0 to add, 1 to multiply, '' to concatenate, [] to build a list, {} to build an object.

The other classic mistake, already flagged in 03-06, is forgetting to return the accumulator:

Case 1: summing with a condition and a weight. The backlog's weighted effort, the number 124 you have been carrying since Module 3:

Case 2: counting by status. The accumulator is an object:

Two details of the code: acc[t.status] uses brackets because the key is in a variable (04-01), and (acc[...] ?? 0) handles the first occurrence, when the key does not exist yet and would return undefined.

Case 3: grouping tasks by assignee. The accumulator is an object whose values are arrays:

And the variant Marta cares about, grouping while adding up hours instead of accumulating tasks:

25 + 6 + 14 = 45, the backlog's open hours. It is exactly what you did by hand with loops in exercise 3 of 04-02, now in five lines.

Case 4: building an index by id. The dictionary you assembled with a for in 04-01:

Why bother? Because backlog.find((t) => t.id === 3) walks the list every time you search, whereas index[3] is a direct access. With six tasks it makes no difference; in Module 9 you will see when it starts to matter.

A style warning, one we also made in 03-06 about higher-order functions: reduce is not always the best option. If what you write with reduce is harder to read than the equivalent loop, write the loop. reduce shines at sums, counts, groupings and indexes; it becomes unreadable when someone uses it to do what map or filter do.

Object.groupBy (modern JavaScript) does exactly case 3 without reduce:

It is more readable than the equivalent reduce, but it is recent: check your environment's support before using it in production (in Module 8 you will see how such things are checked). There is also Map.groupBy, which returns a Map instead of an object.

Set is a collection with no duplicates. It is the answer to the question we left open in 04-03: how to deduplicate the backlog's tags.

The idiom Array.from(new Set(array)) is the standard way of removing duplicates in JavaScript, and it is worth memorizing.

Map is a dictionary whose keys can be of any type, which preserves insertion order and knows how many entries it holds:

When to choose each structure:

Since filter, map, toSorted and flatMap return arrays, they can be chained, and the result reads almost like a sentence:

Read it top to bottom: keep the open high-priority ones, sort them by date, turn them into text. Each step has a name and can be read on its own, which is exactly what you were after in 03-06 with filter → transform → aggregate.

The cost: each link in the chain walks the whole array and creates a new one. Three chained methods are three walks and two intermediate arrays, whereas a for would do a single pass without creating anything.

With six tasks, the difference is literally imperceptible. With hundreds of thousands of elements it starts to show, and that is where the techniques of Optimizing JavaScript Performance come in. The advice, today: chain and prioritize readability, and optimize only when you measure that it is needed. One free detail: put the filter first in the chain, so the following steps work on fewer elements.

Marta opens the panel every Monday and wants a complete snapshot of the backlog. With what you have learned, it fits into one function.

Output:

Go over which method solves each block: filter for the open and overdue ones, reduce for the three totals and for the workload per person, toSorted with localeCompare for ordering by date and by text, slice(0, 3) to keep the next three due dates, flatMap + Set for the unique tags, and Object.entries + toSorted to order the workload object by descending hours. Compare it with the report engine you assembled in 03-06 over parallel arrays: the logic is the same, but it fits on one screen and it reads.

(The line const { totals, workload, ... } = report; is object destructuring, and it is the subject of 04-07. For now read it as "pull these properties out into separate variables".)

1. Calling sort() with no comparator. It sorts as text: [10, 9, 100] becomes [10, 100, 9]. Always pass (a, b) => a - b or whatever comparator fits.

2. Forgetting that sort and reverse mutate. Use toSorted/toReversed, or copy with slice() first.

3. Omitting the initial value of reduce. With objects it produces garbage and with empty arrays it throws a TypeError.

4. Forgetting the return in the reducer. The accumulator becomes undefined and everything blows up on the next pass.

5. Using filter(...)[0] instead of find(...). It walks the entire list just to keep one item.

6. Checking the result of filter with if (result). An empty array is truthy: it will always pass. Check result.length === 0.

7. Comparing strings with < instead of localeCompare. With accents and capitals you get incorrect orderings.

8. Using every over an empty list as validation. It always returns true. Check first that the list is not empty if that matters.

9. Chaining ten methods over huge lists. Each link is a walk and a new array. Readability first; optimize when you measure (Module 9).

Professional tip. These methods are a vocabulary, and using it well is above all about saying what you want. If the method's name matches what you would say out loud —"find me the first one", "keep the high-priority ones", "add up the hours"— the code is fine. If you have to explain a twelve-line reduce, there was probably a loop there.

Exercise 1 — Monday's queries. With the canonical backlog, solve each point in a single expression:

1. The task with id 5.
2. Is there any of Lucía's tasks with no reviewer?
3. Do all the open tasks have at least one tag?
4. The titles of the medium-priority tasks.
5. The last task (walking from the end) that is in progress.

Exercise 2 — The workload ranking. Write workloadRanking(tasks) returning an array of objects { assignee, tasks, hours, overdue } with one entry per person, counting open tasks only, sorted by descending hours and, in case of a tie, by name. Use reduce to group and toSorted with a double criterion. Check that Iván comes first with 25 h and 1 overdue task.

Exercise 3 — Balanced distribution. Marta wants to know whether the work is evenly spread. Write isBalanced(tasks, headroom) returning true if the difference between the open hours of the most loaded and the least loaded person does not exceed headroom. Also return, in an object, { balanced, max, min, difference }. Try it with headroom = 10 and with headroom = 20.

Exercise 1

Frequent mistakes in this exercise: using filter in point 1 (it walks too far and returns an array), and in point 3 applying every to the whole backlog instead of to the open tasks, which answers a different question.

Exercise 2

Three things worth commenting on. First: the accumulator is an object of objects, and at the end Object.values turns it into the array the brief asks for. Second: inside the reduce the accumulator object is mutated, and that is fine because that object was created inside the function itself and nobody else shares it; mutating is a problem when it affects data from outside. Third: notice that Marta shows up with 1 task and 6 h, not 2: her "Screen-printing ink inventory" is done and the initial filter discards it.

Exercise 3

Two notes. The maximum pattern with reduce is the same one from 02-02, and the initial value is values[0] instead of 0 because with a fixed 0 the minimum would always come out as 0. And the empty-list check is essential: without it, values[0] would be undefined and every comparison would be false. That kind of edge case is exactly what you will test systematically in Module 8 with Jest.

With headroom = 10 the distribution is not balanced: Iván piles up 25 h against Marta's 6 h. That is precisely the diagnosis Marta needed in order to redistribute the backlog.

You now have the full arsenal for querying a list. For searching: find and findIndex when you want an element or its position, findLast and findLastIndex when you care about the most recent one, some and every when the answer is a yes or a no —with their short circuit and with the empty-array trap—, and filter when you want a sublist, remembering that it always returns an array and that an empty array is truthy.

For sorting, sort with its two traps burned into memory: with no comparator it sorts as text ([10, 9, 100] → [10, 100, 9]) and it mutates the original. The comparator returns negative, zero or positive; a - b for numbers, localeCompare for text, plain string comparison for ISO dates —the reward for that Module 1 design decision—, the flipped subtraction for descending order and chaining with || for several criteria. And toSorted/toReversed so as not to destroy the data while building a view.

For aggregating, reduce, genuinely understood: it is the accumulator pattern with a name, its reducer must always return the accumulator and its initial value is not optional. You have used it in the four cases that cover 90% of what you will need: summing (48 h, 45 h open, effort 124), counting by status, grouping by assignee (Iván 25 h, Lucía 14 h, Marta 6 h) and building an index by id. Alongside it, Object.groupBy for effortless grouping, Set for deduplicating the 12 tags down to 11 unique ones and Map for dictionaries with dynamic keys. And you know how to chain filter().toSorted().map() while knowing what each link costs. The Taller Nómada weekly workload report, the deliverable outstanding since Module 1, is now written.

If anything has recurred suspiciously in the last few pages, it is lines like pair[0] and pair[1] when walking Object.entries, or const [removed] = tasks.splice(...), or const { totals, workload } = report. They all point to the same thing: there is a syntax for unpacking an array or an object into named variables, and you have been using it in passing for three lessons without ever studying it. We start with the easier half in Array Destructuring, where you will learn to split a dueDate into year, month and day in a single line, to swap variables without a helper and to finally write for (const [i, task] of backlog.entries()) understanding exactly what it means.