How do you approach DOM: Render a List Safely?

document.createElement('li') gives you an element; set its textContent, not innerHTML.

What is the optimal solution to DOM: Render a List Safely?

Build nodes, never strings. The trap is list.innerHTML += ${item} ` - it re-parses the whole list on every iteration (quadratic), and an item like becomes live markup. This is the exact bug class behind most DOM XSS. Creating an element and assigning textContent treats the string as text no matter what it contains.

What are common mistakes on DOM: Render a List Safely?

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: Render a List Safely

EasyFrontend Frameworks

Description

Runs in a real DOM. document and window are live (jsdom). Each test seeds the page with the HTML shown below before calling your function.

The page contains an empty <ul id="list"></ul>. Implement renderList(items) that appends one <li> per string in items, in order, then returns the list's innerHTML so the grader can read the result.

Items are untrusted text - "x" must render as the literal characters, not bold text. That rules out building the markup with string concatenation.

Example 1

Input: items = ["Apples", "Pears"]

Output: "<li>Apples</li><li>Pears</li>"

Example 2

Input: items = ["x"]

Output: "<li>x</li>"

Example 3

Input: items = []

Output: ""

Constraints

- 0 <= items.length <= 100 - Each item is a string of at most 100 characters and may contain <, >, & or quotes. - Page HTML before each test: `<ul id="list"></ul>`

DOM: Render a List Safely: approach, complexity and pitfalls

An easy 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.createElement('li') gives you an element; set its textContent, not innerHTML.
textContent escapes for you - the serializer turns < into < when you read innerHTML back.
Append with list.appendChild(li) (or list.append(li)); do not reset innerHTML first - one hidden test starts with an existing item.

The optimal approach

Show the approach: Build nodes, never strings

The trap is `list.innerHTML += `<li>${item}</li>`` - it re-parses the whole list on every iteration (quadratic), and an item like `<img onerror=...>` becomes live markup. This is the exact bug class behind most DOM XSS.

Creating an element and assigning `textContent` treats the string as text no matter what it contains. When the grader reads `innerHTML` back, the serializer escapes `<`, `>` and `&` - which is why the expected output for `"x"` is `x`.

For large lists, build into a `DocumentFragment` and append once, so the layout engine sees a single mutation.

Time: O(n). Space: O(1) beyond the nodes themselves.

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

What the tests check

Read off this problem's own test suite, so these are the cases a submission actually has to survive.

Empty input. At least one case passes an empty collection. Make sure your loop bounds and any "first element" read survive a length of zero.
Single element. A one-element case is included. Two-pointer and window solutions frequently return the wrong thing when the two indices start out equal.

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.