Making a learning workbench usable: keyset pagination, direct navigation and recoverable saves

Language: English | 简体中文

I improved FLH’s daily learning workflow by replacing full review-queue loading with keyset pagination, adding original-text search and direct record navigation, and building a question-intake path that can recover uncertain saves.

Result: on an isolated fixture with 1,543 reviewable units, the initial review response shrank from about 821 KB to 27 KB. The learner can return to a previous unit, find an old question and save a new one without manually constructing JSON.

发布日期：2026-10-21

Build a workload before choosing the optimization

The validation fixture contains 1,000 learning records, 3,000 knowledge units and 500 Concepts, with 1,543 units eligible for review. It lets the project measure reads and walk complete workflows without touching personal data.

The full queue returned all 1,543 units: 821,246 bytes and a measured median of 109.8 ms. A 50-unit page returned 26,967 bytes at 3.3 ms in the same recorded local run. These are synthetic, single-machine measurements; the concrete improvement is that first load no longer transfers the entire queue.

Use stable order, not array offsets

The paged queue orders units by entry ID, ordinal and unit ID. A cursor identifies the last key, and a from_unit_id locator resumes at a bounded position. The repository reads limit + 1 rows to determine whether another page exists.

This keeps the eligibility rules intact. A unit decided between reads disappears from later pages; new units earlier than the cursor appear after restarting the queue. The UI tells the learner whether it has loaded the whole queue or only a window, rather than presenting a partial count as a total.

Complete walks at multiple page sizes were compared against the legacy complete list, including re-extractions and pinned older versions. Traversal kept the same order with each eligible unit appearing once.

Search what the learner actually wrote

Record search uses parameterized SQLite substring matching over the learner’s original input and context. It ignores letter case using Unicode lowercasing, while accents and normalization remain exact. Percent signs and underscores are literal characters, not wildcard syntax.

Search composes with state filters and cursor pagination. It does not search generated interpretations or perform client-side filtering of already-loaded pages. A stale response for an older query is discarded.

Make saving a question a useful default

The new intake window accepts a typed question and optional context. It reuses learning_capture_v1 and the existing idempotent capture endpoint, storing an unanalyzed record. Analysis and extraction remain separate user actions. JSON import remains available for prepared captures.

The difficult UI state is an unanswered save. A lost response does not establish that storage failed. The interface keeps the attempt’s capture identity, offers a receipt lookup and allows an explicit byte-identical replay. Editing into a new attempt requires resolving or explicitly leaving the old attempt first.

Confirmed saves can be opened even when the current filters exclude them or refreshing the list fails. That is a small design detail with a large effect on whether users trust the save button.

What I delivered

This work combines SQL query design, HTTP compatibility, React state handling and controlled measurements. I focused on the transitions between operations: returning to a unit after navigation, finishing a decision at a page boundary, receiving a slow search response and recovering a save whose result is unknown.

Implementation and recorded verification used AI coding agents under my task contracts and review. The linked reports document the fixture, measurements and regression checks.

Paged queue and search · Question intake · Workflow fixture · About me

Implementation milestone.