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.