Project: chaining transformations into a pipeline

Almost nothing real is one transformation. A report is: take the orders, keep the paid ones, pull out the fields that matter, put them in order, take the top few. That is four steps, and you now know a method for every one of them.

Because filter, map and slice all return arrays, each one can be called directly on the result of the last. That is chaining, and it is why these methods were designed to return new arrays instead of modifying the original. It is also why forEach — which returns undefined — can never appear in the middle of a chain.

This lesson is the project for the module. There is one exercise, and it is the whole pipeline. Everything you need is something you have already used on its own; the new skill is putting the steps in the right order and keeping the result honest.

A chain is written one method per line, indented under the array. Read it top to bottom and say what you are holding after each line: after the filter, still order objects but fewer of them; after the map, small summary objects; after the sort, the same objects rearranged; after the slice, only the first two.

If you cannot say what you are holding after a line, the chain is too clever and should be broken up. That is not a rule about length — a six-step chain of obvious steps is fine, and a two-step chain where one step does something surprising is not.

When you are debugging a chain that produces the wrong answer, the fastest move is to cut it in half: assign the first two steps to a const, print it, and check whether the data was already wrong before the step you suspected.

Two reasons, and the second is the important one. Filtering first means the map runs on fewer elements, which is a small saving. But filtering first is also often the only order that works: once you have mapped each order down to a customer name and a total, the status field is gone, and you can no longer filter on it. Transformations throw information away, so do your selecting while you still have everything.

Sorting comes after mapping when you sort on a field the map produced, and can come before it otherwise. Slicing goes last, because taking the top three only means anything once the order is decided.

There is one ordering trap worth naming: if your filter depends on a value your map computes, you cannot filter first — and that is usually a sign the map is doing two jobs. Compute the value in the map, then filter on it afterwards, and let the chain read in the order the work actually happens.

Array.prototype.sort is not like map and filter. It sorts the array IN PLACE and returns that same array, so orders.sort(...) rearranges the caller's data. In the middle of a chain that is harmless, because the array it is sorting was freshly made by the map above it. Called directly on data you were given, it is a bug — and a nasty one, because the damage happens somewhere else in the program.

The fix is to sort a copy: [...data].sort(...) or data.slice().sort(...). Newer engines also offer toSorted(), which returns a new array and never touches the original.

The second trap is the default comparison. With no comparison function, sort converts every element to a string and orders by text, so [10, 9, 100, 1] sorts to [1, 10, 100, 9] — correct alphabetical order for those strings, and useless for numbers. Always pass a comparator for numbers: (a, b) => a - b for ascending, (a, b) => b - a for descending. A comparator returns a negative number when a should come first, a positive number when b should, and 0 when they tie.

One guarantee you can rely on: the sort is stable, so elements the comparator calls equal keep their original relative order. That is what lets you sort by total and trust that two customers with the same total stay in the order they arrived.

Every link in a chain builds a whole new array. A four-step chain over a thousand orders allocates several thousand-element arrays and walks the data four times. A single for...of loop, or a single reduce, would walk it once and allocate one result.

For the sizes most code deals with — a page of results, a shopping basket, a list of files — that difference is unmeasurable, and choosing the less readable version to save it is a bad trade. Readability is the thing you will spend your time on; a few microseconds is not.

It stops being irrelevant in two situations: very large collections, and code that runs constantly, such as inside another loop or on every frame of an animation. If profiling shows a chain is genuinely hot, the fix is to fuse the steps into one pass. Do that when you have evidence, not in advance — a rewrite that is faster and wrong is worse than a chain.

There is no maximum chain length, but there is a test: can you read it aloud as one sentence? 'Take the paid orders, summarise each one, put the biggest first, keep the top two.' That is a sentence. If reading yours aloud requires stopping to work out what a step produces, split it.

Splitting costs nothing at runtime and buys you names. const paidOrders = ... and const summaries = ... turn the chain into a short story with labelled chapters, and each name is a place a debugger can stop and a reviewer can check. Long chains are not a sign of skill; well-named intermediate steps usually are.

filter, map and slice return new arrays, so they chain; forEach returns undefined and cannot. Filter before you map, because mapping throws away the fields you might need to filter on. sort mutates in place and returns the same array, so sort a copy unless the array was made by the step above; and always pass a comparator for numbers, because the default sorts as text. Sorting is stable, so ties keep their original order. Each link allocates a new array, which is almost always fine — fuse steps only when profiling says so.