The ability to nest tables with the expandable rows is (potentially) allowing us to present data from related tables in a very intuitive format. However, I am finding that it can be difficult to target the desired nested table for various purposes.
For simplicity, let's call the tables mainTable and nestedTable
I have a toolbar icon on the nested tables that will clear the selection on that specific nested table. Simple enough. Have implemented this many times on many non-nested tables, and seems to work in the nested tables without any special accommodation.
Typically, I also add an expression in "Hidden" to dynamically show/hide this clear-selection toolbar button depending on whether a row in the table is actually selected or not. The usual !nestedTable.selectedRow doesn't work. I tried !nestedTable[ri].selectedRow but that doesn't work either.
How do I express "this nestedTable" in the Hidden field?
Relatedly, I've also had to do some convoluted workarounds to get components outside of the tables (modules and forms in modals) to understand which row in which nested table I want them to be referencing. I am starting to think that I am missing something simpler. Is there an obvious way to get the index number of the nested table you are currently "in" to be able to express nestedTable[n].selectedRow… or similar?
I use nestedTable[mainTable.selectedDataIndex].selectedRow. To make sure it doesn't break when user clicks on another row of the main table, I have a collapse row event every time a different row in the main table is selected, this ensures the expanded row is only for the main table's selected row
modules and custom components can def seem like an overly complicated and inefficient workaround for passing values between parent and module. unfortunately using input and outputs are probably going to be the usual route to take, this can cause a re-draw every time the value of an input changes (i think this is the case only for custom components, but i honestly can't remember 100% right now). this could get expensive, especially if you're concatenating 1 letter at a time when a key is pressed... every letter added or removed causes the whole module to redraw
i think i remember reading someone's post who ended up using local storage or cookies as a sort of shared memory space (browser localStorage not retool localStorage... your browser/desktop filepath vs retools server uri), if i stumble on the post that again i'll link it here
I happened upon the same strategy as you for some of these nestedTable quirks – to get our "edit row data" forms to edit the correct row, I did same. I happened upon it just by snooping around the table state, looking for something I could hook onto. So, using event handlers on the tables, clicking on any row in a nestedTable causes that nestedTable's parent table row to be selected. Then, the form looks at nestedTable[mainTable.selectedDataIndex].selectedRow.
In my screenshot, TJTable is the parent table, TDTableNested is the nested table.
Without doing that, it was a crapshoot as to whether form loaded the row you clicked on in the nestedTable, or, a row from another nestedTable entirely! At first I thought I was going crazy, it seemed utterly random.
We can't do the collapse events on every table, because one of the benefits to the nested tables that is great for us is to be able to view the data of two or more nested tables at the same time.
While the make-sure-the-parent-table-row-is-selected workaround works, it feels clunky, and doesn't apply to some other things, like hiding/showing toolbar buttons on a per-nested-table basis. Feels like there should be a way to say "this iteration of the nested table" and it is evaluated for each iteration of the table separately.
Great workaround, it does get complicated with nesting tables inside of collapsable rows of a parent table
I can definitely check with our front end/UI team to see if there is an iterator we might be missing that we have access to for referencing this nested tabled in this specific row.
My only thoughts would be that some users have multiple nested tables inside of a parent table's row. Which would then lead to another level of iteration (second rows third tables first row, etc. )
Could you elaborate more on the final part where you said "evaluated for each iteration of the table separately"?
Just to add my 2 cents to this. This week I found myself trying to do the following:
add a Row event in a nested table
Have the row event button trigger a query (delete a record) that has additional scopes
I'm trying to pass 2 values, the id of the main table's row where the table is nested, and the id of the nested table's selected row (where I clicked the button).
For the first one I pass table1.selectedRow.id (with the workaround I mentioned in my past above where the expanded row collapses if another row is selected, which is not ideal)
For the second one I pass table2[table1.selectedDataIndex].selectedRow.id. HOWEVER, i get a dependency error trying to do this, and as such it passes an undefined value....
This dependency error doesn't happen when I write the same variables within the query, which is fine. But I have 2 or 3 similar tables and I wanted to just keep one query, thus the additional scopes.....
In any case, being able to reference currentTable such as currentRow would be super helpful in these instances.
I can see a ton of use cases where two params as you described will be needed to access from parent and nested table.
The dependency issue is interesting, not sure if that is suppose to happen in that case
So you are saying the issue went away when you define the values as individual variables that point to the data which had been triggering the dep error not intended behavior but a very clever work around!
Can definitely add these comments on to the ticket to surface the dep bug as well as your +1 for having these variables be easier to access.
)
not intended behavior but a very clever work around!