When I use {{ currentSourceRow }} to disable an action, it works fine. For some reason, {{ currentSourceRow }} is not recognized in the hidden option for an action. I find the hidden option is sort of useless without being able to reference {{ currentSourceRow }}.
5 Likes
Hi @shawncrocker Thanks for posting about this! I've shared your feedback with our team internally.
Originally, our team chose not to support this design pattern, but we've gotten some requests for this feature. We're tracking requests at the moment, and it looks like we'll likely end up adding support.
We'd also love to hear your use case if you're able to share it!
@Tess Hi. Yes so, my use case would be something like, I have an action to set an item as the preferred choice in the list. When the action is used on an item for the first time, a long series of events is triggered to extract data from other API's and then record everything in a database. For this action I do use the current row to disable it if the item is already selected as the preferred choice. I also have another action that will force this string of events to happen again as a refresh. If something happens to some data that exists in files or some how some unaccounted for error occurs during the sequence, the user needs to be able to just refresh and have the API's called again. I want this refresh button to be hidden only if the item in the currentRow does not exist in the database. I do just disable it but it feels cleaner for this type of option to just be hidden. Being hidden, it is also a nice visual cue that the item being displayed in the table has not yet been interacted with before. I have some other BOM tables that allow digging into our CAD system and pulling out drawings of a particular item. Depending on how the item is categorized or if it is revision managed or not, I would like the action that starts up the CAD data search to be hidden rather then disabled. Again, it feels more clear to the user that the option to attach MFG data to that item is completely not available to be used rather then its there and maybe they need to do something to have it become available. When the option is there but inactive it prompts the user to question why. "Why can't I click this button that I see?".
Thanks so much for sharing all of these details! I've shared this with our engineering & design team that will be working on this feature 
+1 from me!
@Tess My use case:
Since the new table component doesn't have a canned "Clear selection" functionality like the legacy table 
, seems we have to roll our own. One of two workarounds I've concocted is to add a "Deselect" action with a clearSelection() script. Obviously I only want this action button to appear on the row that is selected (this is a single-select table). I can't accomplish this without being able to evaluate that this row is also the selected row e.g. Hidden: {{ currentSourceRow.entryID == TDTable.selectedRow.entryID ? false : true }} or similar.
The other workaround I thought of has a similar gotcha – if adding a toolbar button to trigger clearSelection(), there is no way to dynamically show/hide the button depending on whether a row is actually selected or not. So both workarounds are less than optimal (suggestions welcome). Thank you!
Hi @Schteevynn Great, these are very helpful use cases to hear!
Yeah, this makes total sense. We do have the ability to add a clearSelection script, but I'm not finding a way to make that conditional 
Sharing all of this with our team internally!
I guessing this wasn't initially implemented due to having to decide what to do with the empty space left by the action icon when it is hidden for one row but not the others? I seems like the actions are residing in sort of a column structure that is not seen and it would be hard to have some actions hidden and shift over in the column structure but not all of them.
+1
Hi there! The fix for dynamically showing/hiding toolbar items is set to ship to Cloud next Thursday
Hi,
Being able to do that in the toolbar help, but is there any update to have similar behavior for action buttons, or is this not being considered anymore ?
Hi there,
Making toolbar items dynamically shown has shipped. We have not yet shipped the option to reference currentSourceRow in the actions hidden property 
, but we're still tracking requests internally
The current recommendation is to use the disabled property instead of hiding as disabling the button promotes a consistent UI and predicable usage for end users
@Tess I thought the hide option was already dynamic? It just couldn't reference the currentSourceRow.
Hi Shawn, correct! We are tracking requests to reference currentSourceRow in the hidden property
1 Like
@Tess So, the option was already dynamic before right? What I'm getting at is, it seems dynamically showing actions is being reported as new and just shipped. But, at the time I created this thread, it was already possible to do it so I'm not sure exactly what feature was just shipped.
For this case mentioned earlier in the thread:
The other workaround I thought of has a similar gotcha – if adding a toolbar button to trigger clearSelection(), there is no way to dynamically show/hide the button depending on whether a row is actually selected or not. So both workarounds are less than optimal (suggestions welcome). Thank you!
This is now possible. You can now show/hide the toolbar buttons:
+1
1 Like
+1 from me, as well.
I applaud the design principle of predictability, and it's one of the things I enjoy about Retool as a piece of software.
Often just disabling an action for a table works well, but with more complex use cases it can make things less clear.
I'd love to have a reminder about good UX practices, but having my hands tied is just frustrating and feels condescending.
1 Like
Thanks for sharing this perspective! Sharing with the team internally 
+1