onReset runs before goToFirst — naming/order is misleading

[rickcedwhat-ai]

Problem

onReset sounds like a hook that runs when reset is finished (or after the table has been returned to a clean starting state). In practice it runs before pagination is reset:

// src/useTable.ts — reset()
await config.onReset(createStrategyContext());

if (config.strategies.pagination?.goToFirst) {
  await config.strategies.pagination.goToFirst(createStrategyContext());
}
// …clear cache, autoInit…

Order today:

1. onReset(context)
2. goToFirst() (if configured)
3. clear header map / page index
4. autoInit()

So a wait or DOM settle inside onReset does not run after navigating back to page 1. That makes the hook easy to misuse when the real need is “after reset navigation has settled” (e.g. wait before applyFilters in a consumer flow).

Expected / desired

Either:

1. Rename / document clearly that onReset is a pre-reset / teardown hook (runs before goToFirst), and document that post-settle work belongs in the flow or a wrapped goToFirst, or
2. Add a post-reset hook (e.g. afterReset) that runs after goToFirst + cache clear (and ideally after the table is interactable again), or
3. Move onReset to after goToFirst if that matches user mental model better (would be a behavior change — needs changelog / migration note).

Real-world impact

GUIDEcx flows call table.reset() then immediately applyFilters(...). Filters appear not to apply because the UI is still settling from goToFirst. Putting waitForTimeout(2000) in onReset does not help because it fires before that navigation.

Proposal

Prefer option 2: keep onReset as the existing pre-hook for teardown (e.g. restore unnamed-column lists), and add something like:

afterReset?: (context: TableContext) => Promise<void>;

called at the end of reset(), after goToFirst + autoInit.

At minimum, docs should spell out the current order so the name doesn’t imply “after reset completes.”