Arrays & Collections

A JavaScript array is an ordinary object whose keys happen to be the strings "0", "1", "2"… plus a special length property that the engine keeps in sync. Its methods fall into two families: methods that edit the array in place and methods that leave it alone and hand you something new. Mixing them up is the source of most array bugs — sorting a prop in React, splice-ing an array another part of the code is still iterating, or expecting push to return the array.

The most important column: does it change the original array?

Read the "Returns" column as carefully as the "Mutates?" column. sort and reverse return the same array object they were called on, so const sorted = arr.sort() gives you two names for one array — sorted === arr is true, and the original order is gone. push returns the new length, not the array, which is why return arr.push(x) inside a reduce is a classic bug. And "❌" only means the array isn't changed: map and slice copy the slots, but if those slots hold objects, the new array points at the same objects (a shallow copy — see Shallow vs deep copy).

These are the three workhorse higher-order functions: each takes a callback, calls it once per element, and builds a result from what the callback returns. None of them changes the original array. That's the point — instead of writing a for loop that pushes into a result variable, you describe what each element becomes, and the method handles the looping and the result array.

A useful mental model is a production line. map is a station that reshapes every item (same number in, same number out). filter is a gate that lets some items through (same or fewer out, each unchanged). reduce is the packing station at the end that folds everything into a single thing — a number, an object, a string, even another array.

All three pass the callback the same arguments: (element, index, array). reduce adds one in front: (accumulator, element, index, array).

const products = [
  { name: "Laptop", price: 1200, inStock: true },
  { name: "Mouse", price: 25, inStock: false },
  { name: "Monitor", price: 300, inStock: true },
];

// map: transform every item → same length
const names = products.map((p) => p.name); // ["Laptop", "Mouse", "Monitor"]

// filter: keep items that pass → same or shorter
const available = products.filter((p) => p.inStock);

// reduce: boil the array down to one value
const total = products.reduce((sum, p) => sum + p.price, 0); // 1525

const inStockNames = products
  .filter((p) => p.inStock)
  .map((p) => p.name.toUpperCase()); // ["LAPTOP", "MONITOR"]

// Count occurrences
const fruits = ["apple", "banana", "apple", "cherry", "apple"];
const counts = fruits.reduce((acc, f) => {
  acc[f] = (acc[f] ?? 0) + 1;
  return acc;
}, {}); // { apple: 3, banana: 1, cherry: 1 }

// Index by id
const byName = products.reduce((acc, p) => ({ ...acc, [p.name]: p }), {});

// Max value
const priciest = products.reduce((max, p) => (p.price > max.price ? p : max));

console.log(["1", "2", "3"].map(parseInt));

Both take a test function, but they answer different questions. filter asks "which items pass?" and always returns an array. find asks "what's the first item that passes?" and returns that item itself (or undefined). Think of filter as a search that collects every result, and find as one that stops at the first hit.

const users = [
  { id: 1, name: "Rohit", admin: true },
  { id: 2, name: "Sam", admin: false },
  { id: 3, name: "Ana", admin: true },
];

users.find((u) => u.admin);    // { id: 1, name: "Rohit", admin: true }
users.filter((u) => u.admin);  // [Rohit, Ana]
users.find((u) => u.id === 9); // undefined

find gives you the item; sometimes you need where it is instead — to replace it, remove it, or insert next to it. findIndex is the position-returning twin of find, and findLast / findLastIndex do the same searches starting from the end. The "not found" values are what trips people up: the index methods return -1, the item methods return undefined.

const nums = [5, 12, 8, 130, 44];

nums.findIndex((n) => n > 10);     // 1   (12)
nums.findLast((n) => n > 10);      // 44
nums.findLastIndex((n) => n > 10); // 4
nums.findIndex((n) => n > 500);    // -1

// Typical use: update an item in place
const i = users.findIndex((u) => u.id === 2);
if (i !== -1) users[i] = { ...users[i], name: "Samuel" };

These answer yes/no questions about the whole array. some is a logical OR across the elements ("does at least one pass?"), and every is a logical AND ("do they all pass?"). Both return a plain boolean, and both are lazy in the same way || and && are: once the answer is decided, they stop.

const ages = [19, 22, 17, 30];

ages.some((a) => a < 18);   // true  — at least one minor
ages.every((a) => a >= 18); // false — not all adults

[].some(() => true);  // false
[].every(() => false); // true — "vacuous truth": no item fails

Two methods with almost the same name and opposite behaviour, which is why interviewers love them. slice is a photocopier: it copies a range out of the array and leaves the original alone. splice is surgery: it cuts items out of the array itself, optionally stitches new ones in at the same spot, and hands you back what it removed.

Both take a start index, and both accept negative numbers counting from the end (-1 is the last element). The second argument is where they differ: for slice it's an end index (exclusive), for splice it's a count of items to delete.

const a = [1, 2, 3, 4, 5];
a.slice(1, 3);  // [2, 3]
a.slice(-2);    // [4, 5]
a.slice();      // shallow copy
a;              // [1, 2, 3, 4, 5] unchanged

const fish = ["parrot", "anemone", "blue", "trumpet", "sturgeon"];
const removed = fish.splice(2, 2);
// fish    → ["parrot", "anemone", "sturgeon"]
// removed → ["blue", "trumpet"]

fish.splice(1, 0, "clown"); // insert, delete nothing
// ["parrot", "clown", "anemone", "sturgeon"]

ES2023 added non-mutating twins of the mutating methods. They're perfect for React state, where you must not mutate.

Before these existed, the non-mutating version of sort was "copy, then sort the copy": [...arr].sort(fn). Forgetting the copy was an easy, silent bug — the original array (often a prop or Redux state) got reordered underneath everything else that held it. The new methods bake the copy in. Each one returns a new array and never touches the original, and the names map one-to-one: sort → toSorted, reverse → toReversed, splice → toSpliced, and arr[i] = x → arr.with(i, x). They're in Node 20+ and all current browsers.

const scores = [30, 10, 20];

scores.toSorted((a, b) => a - b); // [10, 20, 30]
scores.toReversed();              // [20, 10, 30]
scores.toSpliced(1, 1);           // [30, 20]
scores.with(0, 99);               // [99, 10, 20] — replace one index
scores;                           // [30, 10, 20] — untouched

const arr = ["a", "b", "c"];
delete arr[1];
arr;        // ["a", <empty>, "c"] — leaves a hole
arr.length; // 3 — length doesn't change

// Remove properly — pick ONE of these:
arr.splice(1, 1);                            // option 1: mutates arr
const next = arr.toSpliced(1, 1);            // option 2: new array, arr untouched
const next2 = arr.filter((_, i) => i !== 1); // option 3: new array, arr untouched

sort has two surprises. First, it mutates the array and returns the same object. Second, with no comparator it converts every element to a string and orders them by UTF-16 code units — dictionary order on characters, not numeric order. That default made sense for the original use case (sorting words) and can't be changed now without breaking the web.

A comparator is a function (a, b) => number that the engine calls on pairs of elements while it sorts. You don't control which pairs or in what order (that's up to the engine's algorithm — V8 uses TimSort); you only answer "which of these two goes first?". Negative means a first, positive means b first, 0 means "equal, keep their current order".

[10, 1, 5, 100].sort();               // [1, 10, 100, 5] 😬 — default sort compares strings
[10, 1, 5, 100].sort((a, b) => a - b); // [1, 5, 10, 100]
[10, 1, 5, 100].sort((a, b) => b - a); // [100, 10, 5, 1]

// Strings: use localeCompare for proper alphabetical order
["résumé", "apple", "Zebra"].sort((a, b) => a.localeCompare(b));

// By a property, then by another
people.sort((a, b) => a.lastName.localeCompare(b.lastName) || a.age - b.age);

flat removes nesting: it takes an array that contains arrays and pours the inner elements up into the outer one. The depth argument says how many levels of brackets to remove (default 1). flatMap is map followed by flat(1) in a single pass — useful when each input should produce zero, one or many outputs, which plain map (always exactly one) can't express.

[1, [2, [3, [4]]]].flat();          // [1, 2, [3, [4]]]  — depth 1 by default
[1, [2, [3, [4]]]].flat(2);         // [1, 2, 3, [4]]
[1, [2, [3, [4]]]].flat(Infinity);  // [1, 2, 3, 4]

// flatMap = map then flat(1) — map one item to zero or many
const sentences = ["hello world", "hi there"];
sentences.flatMap((s) => s.split(" ")); // ["hello", "world", "hi", "there"]

// Filter and map in one pass: return [] to drop an item
[1, 2, 3, 4].flatMap((n) => (n % 2 ? [] : [n * 10])); // [20, 40]

Array.from(iterableOrArrayLike, mapFn?) builds a real array from anything iterable (Set, Map, string, NodeList) or array-like ({ length: n }, arguments).

"Iterable" means the object has a Symbol.iterator method (see Iterators and the iteration protocol) — that's what for...of and spread use. "Array-like" means it just has a length and numbered keys, like the old arguments object. Array.from handles both, which is why it's the general-purpose "turn this into an array" tool. The optional second argument is a map function (value, index), applied as each element is created, so you don't need a separate .map() and an intermediate array.

Array.from("abc");                       // ["a", "b", "c"]
Array.from(new Set([1, 1, 2]));          // [1, 2]
Array.from(document.querySelectorAll("li")); // NodeList → Array

// Create an array and fill it with index + 1
Array.from({ length: 5 }, (_, i) => i + 1); // [1, 2, 3, 4, 5]
[...Array(5).keys()].map((i) => i + 1);     // same result
Array(5).fill(0);                            // [0, 0, 0, 0, 0]

// ✅ Each row is a new array
const grid = Array.from({ length: 3 }, () => Array(3).fill(0));
grid[0][0] = 1;
// [[1,0,0],[0,0,0],[0,0,0]]

// ❌ fill() puts the SAME array object in every row
const bad = Array(3).fill(Array(3).fill(0));
bad[0][0] = 1;
// [[1,0,0],[1,0,0],[1,0,0]] — all rows changed!

JavaScript has four common ways to walk an array, and they differ in what they give you, whether you can stop early, and how they behave with await. The short version: for...of is the default for arrays and every other iterable; drop to a classic for when you need the index for arithmetic; use forEach for simple synchronous side effects; and keep for...in for plain objects.

const numbers = [1, 2, 3, 4, 5];

for (const n of numbers) console.log(n);
numbers.forEach((n, i) => console.log(i, n));
for (const [i, n] of numbers.entries()) console.log(i, n);

const arr = ["apple", "banana", "cherry"];
arr.extra = "oops";

for (const fruit of arr) console.log(fruit); // apple banana cherry (values)
for (const key in arr) console.log(key);     // "0" "1" "2" "extra" (keys, as strings!)

const obj = { name: "John", age: 30 };
for (const key in obj) console.log(key, obj[key]); // fine for objects
for (const x of obj) {}                            // TypeError: obj is not iterable

A Set is a collection of values where each value can appear only once. Adding something that's already there does nothing. That makes "remove duplicates" a one-liner: pour the array into a Set (duplicates vanish on the way in) and pour it back out into an array.

function uniqueArray(array) {
  return [...new Set(array)]; // or Array.from(new Set(array))
}
uniqueArray([1, 1, 2, 3, 3]); // [1, 2, 3]

const tags = new Set(["js", "ts"]);
tags.add("js");        // ignored — already there
tags.has("ts");        // true — O(1), much faster than array.includes on big lists
tags.delete("ts");
tags.size;             // 1

// Set operations (ES2025 — modern browsers and Node 22+)
const a = new Set([1, 2, 3]);
const b = new Set([2, 3, 4]);
a.union(b);        // {1, 2, 3, 4}
a.intersection(b); // {2, 3}
a.difference(b);   // {1}

// Older equivalent
const intersection = new Set([...a].filter((x) => b.has(x)));

A Map is a key-value collection where keys can be any type — objects, functions, numbers — and insertion order is preserved.

Plain objects were the only dictionary JavaScript had for twenty years, and they're a poor one: every key is turned into a string (obj[1] and obj["1"] are the same slot, and an object key becomes "[object Object]"), they inherit properties like toString from Object.prototype, and getting the size means building an array of keys. Map (ES2015) is a purpose-built dictionary. Keys keep their real type and are compared with SameValueZero — so 1 and "1" are different keys, and an object key matches only that exact object.

The mental model: an object is a record with a fixed set of known fields (user.name, user.email); a Map is a lookup table whose keys come from data and change at runtime (cache.get(url), countsByUserId.get(id)).

const person = new Map([
  ["name", "John"],
  ["age", 30],
]);

person.set("occupation", "Developer");
person.get("name");   // "John"
person.has("age");    // true
person.delete("age");
person.size;          // 2

// Object keys — impossible with plain objects
const meta = new Map();
const btn = document.querySelector("button");
meta.set(btn, { clicks: 0 });
meta.get(btn).clicks++;

for (const [key, value] of person) console.log(key, value);
person.forEach((value, key) => console.log(key, value)); // note: value first

[...person.keys()];     // ["name", "occupation"]
[...person.values()];   // ["John", "Developer"]
[...person.entries()];  // [["name","John"], ["occupation","Developer"]]

// Convert both ways
const obj = Object.fromEntries(person);
const map = new Map(Object.entries(obj));
JSON.stringify([...person]); // serialise as an array of pairs

Like Map/Set, but keys must be objects, and they're held weakly: if nothing else references the key object, it can be garbage-collected and the entry disappears automatically.

(Since ES2023, symbols created with Symbol() are allowed as keys too; primitives such as strings and numbers, and registered symbols from Symbol.for, throw TypeError: Invalid value used as weak map key.)

Why does this exist? A normal Map holds on to its keys. If you use DOM nodes or objects as keys in a long-lived Map, those objects can never be garbage-collected while they're in the Map, even after the rest of your app has forgotten them — a memory leak. A WeakMap holds its keys weakly: the entry doesn't count as a reason to keep the key alive. Once the key object is unreachable from anywhere else, the garbage collector can remove the key and its value together. The value is kept alive only for as long as its key is.

The mental model is a sticky note attached to someone else's object. You can write data on the note and read it back as long as you're holding the object. When the object is thrown away, the note goes with it, and you never have to clean up.

// Private data per instance without memory leaks
const privateData = new WeakMap();

class User {
  constructor(name, password) {
    privateData.set(this, { password });
    this.name = name;
  }
  checkPassword(pw) {
    return privateData.get(this).password === pw;
  }
}

// Cache results per object; entries vanish when the object does
const cache = new WeakMap();
function expensive(obj) {
  if (!cache.has(obj)) cache.set(obj, heavyComputation(obj));
  return cache.get(obj);
}

// WeakSet: "have I seen this object?" — e.g. avoid processing a DOM node twice
const processed = new WeakSet();
function process(node) {
  if (processed.has(node)) return;
  processed.add(node);
}