Repository navigation
fix(svelte-table, vue-table): Keep App* wrappers in sync with new cells and headers - #6633
Conversation
…ls and headers
Svelte's App* wrappers destructured their props, which read the prop getters once, and Vue's setup() read props.cell once. A keyed {#each} or v-for that reused a wrapper with a new cell or header (same id, e.g. after replacing data or columns) kept the first instance for both the snippet/slot value and the context.
Forward wrapper props through getters, read the prop reactively, and provide a live proxy that forwards to the current instance. Prototype methods run against the real instance so per-instance memos never capture the proxy.
🦋 Changeset detectedLatest commit: 9245a93 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to No actionable issue is established from the available evidence; run the adapter tests as part of normal checks before merging. Pre-merge checks |
|
|
View your CI Pipeline Execution ↗ for commit 9245a93
☁️ Nx Cloud last updated this comment at |
🚀 Changeset Version Preview6 package(s) bumped directly, 11 bumped as dependents. 🟩 Patch bumps
|
Related to #6618
When
dataorcolumnsare replaced, a keyed{#each}orv-forreusesAppCell/AppHeader/AppFooterwith a new cell or header that has the same id. The wrappers kept the first instance, so the snippet/slot value anduseCellContext()/useHeaderContext()showed stale values (for example after a refetch).App*wrappers destructured their props, which reads Svelte's prop getters once. They now forwardcell,header, andchildrenthrough getters.AppCell.svelte/AppHeader.sveltederive the extended instance from the current prop.setup()readprops.cell/props.headeronce. The extended instance is now acomputed, and the slot gets its current value.createLiveProxyview that forwards reads to the current instance. Prototype methods are called on the real instance, so per-instance memos (_memo_*capturingself) never see the proxy, and forwarders are cached per key so method identity is stable.datathencolumns, and assert the snippet/slot value and both contexts update. Both tests fail onmain.Notes
useCellContext()/useHeaderContext()now return the live view, not the cell/header object itself, socontextCell === cellisfalse. The alternative is returning a getter or signal like Angular'sinjectTableCellContext(), which is cleaner but breaks the API. Solid has the same pattern but is fine with<For>(keyed by identity); it would only go stale under<Index>.Summary by CodeRabbit