New best practice for using Mapped mode in new Options List

Community Show & Tell
1

This was not pointed out in the docs on the new Options List, but is the most powerful capability of the new feature as far as I am concerned.

Here is a use case of mine. I have a dropdown for selecting which invoice to work on. I now need to find a way to remember that invoice's row data to use in the app. Here are all of the ways I have tried to do this in various apps:

  • Set the InvoiceId in a temp var from the click event. Then run a query on the invoices table to just get that one record. I can then refer to that query everywhere in the app like this: qryInvoices.data.invoiceDate[0]. (Don't forget the [0]).

  • A shortcut to the above is to just use mySelect.value in the query.

  • Get the selected row column values by referring to the mySelect.selectedIndex as in: qryInvoices.data.invoiceDate[mySelect.selectedIndex]

  • Similar to the above you can use the mySelect.value as in: qryInvoices.data.invoiceDate.find(e => e.Invoice_Id === mySelect.value)

  • A variation on the previous 2 is to store the row in a temp var from the Select's Click event: currentInvoiceRow.setValue(qryInvoices.data.invoiceDate[mySelect.selectedIndex]). Then you can read the row with currentInvoiceRow.value.invoiceDate.

I believe there is a new best practice for this which deprecates all of the above methods. You can use the query.data as the source for components that use the Mapped mode of the new Options List feature, like the Select.

  1. Set the Data Source to your query
  2. Set your Value and Label as appropriate (e.g. {{ item.invoice_Id }} and {{item.customer_name}})
  3. Now you can easily get to all of the columns in the selected row like so: mySelect.selectedItem.invoiceDate.

No more extra wiring is needed.

2 Likes
2

Works for tables but trying to make this work for a ListView field seems to be an issue. I’ve been trying to work through an existing issue whereby I’m setting temp var values per field in each instance of that field but the function of setting that val on a change event is inconsistent. Wondering if you have any thoughts. Still working with support on it btw

3

Yeah, I forgot the mention that this new technique works very much like using table.selectedRow.

On your issue, I don't think I have enough context to be of much help. But a basic truth I have evolved is that you only need to use temp vars as a workaround for missing functionality in Retool components. And most (certainly not all yet) of the that missing functionality has been addressed, this newest update with Options Lists being a big one for me.

And as I revisit older apps, refactoring them for new Retool functionality (and let's be honest, more experience), I find that many temp vars start to become unneeded.

So now, if I find myself leaning on temp vars on new apps, I will assume there is a better way and re-work my flows, architecture, whatever and will often find a more straightforward path.

1 Like