Bug: React SKD `useTable` `isReady` reverts to `false` after first row event

[sean256]

Summary

The React useTable hook's isReady boolean correctly flips to true when onApplied fires, but reverts to false on the very next row insert/delete/update event and stays stuck there permanently.

Root Cause

The subscribe callback passed to useSyncExternalStore calls computeSnapshot() inside its onInsert/onDelete/onUpdate handlers, but computeSnapshot was not listed in subscribe's useCallback dependency array. This means subscribe captured a stale computeSnapshot closure that permanently held subscribeApplied = false.

Reproduction sequence

1. useTable mounts, creates a subscription
2. onApplied fires → setSubscribeApplied(true) → re-render → computeSnapshot is recreated with subscribeApplied = true → isReady briefly returns true
3. A row event (insert/delete/update) arrives → the handler inside subscribe calls the stale computeSnapshot (still capturing subscribeApplied = false) → writes [rows, false] into lastSnapshotRef
4. isReady drops back to false and never recovers, since nothing causes subscribe to re-capture the updated computeSnapshot

Impact

• Any app relying on isReady for something like, handling stale data, loaders, etc, will not function properly
• Only affects the React hook — Svelte and Vue versions use mutable refs (writable/ref) so their isReady isn't captured in a stale closure

Fix

Add computeSnapshot to the subscribe dependency array in src/react/useTable.ts:

     [
       connectionState,
       accessorName,
       querySql,
+      computeSnapshot,
       callbacks?.onDelete,
       callbacks?.onInsert,
       callbacks?.onUpdate,
     ]

[bfops]

Hey @sean256, thanks for filing an issue! I think you may have stumbled across an issue that we fixed in the latest release (2.0.3) - Can you check if that version fixes it for you?

[sean256]

Still bugged for me in 2.0.3
Looks like the computeSnapshot is still missing in the dependency array. Add that fixed it for me locally.

[bfops]

Ah rats, looks like we solved a different bug then. We'll work on fixing this soon!