[v9] Data update from external source doesn't trigger rerenders in components with table object references #6601

Activity

1. tevinch commented on Oct 3, 2026

   

   tevinch

   on Oct 3, 2026

   More actions

   The first table in the sandbox stays on its initial timestamp while the source data and second table advance. There are two dependencies to connect here: the externally replaced data, and the feature state used by the row model.

   For an application using 9.2.4, a data Context can carry the first dependency without forwarding unused props through intermediate components. Give the provider the same data reference passed to useAppTable, then read that Context and useSelector(table.store, state => state) in the extracted body.

   There is one Compiler detail to retain: put the imperative row-model read in a small hook that keeps its explicit dependencies:

   function useCurrentRows(table, data, state) {
     'use no memo';
     return React.useMemo(
       () => table.getRowModel().rows,
       [table, data, state],
     );
   }

   With Compiler 1.0.0, the same useMemo inside a compiled component had its extra dependencies removed in the generated output, so Context alone still left stale rows. This keeps only the small hook outside compilation; the owner, intermediate component and table body remain compiled. Treat it as a temporary compatibility boundary and recheck after upgrading.

   Here is a complete runnable example using Table 9.2.4 and React 19.3.0. Browser checks covered repeated data replacement, two-second updates, sorting/filtering, both page-reset settings, and empty/refilled data through memoized components. It uses fixed columns and React state; it has not been checked with a live Query client or WebSocket transport.

   Also, table.optionsStore was undefined in the checked React adapter, so the generic options-store subscription example does not provide a drop-in solution for this version.

   👍React with 👍2Reacted by David Mateita and Görkem Karamolla
2. Bhavani2016 commented on Oct 6, 2026

   

   Bhavani2016

   on Oct 6, 2026

   More actions

   Hi, I reproduced this locally with React Compiler enabled on 9.2.4. Disabling the compiler makes both tables update.

   I also added a test on the 9.2.6 checkout that keeps the AppTable subtree memoized. After replacing the data, the subscribed component still displays “Ada” instead of “Grace”. The existing tests pass.

   From what I traced, table.Subscribe listens to table.store by default, while the updated data is in table.options.data. A data-only change therefore doesn’t appear to notify that subscription. As an experiment on 9.2.4, subscribing to a readonly atom around table.getRowModel() made both tables update, though this uses the internal _reactivity API.

   I saw the Context workaround above and would like to help. Would you prefer a supported way to subscribe to row-model changes, or a docs/example update showing the recommended approach? I’m happy to share the test.
3. gorkemkaramolla commented on Oct 11, 2026

   

   gorkemkaramolla

   on Oct 11, 2026

   Contributor

   More actions

   I looked into this and opened #6631 for the createTableHook part.

   The cause: useAppTable creates AppTable once and reads the table from a ref. When the parent's output is cached (the compiler caches <table.AppTable>…</table.AppTable> since table.AppTable is stable), React skips AppTable, so its context keeps an old table. Replacing data doesn't change any table state, so Subscribe can't catch it either. Preact has the same issue.

   #6631 makes AppTable re-render when the owner commits a new table, without extra renders in the normal case. That should fix the table1 case from the sandbox without any workaround.

   One thing it doesn't cover: components that get table as a plain prop outside AppTable still have nothing to subscribe to for data changes. The Subscribe docs mention source={table.optionsStore}, but table.optionsStore is undefined in React/Preact because renderPhaseReactivity sets createOptionsStore: false.

   Would you be open to exposing table.optionsStore as a read-only atom in React/Preact (updated after commit), so <table.Subscribe source={table.optionsStore} selector={(o) => o.data}> works? Or would you rather remove that from the docs and recommend passing data along with table? Happy to do either.
4. Bhavani2016 commented on Oct 12, 2026

   

   Bhavani2016

   on Oct 12, 2026

   More actions

   Thanks for the fix! I tested PR #6631 locally. My regression test, which previously failed with “Ada” instead of “Grace,” now passes. All 37 React adapter unit tests also pass.
   I also tested the two-table data-refresh reproduction against the local PR build with React Compiler enabled. Both tables now update their timestamps and row order every two seconds without the workaround.

   🎉React with 🎉1Reacted by Görkem Karamolla
5. KevinVandy

   added a commit that references this issue on Oct 12, 2026

   fix(react-table, preact-table): refresh AppTable context under cached…

   ...

   3d3648f
6. tevinch commented on Oct 13, 2026

   

   tevinch

   on Oct 13, 2026

   More actions

   The AppTable part now has a released fix: @tanstack/react-table@9.3.1 includes #6631.

   I checked the npm release with React 19.3.0 and React Compiler 1.0.0. The example now uses useTableContext() inside AppTable, with row-model reads inside table.Subscribe for feature-state changes. It no longer needs the extra data Context or use no memo hook.

   Chrome checks passed external data replacement, sorting/filtering, preserving page 2 when reset is disabled, emptying/refilling data, resetting to page 1 when enabled, and three successive two-second refreshes. The same code on 9.2.8 still displays the initial rows after the first update.

   The updated example and runnable checks cover that context-based path. Components receiving table only as a prop outside AppTable remain a separate case; the official guide recommends also passing data or the rendered rows through props.

   👍React with 👍2Reacted by Bhavani Govindaraj and Görkem Karamolla