memotable - A tiny JS library for finely-reactive, derived collections

[shudv]

_Disclaimer: I am not a SolidJS expert. I am posting this here because based on my limited understanding - I feel SolidJS community would care about the "long tail" of performance issues much more as compared to other frameworks.

Problem

While working with React apps, one common pitfall I notice overuse of hooks. As an example, the hook useMemo is almost always misused. If you use it to memoize simple O(1) computations, the performance improvement won't make a difference in any realistic scenario (unless the O(1) computation is super heavy which is rare). If you use it to memoize collections and their derivatives (e.g. filtered and sorted views), it does not actually work-

const filtered = useMemo(() => todos.filter(filter), [tasks, filter]);
const sorted   = useMemo(() => filtered.sort(cmp), [filtered, cmp]);

This is deceptive as it looks correct but it isn't-

1. If you mutate the array in place, the reference doesn’t change and useMemo will return stale results.
2. If you recreate the array every render (common in immutable flows), the memo dependency always changes and you pay the computation cost every time anyway.

Proposed solution

I built a tiny library — memotable (≈1.4 KB min+gz and ≈1.0 KB min+br). It’s a read-friendly data structure which can maintain derived views efficiently. This matters only for a narrow set of apps (typically apps that manage large in-memory datasets).

Instead of the typical write-friendly pattern-

const todos = new Map<string, ITodo>();

function getTodos(listId: string) {
    return Array.from(todos.values())
        .filter((todo) => todo.listId === listId
        .sort(byTitle);
}

getTodos("list1"); // Full pass and sort on every invocation

you can express the same as a read-friendly structure using memotable's Table primitive-

const todos = new Table<string, ITodo>();

todos.sort(byTitle);
todos.index(
    (todo) => todo.listId,
    (p) => p.memo(), // Memoize list level partitions
);

todos.partition("list1"); // Pre-computed list enabling fast read
todos.values(); // Root partition is not-memoized and hence still sorts at read-time

Reads are effectively free because the view is already materialized. Writes cost more, but for read-heavy workloads it's a good trade-off. As an example- based on my synthetic benchmark with R/W ratio of 4:1, memotable turns out to be ~4x faster.

I am curious if anyone here has explored this before and found a simpler alternative. Please share your feeback/inputs-
Repo: https://github.com/shudv/memotable