It looks like you can go into each column and edit the label to be the same as your db, but I don't see a way to do this by default across all columns I'll request this feature internally
Thank you for looking into it, Tess. The problem is I can't work with the new table component if this questionable "feature" can't be disabled because it messes up our CSV import and export workflow. For now I will stick with the legacy table.
The latter, I'm referring to a column's mapped value.
Matthew's point is similar – the Label field seems to be automatically populated with a reformatted version of the Source field (in the screenshot, I did not remove those underscores nor change case). I pretty much always customize the label anyway, so it's not much of a change for me. But if you prefer the label to match the source, like Matthew does, you'd have to manually revert each label.
The Mapped value field now includes the {{_.startCase(item)}} by default for some column types, so you have to go and delete for those columns if you want the column to display the data "as is" from the data set.
Quite a few "whoa, why does that look so weird" moments before drilling down and removing the startCase reformatting.
I know this is an old thread, but...
+1
Automatically transforming the data that goes into the table by applying _.startCase to column labels or row data, and automatically choosing a column content format makes this component unusable for my team, which is unfortunate there are a lot of nice features to it that are not available with the Legacy table (like row grouping).
Adding another bump on this thread... @retool I just know you're going to want to deprecate the legacy table at some point and that is going to wipe out our app unless you fix this issue.
Thanks for the additional feedback! I have bumped this internally. I'm not sure what the outcome will be yet, but I'll follow up on this thread when I get an update.
For some background, the new table was designed to help build apps quickly by "just working" out of the box, with the option to customize if needed. While these automations can be removed from your table, I can certainly appreciate that it defeats the intention of speed of development if you're going in manually to remove the auto-formatting.
Looking towards a solution, is the main feedback that it is tedious to have to remove auto-formatting & manually change column types for each table?
That's correct. Tedious is one word for it. Unintended data transformation is the real problem.
For example, in my app I'm sometimes pulling in 30+ columns/fields from a MongoDB and off the exact fields I'm pulling change depending on the query. The user can edit in the table and then upload the changes back to the DB.
In the legacy table, this was no problem but with the new table as is, the auto-formatting essentially changes the data structure in my DB, which is obviously not desirable.
A simple auto-format on/off toggle on the new table component would solve the problem.
I'm back in the Retool environment and would like to make my request again because we're doing a lot of importing and exporting and the automatic column renaming is affecting our workflow.
If this is not in the immediate future, please provide a workaround. Thank you.
Thanks for checking in! Our team hasn't been able to prioritize a fix yet, so I don't have an eta . The only workarounds I'm aware of, besides manually editing each column, are to continue using the deprecated table or to use dynamic column settings. Both of these workarounds have limitations, so shipping a fix is still on the roadmap
+1 for this being added as a feature. It's very frustrating to create a table with 20-30 columns that have specific names, just to go back in and have to manually update every single column name.
For this use case, the legacy table "just works" much better than the new one, because it does exactly what I expect it to do (i.e. show the exact results of a query in a table).