Turn off Automatic Column Updating in Table component

💬 App Building
1

  1. My goal: change my backend data without destroying my work on front-end table components

  2. Issue: whenever I update the queries feeding tables, the tables themselves update to add new columns that weren't present. This requires me to either catch the "Undo" toast before it disappears (and even then, it's 50/50 whether it'll remove all the new table columns), or I have to manually delete all the new columns every time I update the JS query. It's incredibly tedious and I don't understand why Retool would overwrite hours of manual work with unwanted automations that create more problems than they solve.

  3. Steps I've taken to troubleshoot: Create a table fed by a JS query. Create some custom columns. Add fields to the JS query and save. Watch a bunch of new columns appear on the table unwanted.

  4. Additional info: (Cloud or Self-hosted, Screenshots): Cloud.

3

Hey Jeric,

It's not a perfect solution, but it sounds like _.pick() might help here? In the table's data source field, you can use _.pick(data_source.data, ['desired_column_1', 'desired_column_2']). That will make it so that adding new fields to the JS query doesn't impact the table

1 Like
4

Hi @jericsinger,

It sounds like you may want to try separating the logic for queries and table components between a development environment and a production environment.

This way, you can test out changes on the development set up, to ensure that you have the data and columns set up the way you want before you update the main 'staging' table so that you can maintain an end product in staging that is consistent with that you expect and want.

The table component updates every time the data being returned by its 'source' is changed automatically. As it is expecting users to want to see any newly added backend data. It will parse out the data coming from the source and create rows and columns out of this data.

Being able to create custom columns in the frontend, then change the data source and have the table both construct rows/columns with the source's new data AND maintain any custom built columns and their logic is outside the table components current capabilities.

Just to clarify, on your steps, you mentioned that you "Add fields to the JS query", by fields are you referring to data that is being turned into table rows? And when you say "watch a bunch of new columns appear" are these columns the new fields that you added?

If not, let me know as I may have misunderstood the steps taking place and the desired outcome of changing the data source JS query and the custom columns in the table :sweat_smile:

5

So, let me give a pseudo-example. Let’s say I’m starting with a JS query that spits out an array of objects like so:

[ 
  { name: 'Michael Bluth', age: 40 },
  { name: 'George Michael Bluth', age: 16 },
  { name: 'G.O.B. Bluth', age: 42 }
]

Then I build a table with columns for name and age, and everything’s great. But what if in the future I decide to add a caption to the name column? So I “add fields to the JS query”:

[ 
  { name: 'Michael Bluth', age: 40, name_caption: 'Jason Bateman' },
  { name: 'George Michael Bluth', age: 16, name_caption: 'Michael Cera' },
  { name: 'G.O.B. Bluth', age: 42, name_caption: 'Will Arnett' }
]

Aaaaaaand, boom, “[one] new column appears” in the table. And if I happen to be adding tooltips, captions, and colors to multiple columns in a table, the whole table will automatically add the columns and mutate the table in ways that are not reliably undoable (when I click undo on the toast notification about the column update, it’s even money that the undo will include all, some, or none of the changes. Extremely scary.

To avoid the unwanted updates, I’ve started formatting my data in a nested structure:

[ 
  { 
    name: {
     value: 'Michael Bluth', 
     caption: 'Jason Bateman',
     tooltip: 'Who?',
     color: '#242424'
  },
  { 
    age: {
     value: 'George Michael Bluth', 
     caption: 'Michael Cera',
     tooltip: 'You remember Ann?',
     color: '#000000'
    },
  },
  ...
]

This works better, insofar as I can add information and formatting to data columns without triggering automatic updates, but it’s not without its usability issues. To start, there’s no way to set a column’s “item” reference to the object. In order to display the ‘value’, I have to set the column value to {{ item.value }}. And then when I go to set the column caption, I can’t set it to {{ item.caption }}, but rather have to reference it as {{ currentSourceRow.name.caption }}. From my perspective, there’s a missing ‘column’ property that exists between ‘self’ and ‘item’ that could make data enrichment (captions, tooltips, sortValue, targetUrl, fontColor, fontWeight, etc.) much simpler to implement.

I guess my question then is, when you say the table “will parse out the data coming from the source and create rows and columns out of the data”, does that mean that I should separate my non-value data (again: tooltips, captions, etc.) into a a different JS query than my value data (e.g., name, age)? Or is there a third way I’m missing?

6

Hi @jericsinger,

Thank you for the explanation! I also love the arrested development reference :banana: :ice_cream:

Yes I agree, if you are actively working on changing the data payload inside a JS query that is the data source for a table, the table will jump to do what it thinks you want(creating the new column to map over the newly added data that it finds in it's source, when in reality you are just trying to save non-value data) and this could be better controlled by a toggle option to not have the table automatically run 'regenerate columns' on source data differences being detected.

I can definitely make a feature request for this, but I feel that this may not be highly prioritized by the UI team given that changing the schema(since the table thinks the non-value data is actually table schema for columns/rows) of a table data frequently is intrinsically going to be a tricky use case to support. But it doesn't hurt to try.

To answer your last question, yes that is exactly what I am getting at, if we can find a way to divide things up between your non-value data (tooltips, captions, etc.) verses the value data (columns) then we could get a viable workaround to fit your use case :raising_hands:

I actually just had another user make a feature request for having a JSON schema for styling/tooltips/captions, etc. and feel that this request is somewhat getting at the same root desire.

This would allow for a table's data source to be rows and columns from a DB table and all the non-value data as you mentioned to be another selectable source that can be altered separately and even shared across tables.