-
Notifications
You must be signed in to change notification settings - Fork 953
fix(Table): only forward necessary props #5527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional Suggestion:
The Payment type definition is missing firstName and lastName properties that are being created in the data and referenced in table columns. Additionally, the addElement function creates Payment objects without these required properties.
View Details
📝 Patch Details
diff --git a/playgrounds/nuxt/app/pages/components/table.vue b/playgrounds/nuxt/app/pages/components/table.vue
index 63cf2fda..b52896cc 100644
--- a/playgrounds/nuxt/app/pages/components/table.vue
+++ b/playgrounds/nuxt/app/pages/components/table.vue
@@ -20,6 +20,8 @@ type Payment = {
status: 'paid' | 'failed' | 'refunded'
email: string
amount: number
+ firstName: string
+ lastName: string
}
const table = useTemplateRef('table')
@@ -224,11 +226,15 @@ const pagination = ref({
})
function addElement() {
+ const firstName = firstNames[Math.floor(Math.random() * firstNames.length)]!
+ const lastName = lastNames[Math.floor(Math.random() * lastNames.length)]!
data.value.unshift({
id: currentID.value.toString(),
date: new Date().toISOString(),
+ firstName,
+ lastName,
status: 'paid',
- email: 'new@example.com',
+ email: `${firstName}.${lastName}@${domains[Math.floor(Math.random() * domains.length)]}`,
amount: Math.random() * 1000
})
currentID.value++
Analysis
Missing firstName and lastName properties in Payment type definition
What fails: The Payment type definition in playgrounds/nuxt/app/pages/components/table.vue (lines 17-23) is missing firstName and lastName properties that are created in the data initialization (lines 34-46) and referenced in table column definitions (lines 131-138). Additionally, the addElement() function (lines 226-235) creates Payment objects without these properties, causing TypeScript type errors and runtime issues when rendering new rows.
How to reproduce:
- Open
playgrounds/nuxt/app/pages/components/table.vue - Note the
Paymenttype definition at lines 17-23 contains only:id,date,status,email,amount - Note the data initialization at lines 34-46 creates objects with
firstNameandlastNameproperties - Note the table columns at lines 131-138 access
firstNameandlastNameviaaccessorKey - Click the "Add element" button at runtime (which calls
addElement()at lines 226-235) - The newly added row will fail to display the First Name and Last Name columns because the object is created without these properties
Result: TypeScript type mismatch errors and incomplete table rows when using the "Add element" feature. The table columns expect firstName and lastName properties on all Payment objects, but the addElement() function creates incomplete Payment objects missing these required properties.
Expected: The Payment type should include firstName: string and lastName: string properties, and the addElement() function should populate these properties when creating new Payment objects, matching the pattern used in the initial data generation.
🔗 Linked issue
❓ Type of change
📚 Description
This PR fixes table reactivity issues by being more selective about which props are forwarded to TanStack Table.
Changes:
reactiveOmitwithreactivePick: Instead of passing all props except a blocklist, now explicitly picks only the TanStack Table core options that should be forwarded (_features,autoResetAll,debugAll,debugCells,debugColumns,debugHeaders,debugRows,debugTable,defaultColumn,getRowId,getSubRows,initialState,mergeOptions,renderFallbackValue).onSortingChange,onColumnFiltersChange, etc.) are only registered when the corresponding v-model is explicitly provided, preventing unwanted prop forwarding that could interfere with TanStack Table's internal state management.defineModel: Allows proper detection of whether a prop was explicitly provided vs. using internal state.📝 Checklist