Implement Throttled Update Notifications for Query Reactivity

Problem

Currently, every mutation or sync triggers immediate reactivity and query invalidation.
In high-update scenarios (e.g., rapid optimistic updates, bulk sync events), this causes excessive re-rendering, layout thrashing, degraded scroll performance, and input lag.

Debouncing is not suitable because it would delay the first user-driven update, breaking perceived responsiveness.

Optimistic updates must render immediately. Only subsequent updates need rate limiting.

Proposed Solution

Introduce throttling of query invalidation and reactivity notifications.

Behavior

• First mutation immediately triggers query reactivity.
• Subsequent mutations within the throttle window are grouped.
• Only one re-render is allowed per throttle window.
• After the throttle window expires, if additional mutations occurred, flush once and reopen the window.

Default Settings

• Target: 120fps smoothness.
• Frame budget: 8.3333ms per frame.
• Default throttle interval: 8.3333ms.

API Design

Global configuration:

configureDb({
  updateThrottling: {
    intervalMs: 8.3333
  }
});

Optional per-query override:

const { results } = useDb()
  .from('posts')
  .withUpdateThrottling({ intervalMs: 16 }) // e.g., throttle to 60fps if desired
  .get();

Design Principles

• Store mutations always apply immediately.
• Only reactivity and re-rendering are throttled.
• Optimistic updates behave identically to server sync updates with respect to throttling.
• No observable data inconsistency.

Constraints

• No batching or throttling in strict testing mode to preserve determinism.
• Throttle window must be precisely timed.
• Throttling must be fully internal; developers should not manage timers manually.

Future Work

• Adaptive throttling based on device performance or application state.
• Metrics collection for mutation vs render rates to optimize default settings.

No files, tests, or entry points are named. First locate the query invalidation and reactivity notification paths, then inspect how strict testing mode is detected. Done means immediate first updates, throttled subsequent notifications, configurable global and per-query intervals, and deterministic strict-mode behavior.