I'm very surprised by the deprecating dropdown (table) column type.
There are three types of columns mostly used in tables: 1) primary key 2) foreign key 3) attribute.
For columns 1) and 3) you have a great solution, but for type 2) (FK) is crucial to use a dropdown list (DDLS).
DDLS in the row-edit allows straightforward user interaction and enhances the referential integrity and hence a high data quality.
Please mind that only simple web applications use only several unreferenced tables. Whenever we are speaking about the data-driven application, our goal is to ensure data quality which is achieved by core database feature like a foreign key.
One of the main reasons why I started working with Retool is that this tool presented the ability to design fast data-driven applications. However, with the missing dropdown list in the table-row, Retool is, unfortunately, losing its cutting edge.
I definitely agree that the tag column is necessary for many use cases. Hopefully, in most cases, the tag column can continue to be used as expected, since it is not deprecated for any columns that are populated by the table's data source.
For any cases where custom columns are preferred, I hope that Kabirdas' suggestion can be a very comparable solution for the time being to still use the tag column type.
It's very helpful to hear how you are interacting with the table component, as we are working on a ton of exciting table improvements this year!
If you have any additional table feedback or if you would like to discuss implementing a workaround for your table, please let me know!
Hi @Tess, thank you for your response. I'm happy to hear that the Retool team is improving the table component.
I see that you are discussing the tag column. For me, "tag" is the workaround, as there is no dropdown list column in the table. There is just "Tag (dropdown)"
Anyway, the challenging issue persists even with tags. Have a look at the below example app. Table show IDs instead user-friendly values. These user-friendly values are available only when the user edits the column.
This is the current expected behavior because the owner column dropdown shows emails from their corresponding ids in string format, but the owner_id column is an integer column. In the exported app, the option for Allow custom values is toggled ON, so even though the integers 5, 1, 2, etc from your screenshot are not a match for any of the dropdown ids, they still show in the table as custom values.
If you toggle off Allow custom values, and add a transformer to the deals query that converts the owner_id from an integer to a string column, you'll see the emails show up in the table (matching the deals owner_id to a user email):
Deals R transformer:
data.owner_id = data.owner_id.map(x=>x.toString())
return data
To clarify, we use the terms "tag" & "dropdown" interchangeably when discussing the table columns. Is there a feature missing from the current "Tag (dropdown)" (other than being able to use it in custom columns)? If so, I can submit a feature request. I just want to make sure I understand the use case first!
Hi Tess, thank you. For me, the experience of many years with data applications, DorpDownList is a crucial part of row-data-edit. This is because it handles the core DB feature - Foreign Keys. In retool Rag/dropdownlist seems that dropdownlist is like the orphan's column type in the table. There are many mentions of decommissioning tag column type, so it's also a risk for the dropdownlist.
The result is that Retool pushes developers not to use foreign keys (FK) and rather just use values, not FKs, leading to significantly lower data quality.
If you ask about the feature, a dropdownlist with all perks allowing edit-in-table-row would be an amazing step forward.
