Currently, it's difficult to process actions on a range of selected rows, since we don't have access in the selection data to which row indexes are selected, we can only see the data in the rows, and the last selected row index.
It would be useful to add a props.selection.selectedRows as a list which contains the row indexes selected.
For example, I want users to be able to select a bunch of rows and use a button to move the data in those rows to somewhere else and then remove those rows from the table. Removing the rows is hard!
Current thinking is that I will add the props.selection.selectedRow value into a custom.selectedRows list on row click, and keep the list the length of the props.selection.data list length using FIFO. Certainly not very nice
E.g.
# on rowClick
def runAction(self, event):
selectedRow = event.rowIndex
selectionLength = len(self.props.selection.data)
selectedRows = self.custom.selectedRows
selectedRows.append(selectedRow)
selectedRows = selectedRows[-1*selectionLength:]
self.custom.selectedRows = selectedRows
I would do something like this:
Expression binding bound to this.props.selection.data
data = [{k: v.get('value') if hasattr(v, 'has_key') else v for k, v in rowData.iteritems()} for rowData in self.props.data]
return [data.index(dict(v)) for v in value]
But even then... i don't fully like it. If you have duplicate rows, it may return the incorrect row? I guess if each row had a unique identifying key, you could check against that to verify you have the correct row.
Your current run action doesn't work correctly if you shift click to select multiple in one go.
Bummer, so it doesn't... my next option would have been your way, although yours looks more sophisticated than what I was going to do 
so i might just borrow yours, thanks!
1 Like
While I'm open to the idea of this feature, there's a potential problem we could run into...
This feature requires some new value be injected into each row selected so that we have a structure approximating this within props.selection.data[x]:
You can probably see why this might be a problem; what if the data of the table already contains a column with a key of index? We've just overwritten the user's data with our own injected value. As we try to settle on a key that clearly conveys what our injected value would be, we would have to tread a fine line between making it simple enough to be useful, but unique enough to have 0% chance of clobbering a user's existing data.
I'm less open to the idea of props.selection.selectedRows because that's a near duplication of selectedRow. That's not to say we couldn't do it, but... ew. Maybe we deprecate selectedRow for 8.3 and replace it with selectedRows? That might work.
Yep, agreed it's ugly having both. Only reason to do that was for backwards compatibility, but certainly better to remove selectedRow in favour of selectedRows.
Inserting the 'index' into the selection.data is definitely not something IA should be doing for your exact reason, unless the name of the key is configurable, which would be useful!
The issue I have is manipulating rows when clicking on views used in the table cells, as the only link you have back to the table row from within the cell view is via the rowData passed into it.
1 Like
