Introduction

We all love Retool for its speed and simplicity when table data visualization is needed. Just create a query to fetch the required information, select it in the code editor - and drag a new Table component onto the canvas. Voila! Now you have all the data you need, properly formatted and presented to a user.

But what if an application is expected to handle different datasets? Well, you can add several tables, hiding and displaying them conditionally. This approach works if you have a limited number of datasets to display, and if the data is well-structured. Or, at least, its structure doesn’t change with the weather (this is a dad joke we’ve all been waiting for).

A more complex but suitable approach could be the so-called Dynamic Columns in a Table.

Limitations

To be short, Retool dynamic column settings allow you to reconfigure table columns on the fly. When you want to customize columns by changing their labels, value formats, etc., Dynamic Column Settings is the feature that enables you to do so. This works because you can hide columns and change other attributes in addition to mapping new values for column labels and formats. For instance, when the schema of the data source changes it becomes necessary to have these settings.

This feature exists both in the old (legacy) Tables and in the new Table component. This is an important note: implementations differ a lot, so be aware that this guide is focused on the new Table component.

Another important limitation is that Dynamic Columns enabled cuts off deep customization features, like tooltips, and advanced formatting settings. Also, the primary key column couldn’t be a column from the dynamic list. If you are okay with these limitations, let’s go ahead and build an app!

Data to Work With

If you like, you can continue reading while exploring our demo app, which is available here.

To demonstrate Dynamic Columns, we prepared three different data structures.

Step 1.

- All the data passed to a table need to be precooked prepared and should look like an array of uniformed objects.

The first one might look familiar to you - it’s based on the Retool demo data displayed in tables by default, it simulates an employee list:

 {
   "id": 0,
   "firstName": "Chic",
   "lastName": "Footitt",
   "email": "[email protected]",
   "role": "Viewer",
   "enabled": true  
 }

The second one might be borrowed from a travel information system, but maybe not:

 {
   "id": 101,
   "destination": "Paris",
   "departureDate": "2024-09-15",
   "returnDate": "2024-09-22",
   "flightNumber": "AF1234",
   "status": "Confirmed",
   "notes": "Direct flight. Business class."
 }

And finally, the last one mocks up data from a car service:

 {
    "repairId": 201,
    "vehicleId": "VIN1234567890",
    "ownerName": "John Doe",
    "serviceDate": "2024-07-10",
    "repairType": "Oil Change",
    "cost": 75.00,
    "status": "Completed",
    "notes": "Used synthetic oil."
 }

‍

‍Step 2.

- You can format data using a JavaScript query and then store it in a state variable, or you can format it using a transformer. The idea is to point the table to the one place to get data.

Dynamic Settings

Okay, now we have three data sets with literally nothing in common. How do we handle this? In addition to the data itself, we will prepare different configurations explaining to the table how to handle the data. Each configuration will be an object, where each first-level field represents a key in a dataset, and its child nodes have all the needed data to configure the table.

So, for the employee list, we will have something like this:

 {
   "id": {"name": "Internal ID", "type": "auto", "editable": false},
   "firstName": {"name": "First Name", "type": "string", "editable": false},
   "lastName": {"name": "Last Name", "type": "string", "editable": false},
   "email": {"name": "Email", "type": "link", "editable": false},
   "role": {"name": "Role", "type": "tag", "editable": false},
   "enabled": {"name": "Is Working?", "type": "boolean", "editable": false},
 }

By the way, internal fields like ‘name’, ‘type’, etc. can be named the way you like - it doesn’t matter.

Let’s take a look at the config of the booking dataset. Note that some keys are marked here as editable - yes, dynamic tables support inline editing!

 {
   "id": {"name": "Booking", "type": "auto", "editable": false},
   "destination": {"name": "Destination", "type": "string", "editable": true},
   "departureDate": {"name": "Outbound Flight", "type": "date", "editable": false},
   "returnDate": {"name": "Inbound Flight", "type": "date", "editable": true},
   "flightNumber": {"name": "Flight", "type": "link", "editable": true},
   "status": {"name": "Status", "type": "tag", "editable": false},
   "notes": {"name": "Notes", "type": "string", "editable": true},
 }

And here is the last configuration, of the car repair data. Nothing is new here, but we will try to do some tricks in the table itself:

 {
   "repairId": {"name": "Order Number", "type": "auto", "editable": false},
   "vehicleId": {"name": "Vehicle", "type": "string", "editable": true},
   "ownerName": {"name": "Owner", "type": "avatar", "editable": false},
   "serviceDate": {"name": "Date", "type": "date", "editable": true},
   "repairType": {"name": "Repair", "type": "tag", "editable": true},
   "cost": {"name": "Cost", "type": "currency", "editable": true},
   "status": {"name": "Status", "type": "tag", "editable": true},
   "notes": {"name": "Notes", "type": "string", "editable": true},
 }

Table Configuration

In the demo app, I decided to store the data to display in the tableData variable, while the corresponding configuration is put to the tableConfig variable. When you click on a button on the navigation bar, the values in those variables are replaced with the values from the selected JSON.

So, if you want to have a fully dynamic table, go and clear all the columns!

Step 3.

- Select the tableData variable as a data source, and then, to make the table programmatically configurable, it shouldn’t have any saved columns, let’s clean them.

Now we are going to attach dynamic data to the table. The secret button is hidden in the additional menu in the Content part, which is located on the right side of the screen.

Step 4.

- Open the Advanced menu, and check the ‘Use dynamic column settings’ option.

If everything is okay, you will be able to see the table populated with the data you have. However, it won’t display column names, etc.

Now, let’s attach the configuration to the table. To understand, which key is being used at the moment, we can refer to an ‘item’ alias. It returns the current column key that table is rendering. So, let’s get the correct labels, formats, and edit attributes set.

Step 5.

- Refer to the configuration variable using the ‘item’ alias in the fields needed, don’t forget to click on a small FX button, if you want to control the format settings programmatically, too (enabled in our example).

On the lowest part of the Advanced panel, you can see a Column Properties section. It allows you to configure type-specific parameters. For example, for currency I specified the currency code ‘USD’, so when a currency column appears on the table, it is formatted as US Dollars.

The ‘tag’ example is more interesting, in my opinion. For demo purposes, we add an icon to all the tags that are displayed in the table, if the data comes from the third, ‘car service’, dataset.

Of course, you can invent another logic here - and make the table display different icons at all.

Step 6.

- Configure type-specific options, like special currency formats, icons, colors, and so on.

The End

If you have followed this guide, you should be able to see a working dynamic table. And we are happy for you! To say, our team struggled a lot when we faced a need to use dynamic tables. We hope that this exploration will be a way easier for you thanks to this article. If you have any additional questions, please feel free to reach me - or any other Akveo Team member. And good luck!