Open fnimick opened 11 months ago
Actually, this is very odd, I figured out what's happening.
If the incoming table data is updated via a call to invalidateAll()
in sveltekit, the row props appear to get desynchronized from the actual table. This leads to behavior such as where checking a row marks a different row as checked, even though the id in $selectedDataIds
is correct.
I suspect this is due to the row prop association to the row not being recalculated when the id assigned to each row changes. The row props are stored by index (I think), so if e.g. a row had id 1 and index 3, and then the data updates such that the row with id 1 is at index 1, checking that row now marks the row at index 3 as checked in row props.
Adding to this. The issue only pops up when linkDataSubRows: true
. I'm experiencing the same issue when I have a basic table with sub rows that expand and the select plugin. It initializes with random rows being selected even though the selectedDataIds
is empty. The only row that works as expected for me is id = '0'
, its children, and anything at the top-level without sub rows. Everything else misbehaves and never corrects itself.
@shawnphoffman are you sure? in my case, I am not using subrows, yet I still experience this desynchronization from the table input data when the input data is updated with some rows removed and other rows added compared to the currently selected row set.
@fnimick @shawnphoffman I think I experienced this issue also when i was using table.display
<<< it seems to not maintain sync with the 'id' of the cell / row.
Use table.column
instead and I think it should solve your issue! 🤞🏾
This sounds very similar to an issue I'm experiencing which I put together on the discussions board. I'm not using table.display
, instead have been using table.column
which hasn't resolved the problem.
https://github.com/bryanmylee/svelte-headless-table/discussions/186#discussion-6095437
Found a solution:
const { selectedDataIds } = pluginStates.select;
setTimeout(() => {
$selectedDataIds = get(selectedTraktorCollectionIds);
}, 0);
Don't ask why))) (because I don't know proper explanation, maybe someone smarter can explain)
This sparked me to dig into it again and I finally figured out a solution for my issues. My issue stemmed from the combination of addSelectedRows
, addSubRows
w/linkDataSubRows=true
, and addExpandedRows
.
My table is basically a file/folder tree and it was misbehaving by pre-selecting entire folder structures that didn't have any files in them.
Digging through the documentation I noticed that when addSubRows.children
is a string, that property must exist. For me, this wasn't the case if a leaf folder didn't have any files/folders in it (it was undefined). So, I switched it to a function that checks for the property and, if undefined, return []
. This too was buggy by selecting everything despite the documentation. On a whim, I switched the else case to return undefined
and everything works perfectly.
I haven't dug into the library code yet but it looks like there is a truthy bug when it comes to checking whether or not an item has children and that subsequently trickled up and caused issues with the "is the row selected" logic. Anyway, I hope this helps someone...
The Fix
Before:
sub: addSubRows({
children: 'someProperty',
}),
After:
sub: addSubRows({
children: (item) => {
return item.someProperty?.length ? item.someProperty : undefined;
},
}),
Weird...
@shawnphoffman Thank you for the extensive and detailed report. You're right in that it's probably a truthiness bug, and I would greatly appreciate if you could file a fix for this issue in the plugin!
Not entirely sure why, this is working in the REPL demo, yet doesn't work in my application. There are no errors logged to the console.
And my SelectIndicator is:
The row's props for the selected state is only true for row 0, and false for all other rows. This does not update along with selections.