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:
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
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.
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
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.
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.
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).
