How do you approach DOM: Highlight Search Matches in Text Nodes?

document.createTreeWalker(root, NodeFilter.SHOW_TEXT) visits only text nodes - collect them into an array first, because you will be replacing nodes while walking.

What are common mistakes on DOM: Highlight Search Matches in Text Nodes?

An incomplete dependency array, which pins the effect to a stale closure. Mutating state in place instead of replacing it, so no re-render is scheduled. Never cleaning up the timer, listener or subscription on unmount.

gitGood.dev

← Back to problems

DOM: Highlight Search Matches in Text Nodes

HardFrontend Frameworks

Description

> **Runs in a real DOM.** Each test seeds `<div id="content">` with a small fragment of HTML. Implement `highlight(term)` that wraps every case-insensitive occurrence of `term` **inside text nodes** of `#content` in a `` element, preserving the original casing of the matched text, and returns `#content`'s `innerHTML`. Rules that make this the interview question it is: - Only text is searched. A match inside an attribute (`title="cat"`) or a tag name must not be touched. - Existing elements stay where they are: `Hello world hello` keeps its ``. - `term` is literal text, not a regex: `"a.b"` must match `a.b` and not `axb`. - An empty or whitespace-only `term` changes nothing.

Example 1

Input: term = "cat", content = "The cat sat. Cat naps."

Output: "The cat sat. Cat naps."

Example 2

Input: term = "hello", content = "Hello world hello"

Output: "Hello world hello"

Constraints

- #content is at most a few hundred characters. - Matches never overlap each other.

DOM: Highlight Search Matches in Text Nodes: approach, complexity and pitfalls

A hard frontend problem, graded against 6 test cases (3 of them hidden).

The pattern: Frontend

React and browser-platform problems - hooks, event handling, and rendering behaviour.

Reach for it when you see: A component, hook, or DOM-behaviour question rather than an algorithm.

If you are stuck

Show the 3-step hint ladder

document.createTreeWalker(root, NodeFilter.SHOW_TEXT) visits only text nodes - collect them into an array first, because you will be replacing nodes while walking.
Escape the term for RegExp (term.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')) and use the 'gi' flags; keep the matched text from the node, not the term, to preserve casing.
Split the text node's data on the regex, build a fragment of text nodes and elements, and replace the original node with the fragment.

The optimal approach

Show the approach: Search the text, not the markup

The naive answer - `root.innerHTML = root.innerHTML.replace(/cat/gi, "$&")` - fails three of the tests: it rewrites the `title="cat"` attribute, it would corrupt a tag if the term appeared in one, and it throws away every listener and reference on the existing nodes.

The right tool is a `TreeWalker` restricted to `SHOW_TEXT`. Collect the text nodes first (mutating during traversal is a classic footgun), then for each node with a match: split its `data` around the matches, build the replacement as a `DocumentFragment` of plain text nodes and `` elements, and `replaceWith` it. Elements are never touched, so `` and `<a title>` survive intact.

Two details the hidden tests pin: escape the term before building the RegExp (`a.b` is literal), and take the matched slice from the node (`Cat` stays `Cat`), not from `term`.

Time: O(total text length). Space: O(matches).

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

Common Frontend mistakes

These apply to the pattern as a whole, not just this problem.

An incomplete dependency array, which pins the effect to a stale closure.
Mutating state in place instead of replacing it, so no re-render is scheduled.
Never cleaning up the timer, listener or subscription on unmount.