Introduction

When developers ask for "all combinations of items in an object," they usually mean the cartesian product of the arrays stored under each key. That is a very different problem from generating subsets of one list. The real difficulty is not writing the loop. It is handling explosive output growth without wasting memory or creating work you never use.

Define the Combination Problem Precisely

Suppose the input is an object whose values are arrays:

1const options = {
2  color: ["red", "blue"],
3  size: ["s", "m"],
4  region: ["us", "eu"]
5};

If you want one result for every choice of one value from each key, the total number of combinations is the product of the array lengths. In the example above, the output size is 2 * 2 * 2 = 8.

That is why the first performance question is always output size. If the input has ten keys with ten choices each, the answer is already too large to materialize casually.

A Straightforward Iterative Product

For moderate sizes, a reduce-based cartesian product is clear and efficient enough.

1function cartesianObject(input) {
2  const entries = Object.entries(input);
3
4  return entries.reduce((rows, [key, values]) => {
5    const nextRows = [];
6
7    for (const row of rows) {
8      for (const value of values) {
9        nextRows.push({ ...row, [key]: value });
10      }
11    }
12
13    return nextRows;
14  }, [{}]);
15}
16
17console.log(cartesianObject(options));

This works well when the total result size is manageable and the caller genuinely needs all rows in memory at once.

Use a Generator When the Output Is Large

If the result space is large, generating combinations lazily is a better design. A generator can emit one combination at a time so downstream code can stop early or stream results to another system.

1function* cartesianGenerator(entries, index = 0, current = {}) {
2  if (index === entries.length) {
3    yield current;
4    return;
5  }
6
7  const [key, values] = entries[index];
8  for (const value of values) {
9    yield* cartesianGenerator(entries, index + 1, { ...current, [key]: value });
10  }
11}
12
13for (const row of cartesianGenerator(Object.entries(options))) {
14  console.log(row);
15}

This does not change the mathematical growth of the problem, but it drastically lowers peak memory usage. That is often the real win.

Prune Invalid Branches Early

In production code, not every theoretical combination is valid. Some choices may be mutually exclusive, or certain keys may depend on earlier selections. If you know those rules, apply them during generation rather than filtering after full expansion.

1function* constrainedGenerator(entries, index = 0, current = {}) {
2  if (index === entries.length) {
3    yield current;
4    return;
5  }
6
7  const [key, values] = entries[index];
8  for (const value of values) {
9    const candidate = { ...current, [key]: value };
10
11    if (candidate.region === "eu" && candidate.size === "s") {
12      continue;
13    }
14
15    yield* constrainedGenerator(entries, index + 1, candidate);
16  }
17}

Early pruning is often more important than small syntax-level optimizations because it reduces the number of objects you ever create.

Estimate the Size Before You Generate

Before generating anything, compute the expected number of rows. That gives you a simple guardrail for deciding whether to materialize, stream, or reject the request. It also helps you explain the cost of the request to other engineers before the job lands in production.

1function estimateCartesianSize(input) {
2  return Object.values(input).reduce((count, values) => count * values.length, 1);
3}
4
5console.log(estimateCartesianSize(options));

If the estimate is already too large for memory or latency budgets, the right solution is not a faster loop. It is a different product decision, such as pagination, filtering, or a streaming pipeline.

Avoid Confusing Cartesian Products With Subset Generation

This problem is frequently mislabeled. Subset generation chooses some items from one list. Cartesian expansion chooses one value from each independent dimension. The algorithms are different because the output structures are different.

Being precise about the problem helps you choose the right vocabulary, the right tests, and the right performance expectations. It also prevents teams from importing a combinations library that solves the wrong problem elegantly and still fails at the real task.

Common Pitfalls

The biggest mistake is materializing the full cartesian product without first estimating how large it will be. Another is filtering invalid results only after generating all of them. Teams also confuse subset problems with cross-key products, or they optimize the loop body while ignoring the exponential output size that dominates the whole task. A final mistake is copying huge intermediate objects on every step when only a streamed consumer was needed.

Summary

• Most "all combinations from an object" problems are cartesian products.
• The output size grows as the product of the option counts, not linearly.
• Iterative materialization is fine for moderate result sizes.
• Generators are better when you need to stream or stop early.
• Estimate size and prune invalid branches before worrying about micro-optimizations.