Uh oh!
There was an error while loading. Please reload this page.
fix(components,plugin-dashboard): the static-data table widget renders instead of looping (#4618) - #4623
Merged
Merged
Conversation
…s instead of looping (#4618) Reported as a `table` dashboard widget crashing into the error boundary with "Maximum update depth exceeded", thrown at data-table.tsx:788 — a line in the sticky-offset layout effect that has nothing to do with the cause. Three hops, all inside data-table.tsx: the `columns: rawColumns = []` destructuring default evaluates a fresh array every render, an identity-keyed useMemo turns that into a fresh `initialColumns`, and the `useEffect(() => setColumns(initialColumns))` sync writes state for it — scheduling the render that regenerates the literal. React throws from the layout effect keyed on `columns` because that is the synchronous nested-update path it counts. Also fixes the two reasons the same widget rendered nothing once it stopped crashing: neither dashboard surface supplied the REQUIRED `columns` key, and DashboardGridLayout read the authored rows as `widgetData?.items` — `[]` for the array shape its sibling has always handled. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017Qqyix2QcnpUC9XeYVDzx3
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
…4618) eslint net count vs origin/main for the two touched packages: 920 -> 918 warnings, all in @object-ui/components, and the delta is exactly the two `react-hooks/exhaustive-deps` warnings this card's fix removes — The 'data' conditional could make the dependencies of useMemo Hook (at line 759 / 899) change on every render. which is the reported defect's own shape, reported by the linter on main all along. The first draft of the guard added three `no-explicit-any` warnings back; `readonly unknown[]` plus a `Record< string, unknown >` narrowing, and `DataTableSchema['data']` for the shared empty, add none. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017Qqyix2QcnpUC9XeYVDzx3
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
yinlianghui
marked this pull request as ready for review
August 14, 2026 03:30
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#4618
A dashboard widget authored as
{ id, type: 'table', options: { data: [ … ] } }fell into theerror boundary with "Maximum update depth exceeded", while
bar/line/area/donut/metricoff the identical static surface rendered clean.Three defects, measured separately. The crash is one of them; the other two are why the same widget
still rendered nothing once it stopped crashing.
1. The loop —
packages/components/src/renderers/complex/data-table.tsxThe filing pointed at
data-table.tsx:788, which issetMeasuredStickyLefts(null)inside thesticky-offset layout effect. That is the throw site, not the cause — a layout-effect state write
is the synchronous nested-update path React counts, so it is where the limit trips.
The actual cycle, every hop inside
data-table.tsx::637columns: rawColumns = []columnskey:722-728initialColumns = useMemo(() => rawColumns.map(…), [rawColumns]):866-868useEffect(() => setColumns(initialColumns), [initialColumns]):785-815layout effect keyed on[stickyLeadingCount, columns]→:788Self-sustaining, because the unstable value is derived inside the component: the table's own
re-render regenerates the literal that scheduled it. Nothing external has to change.
Why it was never seen:
useState(initialColumns)seeds from the very array the mount-render's effectthen re-sets, so the first sync is an
Object.isno-op. Mount is safe; the loop starts at render#2 — the first time any host re-renders the tile. Every existing suite renders once.
Fix, at both hops:
EMPTY_COLUMNS/EMPTY_ROWSreplace the per-render[]literals (thedestructuring defaults and the non-array
datafallback), so "absent" is a stable value;(
setColumns(prev => columnsAreEquivalent(prev, initialColumns) ? prev : initialColumns)).The second half is load-bearing rather than belt-and-braces: both dashboard surfaces rebuild the
child node on every render, so with fix 3 below they now hand the table a freshly-derived
columnsarray each time. Shallow per column, on purpose — column entries carry render functions, and
comparing those by identity is exactly what the sync already did.
2. The blank —
columnsis a REQUIRED key neither surface suppliedDataTableSchema.columnsis required (packages/types/src/data-display.ts:369), and both surfacesbuilt the static node without it whenever the author declared no
options.columns. Measured onorigin/main: zeroth, zerotd, one emptytrper row — the table drew rows it had no cellsfor. A "no error boundary" assertion alone would have passed on that, which is the silent blank
#4612 / #4613 / #4614 spent three cards removing from these surfaces.
The
provider: 'object'half of this same widget family has always derived columns from the rowswhen none were declared (
ObjectDataTable.tsx:327-339), so the static half was the odd one outinside one family.
deriveStaticTableColumns(plugin-dashboard/src/utils.ts) is that behaviourreaching it — first row's keys,
_-prefixed dropped, headers humanized through the helper theobject path now shares (
humanizeFieldKey, lifted out ofnormalizeColumnsunchanged so the twohalves cannot drift). An author-declared column list always wins: a whitelist is never a
starting point.
3.
DashboardGridLayoutnever read an authored arrayIts static branch resolved rows as
widgetData?.items || []—undefined, hence[], for theauthored ARRAY shape.
DashboardRenderer's mirror of the same branch has carried theArray.isArrayarm all along. Visible pre-fix as "No results found" under correct headers whenevercolumns were declared (so the loop did not mask it).
Red-first, verbatim
pnpm exec vitest run --maxWorkers=2on the two new suites, pre-fix — both dashboard surfaces:Angle brackets in the two quoted snippets above are spaced (
< p,< DataTableRenderer >) so theGitHub body sanitizer does not eat them as HTML tags; nothing else about them is altered. The
boundary's rendered text matched the filing exactly, including the "Retry" button. Also red
pre-fix:
renders a real table …(expected null to be truthy— the boundary replaced thetable), and, for the grid only,honours author-declared columns …(
'…Recent InvoicesInvoiceNo results foundTry adjusting your filters or search query.' to contain 'INV-1'— defect 3 with the loop out of the way).Component-level, pre-fix, with the schema stable and only the host re-rendering:
Coverage
packages/components/…/__tests__/data-table-render-loop.test.tsx— the loop at the rendererlevel, plus the two controls that stop the fix from being "we removed the sync": declared columns
still reach the DOM under the same host churn, and a real column change still re-syncs.
packages/plugin-dashboard/src/__tests__/StaticTableWidget.test.tsx—describe.eachover BOTHsurfaces: no boundary under churn; a real table (derived headers and cells); declared columns
honoured and not widened; an empty
data: []invents no headers; a staticbarwidget on thesame surface unchanged.
Verification
Consumer radius — census by import:
data-tableis consumed byplugin-dashboard(
DashboardRenderer/DashboardGridLayout/ObjectDataTable),plugin-detail(RelatedList) andplugin-grid(ObjectGrid);plugin-listandapp-shellreach it through those. Repo-rootpnpm exec vitest run --maxWorkers=2over all six: 767 files, 7228 passed, 1 skipped, 0 failed.Reverse verification (patch +
git checkout+ sha256-verified restore, nevergit stash) was runas a partition rather than one revert, and the result corrected my own expectation — worth reading
before review:
data-table.tsxonlyorigin/main)Row A is the one I predicted wrong. With the dashboard supplying
columns, reverting the componentsfix does not bring the crash back on either dashboard surface: a declared
columnsarray comesoff the schema, which is stable across the table's own re-renders, so the churn is no longer
self-sustaining. In other words the dashboard-side fix alone would have made the reported symptom
disappear — which is exactly why it is not the fix. Row A's red is the components-level suite, the
only thing pinning the cause, and it stays live for any consumer that omits
columns. Row B is themirror: the components fix alone removes the crash and leaves the blank. Neither half papers over the
other, and each is load-bearing on its own.
sha256 of all three files matched their pre-revert values after every restore;
git statusclean.Grading — patch, by measurement. Full
.d.tsmanifest (231 files across both packages) rebuiltwith
dist/and*.tsbuildinfocleared, reproducible across three builds, diffed againstorigin/main:@object-ui/componentsis byte-identical — a pure behaviour fix. The single deltain the whole set is
plugin-dashboard/dist/utils.d.ts, which gains two additive declarations(
humanizeFieldKey,deriveStaticTableColumns) and is not reachable through the package entry —index.d.tsnever references it andexportsmaps only.. Module-local, additive, nothing removedor narrowed: patch on the #4496 precedent. Never major.
Type-check, PREFIX-filtered (direction: downstream consumers,
--filter '...@object-ui/components' --filter '...@object-ui/plugin-dashboard') — 31 packages,0 errors. Two false reds along the way were missing sibling artifacts (
@object-ui/mobile,@object-ui/permissionshad nodist/), cleared by a full workspace build, not by any source change.ESLint, net −2 against an
origin/maincompare worktree (same filter, both sides):@object-ui/components920 → 918 warnings,plugin-dashboard327 → 327, and the entire delta isthe removal of
— the linter had been reporting this defect's own shape on
mainall along. No warning added: theguard is typed
readonly unknown[]with aRecord< string, unknown >narrowing rather thanany.Gate battery, all PASS:
check-{control-bytes, phantom-dependencies, changeset-presence, changeset-no-major, changeset-fixed, type-check-coverage, lint-coverage, doc-links}.mjs. Control-byteself-scan over every changed file including untracked
(
grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]'): no hits. One changeset, patch/patch.Surface respected: nothing under
apps/site/**orexamples/schema-catalog/test/**— acatalog-side render pin for the static
tablewidget (there is still no catalog entry exercising it,which is why nothing caught this) belongs to the #4616 seat's render-pin extension, not here.
content/docs/releases/**untouched.Filed, not fixed: #4629 —
ObjectDataTable'sfinalDatafallback is the same per-render literalone file over, feeding the
derivedColumnsmemo. It cannot loop (memo only, and the child's statewrite does not re-render it), so it is observation-class and out of this card's scope.
Generated by Claude Code