A few years ago I was profiling a UI that felt sluggish. The culprit wasn’t a massive loop; it was a tiny recursive walk over a nested menu structure that blew up when the tree got deep. That bug taught me a simple lesson: recursion is powerful, but it demands respect. If you’re learning JavaScript today, recursion is still one of the best ways to build a sharp mental model of problem solving. You see the same ideas across data structures, parsing, rendering, and even AI tooling pipelines. In this guide, I’ll show you how I think about recursion, how I explain it to teams, and how you can use it safely in modern JavaScript. You’ll get clear mental models, real code, common pitfalls, and practical guidance on when to choose recursion versus loops or iterative stacks. I’ll keep everything runnable, grounded in real-world tasks, and focused on how you actually understand recursion rather than just memorizing examples.
My mental model: recursion is “repeat with smaller work”
When I teach recursion, I start with a single rule: every recursive function must make the next call easier than the current call. That’s it. If that rule is true, recursion will finish. If it’s false, you’ll get a stack overflow.
I visualize a recursive function as a stack of sticky notes. Each call writes its inputs on a note and waits for the next call to finish. Once the base case returns, the notes peel off in reverse order and compute the final answer. This model helps you reason about what’s happening and why a missing base case is disastrous.
Two ingredients make recursion work:
- Base case: the “stop” condition. It returns a concrete value without making another recursive call.
- Recursive case: the “step” that moves you closer to that base case.
If you remember one sentence, make it this: “The recursive case must always move toward the base case.” That small constraint keeps your stack from exploding.
The anatomy of a recursive function
Here’s the minimal pattern I use in JavaScript. I keep it close when I’m writing production code.
function recursiveFunction(parameters) {
// Base case
if (baseCase) {
return baseCaseValue;
}
// Recursive case
return recursiveFunction(modifiedParameters);
}
When you read a recursive function, read it in that same order:
1) Identify the base case.
2) Confirm the recursive case moves toward it.
3) Ask what the function returns at each level.
Here’s a simple example with factorial. It’s classic, but I use it because it shows the pattern clearly.
function factorial(n) {
// Base case: 0! or 1! is 1
if (n === 0 || n === 1) {
return 1;
}
// Recursive case: n! = n * (n - 1)!
return n * factorial(n - 1);
}
console.log(factorial(5)); // 120
When you run factorial(5), you get a chain of calls: 5 → 4 → 3 → 2 → 1. Then it unwinds back to 120. This is the core of recursion: a forward chain that builds a stack, and a reverse chain that builds the answer.
Building intuition with “call stack tracing”
If you’re struggling to understand recursion, I recommend tracing the call stack with a small example. Let’s trace Fibonacci for n = 5.
function fibonacci(n) {
if (n === 0 || n === 1) {
return n;
}
return fibonacci(n - 1) + fibonacci(n - 2);
}
console.log(fibonacci(5)); // 5
Now trace the first few calls:
fibonacci(5)callsfibonacci(4)andfibonacci(3)fibonacci(4)callsfibonacci(3)andfibonacci(2)fibonacci(3)callsfibonacci(2)andfibonacci(1)
You can already see repeated work. The same subproblems appear over and over. This is a great example of when recursion is clear but inefficient unless you add memoization or convert it to a loop.
When I teach this, I ask people to write the call tree on paper. If the tree explodes, I talk about caching or iteration. That simple exercise turns confusion into clarity.
Recursion versus iteration: when I choose each
Recursion is not always the best choice. I decide based on the shape of the data and the depth of the problem.
I use recursion when:
- The data is naturally hierarchical (trees, nested objects, DOM-like structures)
- The algorithm is naturally divide-and-conquer (merge sort, quick sort)
- The problem is naturally backtracking (puzzles, search, combinatorics)
I avoid recursion when:
- The depth is large and unbounded (user input can create deep nesting)
- Performance is critical and recursion adds overhead
- A simple loop or stack is clearer and safer
Here’s a short comparison table I use with teams when choosing between recursion and iteration.
Modern (Iteration or Explicit Stack)
—
Often safer for large depths in JS engines
More control over memory and stack growth
Slightly more code, but predictable
Uses explicit stack or queueIf you’re working in a runtime where you don’t control depth (like parsing user data), I lean toward an explicit stack. Otherwise, recursion is excellent for clarity.
A real-world example: walking a nested menu
Here’s a pattern I see in production all the time: nested menus, categories, or routes. Recursion fits perfectly because each node has the same shape: a label and children.
const menu = {
label: "Home",
children: [
{ label: "Docs", children: [
{ label: "API", children: [] },
{ label: "Guides", children: [] }
]},
{ label: "Blog", children: [] }
]
};
function findLabels(node, labels = []) {
labels.push(node.label);
for (const child of node.children) {
findLabels(child, labels);
}
return labels;
}
console.log(findLabels(menu));
// ["Home", "Docs", "API", "Guides", "Blog"]
Why this works:
- The base case is implicit: when a node has no children, the loop does nothing and the function returns.
- The recursive case moves to the children, which are smaller subtrees.
- Each call handles one node and delegates the rest.
A tip: if you’re worried about deep trees, add a depth limit or convert it to an explicit stack. In a UI, I keep a defensive limit like 1,000 levels and throw a friendly error if it’s exceeded. That avoids hard-to-debug crashes.
Tail recursion in JavaScript: what you should know
Tail recursion is a form where the recursive call is the last action. In some languages, the runtime can reuse the same stack frame and avoid growth. JavaScript engines have historically been inconsistent about tail call elimination. In practice, you shouldn’t rely on it for production safety.
Here’s a tail-recursive factorial. It’s still a helpful concept for thinking, even if the engine doesn’t always transform it.
function factorialTail(n, acc = 1) {
if (n === 0 || n === 1) {
return acc;
}
return factorialTail(n - 1, n * acc);
}
console.log(factorialTail(5)); // 120
When you write tail recursion, you create a natural path to convert the function into a loop later. If you need more safety, the loop is straightforward:
function factorialLoop(n) {
let acc = 1;
for (let i = 2; i <= n; i++) {
acc *= i;
}
return acc;
}
I use tail recursion as a teaching tool and as a stepping stone to iterative code. It keeps the logic clear while making the eventual loop conversion trivial.
Common mistakes I see and how to avoid them
These are the pitfalls I see most in code reviews and interviews. If you avoid them, you’ll be ahead of the curve.
1) Missing or weak base case
If your base case doesn’t cover every stopping path, you will get infinite recursion. I always ask, “What are the smallest inputs?” and verify those return immediately.
2) Recursive step doesn’t get smaller
If the recursive call doesn’t reduce the problem size, you’re stuck. I encourage people to write a comment like “// move toward base case” and check the logic.
3) Returning the wrong value
Some developers forget to return the recursive call. In JavaScript, missing return means undefined, which breaks your logic when the stack unwinds.
4) Doing work after the recursive call unintentionally
Sometimes you think you have tail recursion but you don’t. A simple + 1 after the call turns it into non-tail recursion, which may be fine but needs to be intentional.
5) Ignoring performance in overlapping subproblems
Naive Fibonacci is the classic example. If the call tree repeats work, you should introduce memoization or dynamic programming.
Here’s a simple memoized Fibonacci that stays clear and fast:
function fibonacciMemo(n, memo = new Map()) {
if (memo.has(n)) return memo.get(n);
if (n === 0 || n === 1) return n;
const value = fibonacciMemo(n - 1, memo) + fibonacciMemo(n - 2, memo);
memo.set(n, value);
return value;
}
console.log(fibonacciMemo(40));
That memoization turns exponential time into linear time for this case. You keep the recursive clarity while controlling runtime.
Performance and stack safety in real JavaScript runtimes
JavaScript has a call stack limit that varies by engine and environment. That’s why I avoid deep recursion when the depth is unknown. A browser might handle thousands of frames, but not tens of thousands. A Node process may differ. You don’t want your production service to fail because a user uploaded a deeply nested JSON structure.
Here’s my rule of thumb:
- Depth up to a few hundred: recursion is usually fine.
- Depth up to a few thousand: recursion is risky; test carefully.
- Depth unknown or user-controlled: prefer an explicit stack.
If you need to simulate recursion safely, use an iterative stack. Here’s a safe depth-first traversal without recursion:
function findLabelsIterative(root) {
const labels = [];
const stack = [root];
while (stack.length > 0) {
const node = stack.pop();
labels.push(node.label);
// Push children in reverse so traversal order matches recursion
for (let i = node.children.length - 1; i >= 0; i--) {
stack.push(node.children[i]);
}
}
return labels;
}
That’s my go-to when I can’t trust the depth. The code is a bit longer, but predictable and safe.
Recursion in modern development workflows (2026 perspective)
Recursion isn’t just an academic tool. I use it today in production for:
- Walking ASTs in code transformation tools
- Traversing deeply nested configuration objects
- Building tree-shaking and bundling logic
- Rendering nested UI structures in a controlled way
In 2026, AI-assisted coding tools often generate recursive solutions for tree and graph problems. The tools are helpful, but you still need to validate that base cases are correct and that recursion depth is safe. I routinely add tests that exercise extreme depths or empty data to avoid surprises.
Here’s a practical pattern I use in code reviews: I ask the author to add a test for the smallest input and for a deep input. Those two tests catch most recursion bugs. If the function will run on user data, I also ask for a maximum depth guard.
Recursion for data structures: linked lists and trees
Let’s apply recursion to a linked list reversal. It’s elegant and teaches you how recursive return values build new structure.
function reverseList(node) {
if (node === null || node.next === null) {
return node;
}
const reversedHead = reverseList(node.next);
node.next.next = node; // flip the pointer
node.next = null; // old head becomes tail
return reversedHead;
}
This version is elegant but uses recursion depth equal to list length. If the list is huge, I use iteration instead. Still, I like this example because it shows how recursion can transform structure as it unwinds.
Now consider a binary tree traversal. Recursion is the most natural expression.
function inorderTraversal(node, values = []) {
if (!node) return values;
inorderTraversal(node.left, values);
values.push(node.value);
inorderTraversal(node.right, values);
return values;
}
Again, base case is null. The recursion walks left, then node, then right. If you can see this in your head, you’re already thinking recursively.
Backtracking: recursion as a search strategy
Backtracking is one of the most practical uses of recursion. It’s the idea of making a choice, exploring, and undoing if it fails.
Here’s a clean example: generate all valid parentheses pairs for a given number. This is a classic recursion exercise that feels real because it mimics the decision tree you’d draw on paper.
function generateParentheses(n) {
const results = [];
function backtrack(current, open, close) {
if (current.length === n * 2) {
results.push(current);
return;
}
if (open < n) {
backtrack(current + "(", open + 1, close);
}
if (close < open) {
backtrack(current + ")", open, close + 1);
}
}
backtrack("", 0, 0);
return results;
}
console.log(generateParentheses(3));
In this pattern, each recursive call adds one character and narrows the possibilities. This is the cleanest way I know to explain why recursion is so useful for search problems.
When not to use recursion (and what I do instead)
I recommend avoiding recursion when:
- You’re processing large arrays or streams where a loop is clear and fast
- The depth can be high due to user input
- You’re in a performance-sensitive hot path
In those cases, I pick one of two alternatives:
1) Use a loop with a stack or queue (explicit data structure)
2) Use a generator to yield values without deep call stacks
For example, a recursive directory walk can be replaced with an iterative queue and a breadth-first traversal. That’s a safer pattern when the directory depth is unknown.
This isn’t about “recursion is bad.” It’s about choosing the right tool for the environment and constraints.
Testing recursive functions the way I do it
Recursion bugs are subtle, so I rely on a small test checklist:
- Test the smallest input (base case)
- Test a typical input (middle case)
- Test a deep input (stress case)
- Test invalid inputs (negative numbers, null, empty arrays)
Example tests for factorial:
factorial(0) === 1factorial(5) === 120- For invalid input, either throw or return
null
I like to explicitly handle invalid input to avoid accidental infinite recursion:
function factorialSafe(n) {
if (!Number.isInteger(n) || n < 0) {
throw new Error("n must be a non-negative integer");
}
if (n === 0 || n === 1) {
return 1;
}
return n * factorialSafe(n - 1);
}
Even simple validation like this saves you from weird corner cases in production.
Practical patterns I rely on
Here are the recursion patterns I return to often, with guidance on when to use them.
1) Reduce a list recursively
Use this when you want clarity over performance and the list is small.
function sumList(arr) {
if (arr.length === 0) return 0;
return arr[0] + sumList(arr.slice(1));
}
This version is expressive but not efficient because slice creates new arrays. For large arrays, I switch to an index-based helper to avoid extra allocations.
function sumListEfficient(arr, i = 0) {
if (i === arr.length) return 0;
return arr[i] + sumListEfficient(arr, i + 1);
}
2) Traverse nested objects
Use this for configs, API payloads, or settings with unknown depth.
function collectKeys(obj, keys = []) {
if (obj === null || typeof obj !== "object") return keys;
for (const key of Object.keys(obj)) {
keys.push(key);
collectKeys(obj[key], keys);
}
return keys;
}
This is especially helpful when you need to detect unexpected properties in nested structures.
3) Divide-and-conquer algorithms
Recursion shines in algorithms like merge sort because the data is naturally split.
function mergeSort(arr) {
if (arr.length <= 1) return arr;
const mid = Math.floor(arr.length / 2);
const left = mergeSort(arr.slice(0, mid));
const right = mergeSort(arr.slice(mid));
return merge(left, right);
}
function merge(left, right) {
const result = [];
let i = 0, j = 0;
while (i < left.length && j < right.length) {
if (left[i] <= right[j]) result.push(left[i++]);
else result.push(right[j++]);
}
return result.concat(left.slice(i)).concat(right.slice(j));
}
This is clean, but note it allocates many arrays. In performance-critical paths, I prefer iterative or in-place sorting.
Debugging recursion in the real world
I debug recursive functions with a few consistent techniques:
1) Add a depth counter
It’s the fastest way to confirm you’re moving toward the base case.
function debugFactorial(n, depth = 0) {
console.log(" ".repeat(depth * 2) + call factorial(${n}));
if (n === 0 || n === 1) return 1;
return n * debugFactorial(n - 1, depth + 1);
}
2) Log at the base case and on unwind
This tells you how many calls actually happened and where the answer is built.
function debugSum(arr, i = 0) {
if (i === arr.length) {
console.log("base case reached");
return 0;
}
const result = arr[i] + debugSum(arr, i + 1);
console.log(unwind at i=${i}, result=${result});
return result;
}
3) Assert invariants
I add lightweight checks that prove the recursive step makes progress. If those checks fail, the recursion is wrong by definition.
function safeWalk(node, depth = 0, maxDepth = 1000) {
if (depth > maxDepth) throw new Error("Max depth exceeded");
if (!node) return [];
const result = [node.label];
for (const child of node.children) {
result.push(...safeWalk(child, depth + 1, maxDepth));
}
return result;
}
Recursion and memory: what’s really happening
Each recursive call consumes a stack frame that holds local variables and the return address. That’s why deep recursion can crash: the stack is finite.
A couple of practical takeaways:
- Recursion depth is a memory cost, not just a time cost.
- The “implicit stack” is convenient but opaque.
- If you need visibility or control, make the stack explicit.
Here’s a helpful exercise: whenever you write a recursive function, imagine the stack frames as actual objects in memory. If you can’t afford those objects at scale, you can’t afford deep recursion.
Converting recursion to iteration: a repeatable recipe
If you ever need to convert a recursive algorithm to an iterative one, I follow a consistent pattern:
1) Identify what each recursive call needs to do.
2) Create a stack (or queue) to store those tasks.
3) Pop tasks, process them, and push new tasks that represent the next recursion steps.
Here’s a conversion example for tree traversal:
function collectLabelsIterative(root) {
const labels = [];
const stack = [{ node: root, visited: false }];
while (stack.length > 0) {
const { node, visited } = stack.pop();
if (!node) continue;
if (visited) {
labels.push(node.label);
} else {
// Post-order traversal: left, right, node
stack.push({ node, visited: true });
stack.push({ node: node.right, visited: false });
stack.push({ node: node.left, visited: false });
}
}
return labels;
}
This pattern replaces the call stack with a manual structure. It’s more verbose, but it scales and is often easier to debug in production.
Recursion and memoization: two sides of the same coin
Recursion becomes dramatically more powerful with caching. If you see overlapping subproblems, memoization is usually the right move. The recursive shape stays clean, but the repeated work disappears.
Here’s a memoized path count for a grid (a classic dynamic programming example):
function countPaths(rows, cols, memo = new Map()) {
const key = ${rows},${cols};
if (memo.has(key)) return memo.get(key);
if (rows === 1 || cols === 1) return 1;
const value = countPaths(rows - 1, cols, memo) + countPaths(rows, cols - 1, memo);
memo.set(key, value);
return value;
}
If you remove memoization, this explodes in time. With memoization, it runs quickly for reasonably large grids. The point isn’t the math; the point is that recursion is often a gateway to dynamic programming.
Understanding recursion with real UI scenarios
I like teaching recursion with UI layouts because it feels concrete. Here’s a practical example: render a nested comment thread into a flat list with indentation metadata.
function flattenComments(comments, depth = 0, result = []) {
for (const comment of comments) {
result.push({ id: comment.id, text: comment.text, depth });
if (comment.replies && comment.replies.length > 0) {
flattenComments(comment.replies, depth + 1, result);
}
}
return result;
}
This is a clean fit for recursion because each comment has the same shape. The base case is “no replies.” The recursive case handles the replies with a deeper indent. This pattern also maps directly to rendering nested components.
Handling cycles: recursion’s hidden trap
Recursion assumes a tree or a DAG. But real-world data can contain cycles. If you recurse into a cycle, you’ll never reach the base case.
A simple fix is to track visited nodes:
function walkGraph(node, visited = new Set()) {
if (!node || visited.has(node)) return;
visited.add(node);
for (const neighbor of node.neighbors) {
walkGraph(neighbor, visited);
}
}
If your data might have cycles, add this guard. It turns infinite recursion into a safe traversal.
Recursion with generators: laziness without deep stacks
Sometimes you want recursion’s clarity but not its memory cost. Generators can help by yielding values as you go.
function* walkTree(node) {
if (!node) return;
yield node.value;
for (const child of node.children) {
yield* walkTree(child);
}
}
This is still recursive, but it can be easier to consume because you pull values as needed. For very deep trees you still risk stack overflow, but for moderately deep trees it’s elegant and composable.
Measuring recursion performance responsibly
I avoid exact benchmark claims because they vary by machine and engine. Instead, I look for ranges and trends:
- Naive recursion is often several times slower than a loop due to function call overhead.
- Memoization often turns an unusable recursive solution into a practical one.
- If recursion depth grows beyond a few thousand frames, the failure risk increases sharply.
The key is not to guess: profile with realistic inputs, not toy examples. Recursion that’s fine on a 100-node tree may fail on a 50,000-node user payload.
Recursion and error handling: be intentional
When a recursive function fails, it can be hard to pinpoint where. I include defensive checks early in the function:
function safeFactorial(n) {
if (!Number.isInteger(n)) throw new Error("Expected integer");
if (n < 0) throw new Error("Expected non-negative integer");
if (n <= 1) return 1;
return n * safeFactorial(n - 1);
}
I also prefer to keep recursive functions pure when possible. That makes it easier to test and reason about. If the function needs side effects, I isolate them so I can confirm they execute only once per call.
How I explain recursion to a team
When I introduce recursion to a team, I do three things:
1) I show the base case first.
People understand “when do we stop?” before they understand “how do we move.”
2) I trace a tiny example on a whiteboard.
We write the call stack explicitly. Seeing it makes the model click.
3) I compare it to iteration.
That comparison reduces fear. Recursion is just a different way to organize the same work.
A phrase I use often is: “Recursion is a loop with a memory.” That memory is the call stack. This makes the concept feel less mysterious.
Recursion for parsing and AST traversal
If you ever parse expressions or work with compilers, recursion appears immediately. An AST is a tree, and trees are recursion’s home turf.
Here’s a small expression evaluator:
function evaluate(node) {
if (node.type === "Number") return node.value;
if (node.type === "Add") return evaluate(node.left) + evaluate(node.right);
if (node.type === "Multiply") return evaluate(node.left) * evaluate(node.right);
throw new Error("Unknown node type");
}
This is almost the perfect recursion example: each node asks for the value of its children. The base case is a number literal, and the recursive case is an operator that combines the children’s values.
Recursion in async code: keep it readable
Recursion can work with async operations, but you need to return your promises properly.
async function fetchTree(node) {
if (!node) return null;
const children = await Promise.all(node.childUrls.map(fetchNode));
node.children = [];
for (const child of children) {
node.children.push(await fetchTree(child));
}
return node;
}
The critical part is returning the recursive call. In async recursion, missing a return can lead to unresolved promises and partial results. I keep the code explicit so it’s harder to mess up.
A practical checklist before I ship recursive code
Before I ship a recursive function, I quickly check:
- Base case: does it handle the smallest valid input?
- Progress: does each call move closer to the base case?
- Depth: is the maximum depth safe for the runtime?
- Performance: are there overlapping subproblems I should memoize?
- Tests: do I have a base case test and a deep input test?
If those checks pass, I’m comfortable with recursion in production.
A deeper look at “understanding” recursion
Understanding recursion isn’t about memorizing examples. It’s about being able to predict what happens at each step. Here’s how I practice that skill:
1) I start with tiny inputs.
I run the function for the smallest values and confirm the base case behavior.
2) I write the call stack on paper.
I explicitly list each call and the returned value.
3) I separate “down” and “up.”
The recursion goes down (building the stack) and then goes up (building the answer). That two-phase thinking eliminates most confusion.
4) I rename parameters.
If the recursive step isn’t clearly smaller, I rename variables to reflect what changed. That often reveals the mistake.
The goal is to build the mental habit of “what changes in the next call?” If you can answer that clearly, you understand the recursion.
Recursion pitfalls in JavaScript specifically
JavaScript has a few quirks that can make recursion trickier:
- Default stack limits are not standardized. Code that works in one runtime may fail in another.
- Mutability can cause surprising results when you pass arrays or objects through recursion.
- Tail call elimination is not reliable in practice.
Because of these, I often use recursion in JavaScript for clarity and medium-sized inputs, and I use iteration for unbounded or user-controlled inputs.
Advanced pattern: recursion with accumulator objects
Sometimes you want to build up complex results across recursive calls. I use an accumulator object so I can add multiple types of results in a single traversal.
function analyzeTree(node, stats = { count: 0, labels: [] }) {
if (!node) return stats;
stats.count += 1;
stats.labels.push(node.label);
for (const child of node.children) {
analyzeTree(child, stats);
}
return stats;
}
This is an efficient pattern because it avoids rebuilding arrays at each return. The tradeoff is that you must be careful about mutations. I avoid exposing this stats object outside the function unless I’m confident it won’t be reused incorrectly.
Practical scenario: validating nested form input
Here’s a real-world example I use in front-end code: validating nested form fields.
function validateFields(fields, errors = []) {
for (const field of fields) {
if (field.required && !field.value) {
errors.push({ id: field.id, message: "Required" });
}
if (field.children && field.children.length > 0) {
validateFields(field.children, errors);
}
}
return errors;
}
This is a clean use of recursion because each field has the same shape. The function is small, easy to test, and easier to read than a manual stack in many cases.
Practical scenario: flattening a file system tree
If you’ve ever built a file explorer UI, you’ve probably done this:
function flattenFileTree(node, path = "", result = []) {
const currentPath = path ? ${path}/${node.name} : node.name;
if (node.type === "file") {
result.push(currentPath);
return result;
}
for (const child of node.children) {
flattenFileTree(child, currentPath, result);
}
return result;
}
This is an ideal use of recursion: small, readable, and directly aligned with the shape of the data.
Practical scenario: recursion in JSON transformations
When you need to transform all values of a nested JSON object, recursion is often the cleanest approach.
function mapValuesDeep(value, transform) {
if (Array.isArray(value)) {
return value.map(v => mapValuesDeep(v, transform));
}
if (value !== null && typeof value === "object") {
const result = {};
for (const [key, val] of Object.entries(value)) {
result[key] = mapValuesDeep(val, transform);
}
return result;
}
return transform(value);
}
This pattern is extremely useful in configuration pipelines and API normalization.
The “base case first” reading strategy
When you’re reading someone else’s recursive code, don’t start at the top. Start at the base case. Ask: “What does the smallest input do?” Then look at the recursive case and confirm it reduces the problem. This reading order is the most reliable way I know to prevent confusion.
A short guide to teaching yourself recursion
If you want to build recursion intuition quickly, here’s the practice sequence I recommend:
1) Factorial and sum of an array
2) Tree traversal with a tiny tree
3) Fibonacci with memoization
4) Backtracking with a small puzzle
5) Convert one recursive solution to an iterative one
This sequence builds confidence gradually and exposes the main recursion patterns you’ll use in real code.
Recursion and code review: what I look for
When I review recursive code, I look for:
- Clear base case, preferably near the top
- A comment or obvious expression showing how the input shrinks
- Tests covering base and deep cases
- A note or guard for maximum depth if the input is untrusted
If those are present, I’m comfortable approving the code. If not, I ask for changes.
Summary: the simplest way to understand recursion
Recursion isn’t magic. It’s a loop with a memory, and the memory is the call stack. If you can answer three questions, you understand recursion:
1) What is the base case?
2) How does each recursive step move toward that base case?
3) What does the function return as it unwinds?
Master those questions and recursion becomes a tool you can rely on, not a trick you copy and paste. When you use it with care—base cases, safe depths, and proper tests—it becomes one of the most expressive problem-solving tools in JavaScript.
If you want to go further, pick a real nested structure from your codebase and write a recursive traversal. Then write the iterative version. That single exercise will teach you more than any diagram. Recursion clicks when you can see both forms and know why you’d choose one over the other. That’s the real understanding.
