demo · v141
Reverse Pagination
Activity feed reads — chat history, email lists, audit logs — almost always need the newest records first. Before 141 that meant orchestrating a "prev" cursor task-by-task. getAllRecords({ direction: "prev", count }) returns a whole page descending in a single round trip.
This page seeds 200 fake activity records into a real IndexedDB store, then runs the same paginated read two ways.
the call
// new in 141 — one round-trip, no per-record task
const tx = db.transaction("activity", "readonly");
const store = tx.objectStore("activity");
const records = await new Promise((res, rej) => {
const req = store.getAllRecords({ direction: "prev", count: 20 });
req.onsuccess = () => res(req.result);
req.onerror = () => rej(req.error);
});
// records: [{ key, primaryKey, value }, …]why this angle
The intent-to-ship explicitly lists "paginated cursors in descending order" as a use case that was previously impossible without the cursor dance. Activity feeds are the canonical workload. The Microsoft case study cited a 350ms improvement on a real production read — every per-record task hop costs real time. This concept times the two approaches side-by-side so you can feel the difference.