SolidBoard:
Wait-Free Management

WHY SOLID AND NOT REACT

A Kanban board is a stress test for a reactive model in a specific way: during a drag, a fast-changing piece of state — which card is held, which gap it is hovering — is read by almost every node on the screen. Under a virtual DOM that is a reconciliation pass per pointer move over the entire board.

Solid compiles the JSX into direct DOM instructions. There is no diff, and a signal read inside a component body does not subscribe the component to it — it subscribes the exact expression that read it. A card turning translucent because it is being dragged updates that one class binding and nothing else, whether the board holds ten cards or three hundred.

The cost is that the ergonomics are unforgiving. Props are getters, so destructuring them silently breaks reactivity, and the entire component body runs exactly once. It is a model that rewards knowing what it is doing and punishes React habits.

WHERE THE STATE LIVES

Boards sit in a Solid store rather than a signal, because store writes are path-addressed. Updating one board's title is a write to that board's title node — anything watching a different board is not notified at all, without any memoisation being written by hand.

Filtering is a derived value rather than an effect that writes more state. One createMemo narrows the task list by search text, then priority, then tag; each column then takes its own slice of that memo and sorts by order. Typing into the search box recomputes one memo and touches only the cards whose membership actually changed.

The input itself is held locally and pushed into the shared query through a 300ms debounce, so the memo chain runs on pauses in typing rather than on keystrokes, while the field itself stays perfectly responsive.

Persistence

Ordering is dense integers

The Express API exposes one endpoint for movement, PUT /api/tasks/:id/move, taking a target column and a target index. Everything else about a task goes through the normal update route, so there is exactly one place where ordering can be got wrong.

Positions are contiguous integers per column, which means a move is never one write. Across columns it is three: the card is repositioned, then everything below its old slot is decremented, then everything at or after its new slot is incremented. Within a column it is two, and the direction decides which range shifts and which way. Each of those shifts is a single updateMany with $inc over a range predicate, rather than a read-modify-write of every affected row.

Two compound indexes exist for exactly these queries: board with column, and board with order.

THE TRADE-OFF

Dense integers are the obvious choice and the slow one. Every move is linear in the size of the affected range, and two people reordering the same column at the same moment can interleave their shifts into an order neither of them asked for.

Fractional or lexicographic ranks are the standard fix: give each card a key strictly between its neighbours', and a move becomes one write to one row with no shifting at all. The price is keys that drift toward unreadable as they subdivide, plus a background rebalance to stop that. For a single-owner board, three bounded writes is a worse algorithm and a much easier system to reason about — the ordering column stays a small integer you can read straight out of the database.

Below that, the data model is deliberately plain. A board embeds its columns as a subdocument array and ships with five by default — Backlog, To Do, In Progress, Review, Done — because columns are owned by exactly one board and never queried independently. Comments embed in their task for the same reason. Priorities are a four-value enum from low to urgent, and every board route re-verifies ownership against the authenticated user before touching anything, so a stateless JWT proves who you are and the route still proves what you may reach.