# \[IGN-7140\] Perspective Table - add \`props.selection.selectedRows\` **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [February 3, 2023, 1:19am UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378 "2023-02-03T01:19:13Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [February 3, 2023, 1:19am UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/1 "2023-02-03T01:19:13Z")
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. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/a/0a10d9500bb4c09d76e045c30cb93c8c9153bf09.png) 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. ```auto # 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 ``` ---
**Author:** ![Matthew.gaitan](https://avatars.discourse-cdn.com/v4/letter/m/59ef9b/32.png) [@Matthew.gaitan](https://forum.inductiveautomation.com/u/Matthew.gaitan)\ **Post date:** [February 3, 2023, 3:58am UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/2 "2023-02-03T03:58:17Z")
I would do something like this: Expression binding bound to `this.props.selection.data` ```auto 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. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [February 3, 2023, 4:18am UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/3 "2023-02-03T04:18:54Z")
> [@Matthew.gaitan](#): > > 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! ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [February 3, 2023, 5:48pm UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/4 "2023-02-03T17:48:53Z")
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]`: ![Screenshot 2023-02-03 at 9.44.45 AM](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/3/43dcb94fede35320650ef933f098919bbdf55309.png) 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. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [February 3, 2023, 10:06pm UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/5 "2023-02-03T22:06:51Z")
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. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 13, 2024, 8:10pm UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/6 "2024-03-13T20:10:20Z")
As per usual, I'm a year-late to the topic... @nminchin, Correct me if I'm mistaken, but I believe the Tree component has the feature (multi-selection indexing) that you're requesting. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/3/035b9356f49804d23650047ba45cded56ac69c4d.png) @cmallonee, I'm struggling to understand why user data would have to be transformed to handle this request? I am stuck with a feeling that adding a key (of any name) with a value that ALWAYS matches the data[#] index is a bit redundant. Obviously, the details matter here, but wondering if you can shed some light? I'm hoping that the more difficult problem is how to handle backwards compatibility while keeping property list 'clean'. ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 13, 2024, 8:28pm UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/7 "2024-03-13T20:28:46Z")
While it's true the Table has `props.selectionData`, the objects in that list contain only the data of the row, with no insight into the index of the row in the dataset/list. Consider the following `data` value, where an object seems to be repeated: ```auto [ {"name": "A", "value": 1}, {"name": "B", "value": 2}, {"name": "C", "value": 3}, {"name": "A", "value": 1} ] ``` If a user selects the last row of the data, how are you to know if `props.selectionData` represents the first or last row of data? Due to the complete dataset containing no guaranteed unique value, there is no way to perform something like an update query based on the provided data. FOr Perspective to expose which row is truly selected, we would need to inject some sort of `index` property, which would reflect the 0-based index of the row each entry in `props.selectionData` represents. Now, here's the problem: what if users have prepared their data with an `index` key which actually means something to them? ```auto # select * from MyTable where index<30; [ {"index": 1, "name": "A", "value": 1}, {"index": 15, "name": "B", "value": 2}, {"index": 20, "name": "C", "value": 3}, {"index": 21, "name": "A", "value": 1} ] ``` If a user clicks the last row again, we can't run the risk of replacing `21` with `3`. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [March 22, 2024, 4:48pm UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/8 "2024-03-22T16:48:12Z")
I see! I was assuming (shame on me) that the `props.selectionData` object (of the Table component) was a derivative of (populated by) the `props.selection` object. I see now that the manual modification of one has no effect on the other... Perhaps one way to accommodate the request (for 8.3) would be to: a) Move any configuration props out of the `props.selection` object to a new `props.config` object, and make `props.selection` an array. b) Move the selection data array values to a child object of the respective array, whose siblings contain the new index prop(s). Something resembling: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/d/1db9e4f9e205f1441f838cdf0d95e1db0efac06d.png) 🤔 ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [March 22, 2024, 5:30pm UTC](https://forum.inductiveautomation.com/t/ign-7140-perspective-table-add-props-selection-selectedrows/69378/9 "2024-03-22T17:30:10Z")
While that might function, it's also a surprisingly big ask because we're unlikely to just remove the existing props in favor of this pattern, which would leave us with nearly identical data structures which both more-or-less represent the same data. We're actually more likely to modify the structure of the existing `selection` array than we are to introduce a sibling which does essentially the same thing. While 8.3 affords us the option to introduce "breaking" changes to the product, we still intend to only do so in spots where it absolutely must be done to advance the product - and this does not seem to be one of those spots.