Table component's .displayedData field does not reflect actual data

App Building
1

Hi, running into this issue where my tableComponent.displayedData doesn't accurately reflect what's currently presented client-side, probably the filter is done only on the frontend? This can be reproduced by sorting a table in any way and then checking the ordering of .displayedData, it keeps the initial data ordering no matter what.

I know some other tickets were created for this issue, were there any updates or potential timeline on a fix? I understand there might be some backwards compatibility concerns, in that case could we simply add a new field to the table component?

Thank you.

2

Hey @Tianjing_Li!

No specific timeline yet but it is part of a larger set of table upgrades that the dev team is currently working on. Is there a specific use case you have for the displayedData property?

3

Thanks for the update,

We currently on an app have row-dependent actions where selecting the row isn't ideal, for example, clicking an action on a specific table row to perform XYZ without selecting that row.
Using table.displayedData[i] from the action's JS handler works fine, but unfortunately sorting/filtering the table in any way breaks its usage.

I know of the existing workaround of selecting the row and using table.selectedRow[<length of selected rows> -1] (since its a multi-select table) but its not ideal for my use-case

4

It's not a big blocker, but open to any other workarounds you might know of that don't involve having to select the row being clicked

5

When you trigger a query with an action button the i variable should reference the row's index in the table's underlying data, so you might try referencing table.data[i] instead.

Does that work?

6

Yup that works - just note it doesn't work when you have a table column that's converted to a button and calls a JS script:
image

Here in handleSearchComment i will reference the displayed value, but if I convert it to a table action the JS script triggered will reference i correctly, which is a workaround I can live with.

Thanks Kabirdas!

7

Ahh yes, that's a tricky inconsistency :pensive:

If you're calling your query from a button column you should have access to the currentRow variable in your query as well (note that this is not available if you call it from an action button). That should give you access to an object with all of the underlying data properties for the row you clicked the button in.