I'm experiencing some strange behaviour where my table is not selecting the first row after loading the table data.
Any help is appreciated!
Goal
Select the first row in the table after loading the data.
Reproduction steps:
1. Create a simple SQL query to fetch some data.
2. Link the data to a table and set the default row to index 0.
3. Create a transformer that logs the selectedSourceRow of the table.
Behaviour
The selectedSourceRow starts out as null, which is normal because the table does not yet contain the fetched data.
The selectedSourceRow actually shows the data of the first row.
The selectedSourceRow changes to null again (I can't figure out why this is happening)
Iād like to suggest an alternative and ask you a follow-up question regarding your current setup.
Consider using the selectedRow property of the table component instead. This will return the columns that are part of the table component's UI. The selectedSourceRow property retrieves data from the underlying data source.
Could you please share which version you are using? You can find this information by clicking the ? button located in the bottom right corner, as shown here:
Even when using selectedRow instead of selectedSourceRow, the behaviour remains the same where the selected row is cleared after the data has been loaded into the table.
I can write some logic to bypass this issue (e.g. selecting the first row in the succes handler of the getTrucks query), but I would expect the Default row and Default index settings to do this for me.
I'm pretty sure this used to work in the past. Has there been a change recently that causes this behaviour?
Hey @avr, got it that you are seeing the same behavior when using selectedRow and thank you for providing additional context on this working before.
Another thing you can check - what is the component state? Is the value null?
I can also take a closer look at this issue if you are able to share your app export (note that this does not export any underlying data, just the app structure and hardcoded values).
You can try using the nullish coalescing operator?? to provide a default value if an expression on the left is possibly null or undefined. Have you tried this?
Hi @avr , I realized you did link a json exort of your app. Thank you
I was able to validate the behavior you are describing which indeed looks like a bug on our end. I have filed this with our engineering team and we will post further status updates here.
I found this post after searching for issues related to my table not automatically having the first row selected when I launch my app..
@pascual I assume we should expect that when the 'Default index' is populated as 0, the first row in the table should be selected when the app is first loaded? Is that correct?
I've talked to our team here and they're definitely aware of this particular issue; it seems there is a race condition on initial page load that is causing selectedSourceRow to become unset.
It's hard to say when we'll be able to push out a fix, but there's a relatively straightforward workaround you can utilize, in the meantime. Try defining a success handler similar to the following on the query that is fetching your table's data.
The trick is to debounce it just enough to bypass whatever race condition is at play. I hope that helps! Let me know if you have any follow-up questions and I'll be sure to provide any additional updates here as soon as possible.
Even if I use a work around and it works (but it is intermittent, especially when loading larger datasets), the errors still happen. Our app uses this pattern a lot (parent table up top, clicking a row displays a lot of information, from many data sources), and we're seeing around 20 error messages every time someone loads a page.
This never used to happen. We woke up one day to it.
Looking into it more, I'm wondering if there was an update to the run behavior?
Now the query to load the child data (that depends on the parent data to have loaded and the row to be selected) runs on page load, so it will fire without the data from the parent table (slug will be null).
The solution will be to select the Manual run behavior, and add an event to the parent table to fire the child query(s) when a row is selected. Unfortunately for me, this will mean manually calling over 20 queries and maintaining that
Is there a way to have a run behavior that says "query runs when a variable it depends on changes" - like the automatic option, but without the "on page load" bit?!
By default, queries have always run on initial page load; they didn't, however, display corresponding notifications until a few weeks ago. The biggest reason for this change, other than general consistency, was to improve visibility into app performance.
Instead of changing these queries to run manually, I would recommend dynamically disabling them under specific conditions in order to prevent them from running on initial page load.
It requires a little bit of extra work, but not as much as manually triggering them! I hope that helps. And don't hesitate to follow up with any additional questions!
Hey @Simon_Damiaens! We have a fix coming out for a related issue, but I'm not 100% confident that it will address this particular use case. If you haven't already tried, I recommend implementing the workaround described above.
