How do you approach DOM: Sort a Table by Column?

Array.from(tbody.rows) gives you the elements; row.cells[columnIndex].textContent is the key.

What are common mistakes on DOM: Sort a Table by Column?

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: Sort a Table by Column

MediumFrontend Frameworks

Description

Runs in a real DOM. Each test seeds a <table id="people"> with a <thead> and a <tbody>.

Implement sortTable(columnIndex, direction) that reorders the <tbody> rows by the text of the cell at columnIndex. direction is "asc" or "desc".

If every value in the column parses as a number, compare numerically (so 9 < 31 < 110); otherwise compare as strings.
The sort must be stable: rows with equal keys keep their original relative order.
Move the actual row elements - do not rebuild the table from strings.

Return the first-column text of every body row, in the new order, read back from the DOM.

Example 1

Input: columnIndex = 0, direction = "asc" (names Cara, Abe, Bo)

Output: ["Abe","Bo","Cara"]

Example 2

Input: columnIndex = 1, direction = "asc" (ages 31, 9, 110)

Output: ["Abe","Cara","Bo"]

Constraints

- 1 <= rows <= 200 - columnIndex is always valid.

DOM: Sort a Table by Column: approach, complexity and pitfalls

A medium 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 4-step hint ladder

Array.from(tbody.rows) gives you the <tr> elements; row.cells[columnIndex].textContent is the key.
Decide numeric-vs-string ONCE for the whole column: every key must be a finite number, otherwise '110' sorts before '9' as text.
Array.prototype.sort is stable in every modern engine - for desc, reverse the comparison, do not reverse the array (that breaks stability).
Re-appending an element that is already in the DOM moves it - tbody.appendChild(row) in sorted order is the whole reorder.

The optimal approach

Show the approach: Three details, all of which the tests check

1. Column-wide type decision. Deciding per pair (`a` numeric and `b` numeric → numeric compare) gives inconsistent comparators that violate the sort contract. Decide once: numeric if *every* cell parses, else string.

2. Stability under `desc`. `sort(cmp).reverse()` reverses the ties too. Negate the comparison instead: `direction === "desc" ? -cmp : cmp`.

3. Moving nodes. `appendChild` on a node that already has a parent *moves* it, so appending the rows back in sorted order reorders the table in place - event listeners, focus, and any state on the rows survive. Rebuilding via `innerHTML` would destroy all of that.

Time: O(n log n). Space: O(n) for the row array.

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.

Zero. Zero appears in the input, which is the value most likely to break a truthiness check used in place of an explicit comparison.

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.