递归评论树 + 树形不可变更新Recursive comment tree, updated without changing the original

“Comments on comments” sounds complicated; written as a type it is one line:

replies is typed Comment[] — it refers to the very type being defined. TypeScript allows that recursion, and that is what a tree is.

Depth is not in the data. Notice there is no depth field on Comment. Depth is “where the node sits in the tree”, worked out while rendering. It should not be stored — store it and you have to maintain it whenever a node moves, and it drifts out of sync with the real structure very easily.

A recursive component renders itself inside its own JSX:

Where is the base case? In the line comment.replies.map(...). When replies is an empty array, map produces nothing, so no new CommentNode is created — the recursion stops by itself and you do not need anything like if (depth > N) return null.

Depth is passed down as a prop. One level down is depth + 1, used for the indent and for data-depth. The root starts at 0.

The key is still child.id, same as any list — unique among siblings is enough, it does not have to be unique across the whole tree.

One real caveat: if the data can contain a cycle (A shows up inside its own replies), the recursion blows the stack. A real API usually will not, but if the question mentions “the data comes from user input”, saying “add a visited set or a max depth as a backstop” earns points.

“How many comments in total, counting every level” is the usual add-on requirement for this kind of question. As a recursion it is one line:

How to read it: every node contributes itself, 1, plus its whole subtree. On an empty array reduce returns the initial value 0, and the recursion ends there.

The same pattern gets you plenty of other things: max depth (1 + Math.max(...children)), finding an id, flattening the tree into an array. Tree questions are mostly this one skeleton with a different accumulator.

The requirement is “add one entry to the replies of the node whose id is X”, and X can be at any depth.

Why not just find it and push? That mutates the original object. React compares the reference of the root array — you changed something deep inside, the root array is still the same one, and the UI does not update. (Even if you then build a fresh root with setComments([...comments]), the original data is already polluted.)

The right answer is to build new objects recursively:

This code is worth reading line by line:

• nodes.map(...) — every level returns a new array.
• Target found: { ...node, replies: [...node.replies, reply] } — a new node object plus a new replies array.
• Not the target: build a new object anyway, because the target may be hiding in its subtree and addReply(node.replies, ...) may return a new array.
• When the recursion reaches a leaf (replies empty), map returns an empty array and the recursion ends.

One thing people misread: this is not a deep copy. Only the nodes on the path from the root to the target are new objects; the branches beside it do get a new shell from { ...node }, but the values inside — body, author and the rest — are shared, and the deeper subtree objects are reused. That is exactly what React wants: references change along the path that changed and stay the same everywhere else, which is the only way React.memo can skip correctly.

The tests check both of these: the original tree was not touched at all (deep-frozen with Object.freeze, so any write throws), and the objects on the path really are new references.

Collapsed state lives on each node (open inside CommentNode), not lifted to the top. Whether this one comment is folded is nobody else’s business — lift it and you have to maintain a set of ids, which is trouble you invented for yourself.

onReply is passed all the way down from the top. On a deep tree that gets wordy, and a real project would reach for Context or a state library — but in an assessment plain, honest prop passing is the safest answer, unless the question explicitly asks for Context.

deepFreeze recursively runs Object.freeze on every level of the original tree. Once frozen, any write throws a TypeError outright in strict mode (TS/ESM are strict by default) instead of failing silently.

So if your addReply has one push or one direct assignment in it, the test reports Cannot add property 0, object is not extensible — immutability goes from “somebody has to catch it in review” to “a machine checks it”. The trick works in any question about immutable updates.

Test 3 checks that only the path is rebuilt: nodes on the path must be not.toBe the originals (new references), while the branches beside it keep the same content. That test separates the real answer from “deep copy and hope”.