# Selection Attribute on Table Component in Perspective

**URL:** <https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333>\
**Category:** Ignition\
**Tags:** perspective\
**Created:** [June 12, 2025, 4:09pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333 "2025-06-12T16:09:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\
**Post date:** [June 12, 2025, 4:09pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333/1 "2025-06-12T16:09:34Z")

</div>

Hey, I just wanted to get some perspective before filing a bug report.

Version: 8.1.32  
Module: Perspective

Some context: I was making a table that has some styles, and a nested style for a single cell in each row based on pass or fail of a test. When the data refreshes every 5 seconds, I have a bit of logic to set the row to the same record in the data (through id of the selected row) or not depending on user's set preference (toggle switch). However, it will randomly change how the selected data is presented:

> **Images**
>
> ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/9/b9ce55d9b87df743755bc2034e4a696f0f750773.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/5/e573c867639238dce37b60d975738eca645d85fb.png)

One is an object that contains the style and the value, the other just the value object. It feels like the intended workings of the `selection.data` property is to just contain the value, but all I need is for it to be consistent. I've got a work around by checking what keys the data object contains, but it makes my expression a bit clunkier. This also happens with the nested style object for the cell, and they don't always happen at the same time, either.

If this was fixed in an update, let me know, otherwise I'll start filing the report

---

<div class="post-metadata">

**Author:** ![Kevin\_Flener](https://avatars.discourse-cdn.com/v4/letter/k/74df32/32.png) [@Kevin\_Flener](https://forum.inductiveautomation.com/u/Kevin_Flener)\
**Post date:** [June 12, 2025, 4:23pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333/2 "2025-06-12T16:23:53Z")

</div>

I think when you're seeing just the style and value keys, it's because you don't have a row selected. (the first image). I'm fairly certain when your data refreshes, you no longer have a row selected.

After selecting a row, you get the full set of keys and values.

---

<div class="post-metadata">

**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\
**Post date:** [June 12, 2025, 4:35pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333/3 "2025-06-12T16:35:51Z")

</div>

I set the row selected property when the data gets changed/updated, so if it's a race condition based on this, then my work around sounds like it may be a tad more permanent.

However, I'm a little skeptical, as the table maintains the selected index as long as that index still exists at the very least (I haven't tried having an index greater than length of the data coming in, yet), and `selection.data` reflects that as far as I've seen. I'll edit my post with a minimum reproduction example project if anyone else wants to try. I just find it weird that a builtin attribute would be weird like that, but it very well could be my manual setting of a property it's based on that triggers the behavior, too. I just want to know a little more about why something like this would happen so that I can try to avoid it if it's not a bug, or to bring visibility to it if it is

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 12, 2025, 4:41pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333/4 "2025-06-12T16:41:17Z")

</div>

The table component's `props.selection.data` is driven **only** by the browser, and is only updated when the browser makes or detects a row selection change. Bindings that deliver updates to `props.data`, or script assignments to `props.data`, will cause the browser to drop row selection. If you are manipulating row selection programmatically after such a change, your manipulation will race with the browser and will likely be discarded. There is no fix for this, other than to not use polling bindings when also using row/column selection.

---

<div class="post-metadata">

**Author:** ![Xander\_Dawson-Fink](https://avatars.discourse-cdn.com/v4/letter/x/73ab20/32.png) [@Xander\_Dawson-Fink](https://forum.inductiveautomation.com/u/Xander_Dawson-Fink)\
**Post date:** [June 12, 2025, 5:12pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333/5 "2025-06-12T17:12:35Z")

</div>

Ah, so it is a race condition. I'm a little upset to keep a race in production code, even if it is just for viewing the results, but the people up top want realtime results. I'll bring this up to them, just to make sure, but since I have a catch for both scenarios, I'm sure they'll want it anyway.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 12, 2025, 6:50pm UTC](https://forum.inductiveautomation.com/t/selection-attribute-on-table-component-in-perspective/107333/6 "2025-06-12T18:50:41Z")

</div>

> [@Xander\_Dawson-Fink](#):
>
> want realtime results

Use cell render views where you want live data and have those nested views obtain that data themselves (indirect tag bindings if this is tag data). Then the table can use static data obtained once (computed on view load, perhaps).
