Expandable Row Query Context Has Changed — Existing Apps May Break

💬 App Building
1

Hi Retool team,

I’ve noticed a recent change in behavior when triggering JS queries from components placed inside expandable row sections of a Table component.

:white_check_mark: Positive change:

It looks like we can now use i, currentRow and currentSourceRow inside JS queries triggered from buttons or components within the expanded row.

This is great — it's much more ergonomic than the older workaround where we had to use, e.g.

const row = table2[table1.selectedDataIndex].selectedRow;

:warning: But this may break existing apps:

Previously, it was possible to access external components in a query that was triggered from inside the expanded row, and they resolved correctly (or at least predictably). Now, when a query is triggered from inside the expanded row, references to external components like table17.selectedDataIndex appear to return null, or fail to resolve entirely, even when the same query works fine if triggered from outside the row.

For example:

const selectedImages = table18[table17.selectedDataIndex].selectedRows;

…works when triggered globally, but fails with:

Cannot read properties of null (reading 'selectedRows')

…when triggered from a button inside the expanded row — because selectedDataIndex is no longer populated in that context.

It seems like this is due to a scoping change — Retool now isolates the expanded row context more strictly (which is good), and the JS query triggered from within an expandable row no longer has access to outer table state by default.

But this change might silently break existing apps that rely on accessing selectedDataIndex or other external component state.

:question:Questions:

  1. Can you please confirm this has changed and has it now been applied to all tables, or only new ones?
  2. Is there a recommended way now to reference outer components safely from inside an expanded row component? What other variables can we use on top of i, currentRow and currentSourceRow
  3. Could there be a compatibility mode (or deprecation warning) to catch this kind of usage before apps break?

Again — the addition of i, currentRow and currentSourceRow is a very welcome improvement, and I’ll refactor accordingly. I just want to ensure this behavior is clearly understood and ideally won’t break existing apps unexpectedly.

Happy to share a minimal reproducible example if helpful.

Thanks!
Miguel

2 Likes