Why MagicIndexedDB .Skip().Take() is Backwards
Why .Skip().Take() is Backwards
Author: Lance Wright II
Published: June 02, 2025
Why .Skip().Take() is Backwards
Background: The Expected Convention
In virtually every programming paradigm and database system, pagination is expressed as:
.Skip(x).Take(y)
This means: “skip the first x results, then return y results after that.”
This is the intuitive and standard way developers expect pagination to behave.
The Chaos of IndexedDB
IndexedDB, however, breaks this convention in a rather surprising way—especially when dealing with indexed queries.
When using an indexed cursor, IndexedDB does the opposite:
Take(y) → then Skip(x)
Yes, really.
Despite this reversed syntax, the resulting data still behaves like a .Skip(x).Take(y), but only if you follow IndexedDB’s reversed expectation.
Cursor-based queries vs index-based queries behave differently.
Using .Skip().Take() vs .Take().Skip() can produce different results depending on which query path the browser decides to take.
IndexedDB exposes zero consistency guarantees between query modes.
This is not just a quirk—it’s a core, deeply embedded design decision of the IndexedDB API. And it violates everything developers normally understand about pagination.
✅ MagicIndexedDB's Solution
To avoid this inconsistency (and resulting bugs), MagicIndexedDB enforces a standardized rule:
Always write .Take(y).Skip(x).MagicIndexedDB will internally translate this into the correct behavior, whether it uses an index or a cursor.
Why?
Indexed queries are the most performant in IndexedDB.
To avoid giving developers unpredictable or incorrect results based on query internals.
To align with IndexedDB’s required ordering while preserving the intent of standard pagination.
So while .Take().Skip() looks backwards, MagicIndexedDB ensures it behaves exactly like the expected .Skip().Take().
🔒 Why .Skip() Ends the Query Chain
Calling .Skip() in MagicIndexedDB returns IMagicQueryFinal, which intentionally ends the fluent chain.
Because at this point, the query can no longer guarantee index-based optimization.
Chaining anything after .Skip() would eliminate the chance of performing a fast indexed query.
It would require fallback to full cursor iteration.
If you do need that flexibility, you can opt-in explicitly via .Cursor() instead of .Where(). But know that this disables all indexed optimizations.
🧩 Summary
IndexedDB has non-standard, reversed pagination behavior.
MagicIndexedDB intentionally uses .Take().Skip() to align with this behavior and provide consistent, performant results.
Calling .Skip() finalizes the query to avoid accidentally chaining unsupported logic.
If you need custom chaining or advanced pagination, use .Cursor(), but expect a performance trade-off.
💬 Developer Note
Yes—it feels unnatural.
Yes—you’re right to be confused at first.
No—you’re not doing anything wrong.
This is one of those browser API design quirks that MagicIndexedDB exists to shield you from. It’s weird—but you’re in good hands.
