
A regular expression is a small pattern language for matching text. JavaScript has it built in: you can write a pattern as a literal between slashes (`/foo/`) or construct one at runtime with `new RegExp("foo")`. Methods on strings and RegExp objects let you test, search, capture, and replace using those patterns.

<ExamplePair>
<ExampleProse>

`test` checks whether a pattern appears anywhere in a string and returns a boolean. `match` returns the matched text (and capture groups) or `null`. The `g` flag makes `match` return every occurrence instead of just the first.

</ExampleProse>
<ExampleCode>

```js
// test - returns true or false
console.log(/cat/.test("concatenate")); // true
console.log(/cat/.test("dog"));         // false

// match without g - first occurrence + index
const result = "hello world".match(/\w+/);
console.log(result[0]);     // "hello"
console.log(result.index);  // 0

// match with g - all occurrences as an array
const all = "hello world".match(/\w+/g);
console.log(all); // ["hello", "world"]
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Capture groups, written as `(...)`, let you extract specific parts of a match. `exec` returns a single match with its groups as array slots. Named groups (`(?<name>...)`) make the captured values accessible by name instead of by index, which keeps regex code readable when there are several groups.

</ExampleProse>
<ExampleCode>

```js
// Numbered capture groups
const numbered = /(\w+)@(\w+)/.exec("user@example");
console.log(numbered[1]); // "user"
console.log(numbered[2]); // "example"

// Named capture groups - much easier to read
const named = /(?<user>\w+)@(?<host>\w+)/.exec("user@example");
console.log(named.groups.user); // "user"
console.log(named.groups.host); // "example"

// matchAll iterates all matches including their groups
const emails = "a@b.com c@d.com";
for (const match of emails.matchAll(/(?<user>\w+)@(?<host>[\w.]+)/g)) {
  console.log(match.groups.user, match.groups.host);
}
// "a" "b.com"
// "c" "d.com"
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`replace` swaps matched text with a string or the return value of a function. Passing a function replacer is the most flexible form: it receives the full match plus any capture groups, so you can transform each match individually.

</ExampleProse>
<ExampleCode>

```js
// Simple string replacement (g flag replaces all)
const dashes = "2026-04-27".replace(/-/g, "/");
console.log(dashes); // "2026/04/27"

// Function replacer - called once per match
const words = "hello world";
const titled = words.replace(/\b\w/g, (char) => char.toUpperCase());
console.log(titled); // "Hello World"

// Function replacer with named groups
const date = "2026-04-27";
const reordered = date.replace(
  /(?<y>\d{4})-(?<m>\d{2})-(?<d>\d{2})/,
  (_, y, m, d) => `${d}/${m}/${y}`
);
console.log(reordered); // "27/04/2026"
```

</ExampleCode>
</ExamplePair>

<InProduction>
Catastrophic backtracking - where the regex engine exhausts every possible combination before giving up - can hang the event loop on user-supplied input. The classic trap is nested quantifiers like `(a+)+` applied to a string that nearly matches: the engine tries exponentially many paths. Anchor your patterns (`^` and `$`) where you can, keep quantifiers flat, and run any regex that touches untrusted strings through a static analyzer like `safe-regex` or the `eslint-plugin-security` rule `detect-unsafe-regex`.
</InProduction>


Regular expressions match and transform text using patterns built into JS - write them as /foo/ literals or new RegExp("foo"), with flags like g (global) and i (case-insensitive).

Regular Expressions


A stack is a last-in-first-out (LIFO) collection: the last item you push in is the first one you get back, like a pile of plates. A queue is first-in-first-out (FIFO): items leave in the order they arrived, like a line at a coffee shop. Both are abstract interfaces, not specific data structures - JavaScript arrays can implement either.

<ExamplePair>
<ExampleProse>

A stack on top of an array uses `push` to add to the top and `pop` to remove from the top. Both are O(1): they touch only the last element, so the array never has to shift anything around. A classic use case is an undo history: each action goes on the stack; pressing undo pops the most recent one off.

</ExampleProse>
<ExampleCode>

```js
const undoStack = [];

function doAction(action) {
  undoStack.push(action);
  console.log("Did:", action);
}

function undo() {
  const last = undoStack.pop();
  if (last) {
    console.log("Undid:", last);
  } else {
    console.log("Nothing to undo");
  }
}

doAction("type 'hello'");  // Did: type 'hello'
doAction("bold selection"); // Did: bold selection
undo();                     // Undid: bold selection
undo();                     // Undid: type 'hello'
undo();                     // Nothing to undo
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A queue on top of an array uses `push` to add to the back and `shift` to remove from the front. The `shift` operation is O(n) because the browser has to move every remaining element one index earlier. For small queues that's fine; for a hot queue (many items, high throughput) the cost adds up.

</ExampleProse>
<ExampleCode>

```js
const printQueue = [];

function enqueue(job) {
  printQueue.push(job);
}

function dequeue() {
  return printQueue.shift(); // O(n) - the whole array slides left
}

enqueue("page-1.pdf");
enqueue("page-2.pdf");
enqueue("page-3.pdf");

console.log(dequeue()); // "page-1.pdf"
console.log(dequeue()); // "page-2.pdf"
console.log(dequeue()); // "page-3.pdf"

// Checking length and front without removing
const taskQueue = ["alpha", "beta", "gamma"];
console.log(taskQueue.length);  // 3
console.log(taskQueue[0]);      // "alpha" (peek at front without shift)
```

</ExampleCode>
</ExamplePair>

<InProduction>
Arrays make great stacks (`push` and `pop` are O(1)) but lousy queues: `shift` has to slide every element one position forward, so it's O(n). The regression is easy to miss in a benchmark that uses 100 items - it only shows up around 100,000. For a hot queue, reach for a linked-list-backed queue or a circular buffer where both enqueue and dequeue are O(1). Most job-queue and event-loop implementations inside Node.js internals use a circular buffer exactly for this reason.
</InProduction>


Stack (LIFO: push/pop) and queue (FIFO: push/shift). Arrays are great stacks but poor queues because shift is O(n); use a linked-list queue when throughput matters.

Stacks and Queues


CRUD stands for Create, Read, Update, Delete - the four operations every persistent data store supports. With `localStorage` you can back a small list with a single JSON-encoded key: load it into memory, mutate the in-memory array, then write it back. The pattern is simple but requires careful error handling because `JSON.parse` throws when the stored data doesn't match what you expect.

<ExamplePair>
<ExampleProse>

Reading (the R in CRUD) means loading the JSON string from storage and parsing it. When the key doesn't exist yet `getItem` returns `null`, so you default to an empty array. Wrap `JSON.parse` in `try/catch` so a corrupted or schema-mismatched value doesn't crash the app.

</ExampleProse>
<ExampleCode>

```js
const STORAGE_KEY = "tasks-v1";

function loadTasks() {
  try {
    const raw = localStorage.getItem(STORAGE_KEY);
    if (!raw) return [];
    return JSON.parse(raw);
  } catch {
    // Stored data is not valid JSON or doesn't match the expected shape.
    // Return an empty list rather than crashing.
    console.warn("Could not parse stored tasks; starting fresh.");
    return [];
  }
}

function saveTasks(tasks) {
  localStorage.setItem(STORAGE_KEY, JSON.stringify(tasks));
}

const tasks = loadTasks();
console.log(tasks); // [] on first run
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Creating a task means pushing a new object onto the array and saving. Updating a task means mapping over the array, replacing the item whose `id` matches, and saving. Both operations work on the in-memory copy and then persist it.

</ExampleProse>
<ExampleCode>

```js
function createTask(text) {
  const tasks = loadTasks();
  const newTask = {
    id: crypto.randomUUID(), // unique ID that won't collide
    text,
    done: false,
    createdAt: new Date().toISOString(),
  };
  tasks.push(newTask);
  saveTasks(tasks);
  return newTask;
}

function updateTask(id, patch) {
  const tasks = loadTasks();
  const updated = tasks.map((task) =>
    task.id === id ? { ...task, ...patch } : task
  );
  saveTasks(updated);
}

// Usage
const task = createTask("Buy groceries");
console.log(task.id); // "550e8400-e29b-41d4-a716-446655440000" (random UUID)

updateTask(task.id, { done: true });
console.log(loadTasks().find((t) => t.id === task.id)?.done); // true
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Deleting a task means filtering it out of the array and saving the result. Clearing everything means writing an empty array (or removing the key entirely). The in-memory array never mutates in place - you always produce a new array and save it.

</ExampleProse>
<ExampleCode>

```js
function deleteTask(id) {
  const tasks = loadTasks();
  const remaining = tasks.filter((task) => task.id !== id);
  saveTasks(remaining);
}

function clearAllTasks() {
  localStorage.removeItem(STORAGE_KEY);
}

// Usage
const t = createTask("Write tests");
console.log(loadTasks().length); // 1

deleteTask(t.id);
console.log(loadTasks().length); // 0

// Add a few, then wipe everything
createTask("Alpha");
createTask("Beta");
clearAllTasks();
console.log(loadTasks().length); // 0
```

</ExampleCode>
</ExamplePair>

<InProduction>
`JSON.parse` on stored data can throw if a previous version of the app wrote a different shape - a renamed field, a changed type, a removed key. Always wrap it in `try/catch` and version your storage key (`tasks-v1`, `tasks-v2`) so a schema change starts fresh rather than corrupting every existing user's data. Two tabs open to the same page can clobber each other's writes because each tab loads, mutates, and saves without knowing about the other; for anything that needs concurrent writes, use IndexedDB or a server-side store instead.
</InProduction>


CRUD on a JSON-encoded list stored in a single localStorage key - including try/catch on parse and versioned keys to survive schema changes between app deploys.