Retool New Table Component Missing Features (And How to Fix Them)

If you've started building with Retool's new table component and noticed that several features from the legacy table are missing or behave differently, you're not alone. The new table component brings real improvements — better performance, a cleaner editor UI, and more advanced column types — but it also dropped or changed a handful of features that many builders relied on daily. This guide covers every confirmed missing feature, what the Retool team has said about each one, and the best workaround you can use right now.

1. Row Background Color via JavaScript Expression

In the legacy table, you could set row background color with a simple JS expression directly on the row styling property — something like {{currentRow.status === "Pending" ? "grey" : "green"}}. This was a fast, visual way to communicate status at a glance without adding extra columns.

In the new table component, this option is not available. The Retool team has acknowledged the gap. In the meantime, the closest alternatives are:

• Use a Tag column type to display a colored status badge in a dedicated column. You can map tag colors dynamically to values in your dataset.
• Use a status indicator add-on column to surface a colored dot or icon next to a row value.
• If you need true row-level highlighting, consider adding a calculated column that returns an icon or emoji as a visual proxy while waiting for native support.

None of these are a perfect substitute for full row coloring, but the Tag column type handles the majority of status-signaling use cases without cluttering the table with extra horizontal scroll.

2. Auto Height When Pagination Is Enabled

The legacy table had an option to set table height to automatic even when pagination was turned on — meaning the table would shrink or grow to fit its current page of rows. In the new table component, this setting is missing.

The Retool development team has confirmed they are actively investigating auto height support for the new table. There is no ETA, but it is on the roadmap. For now, the workaround is to set a fixed pixel height or use a container with overflow handling to approximate the behavior. If auto height is critical to your layout, the legacy table remains an option until this is resolved.

3. currentRow Is Not Accessible — Use currentSourceRow Instead

This one trips up almost everyone migrating from the legacy table. In the new table component, currentRow is no longer the correct reference. The replacement is currentSourceRow.

Here's what changed and where each reference works:

• currentRow — legacy table only. Will not resolve in the new table component.
• currentSourceRow — new table component. Use this anywhere you previously used currentRow in column value expressions, conditional formatting, or button actions.

However, there is an important caveat: currentSourceRow is intentionally not available inside Tag column type option lists. The Retool team has stated this is a deliberate performance decision — exposing row context inside dynamic dropdowns would require running a mapped query per row, which is expensive at scale. If your use case requires filtering tag options based on another column's value in the same row, the current recommended path is to open a modal with a form, pull the dynamic options in that modal via a query triggered by the selected row, and write the result back to the table using setData().

Note that setData() replaces the entire dataset and will reset any pending unsaved changes — plan your state management accordingly.

4. No Inline Row Add (Toolbar Missing)

The legacy table had a built-in toolbar with an Add Row button that let users insert a new row inline without leaving the table. The new table component shipped without this toolbar entirely.

The Retool team has confirmed the toolbar is being reintroduced in an updated form. The proposed model is a toolbar button that opens a modal containing a separate form for row creation, rather than inline editing. For most CRUD use cases, this is actually a cleaner UX pattern — it gives you full control over the form layout, validation, and the queries that run on submit. Here's how to replicate it today:

• Add a Button component above or inside your table layout and label it "Add Row."
• Configure the button's click event to open a Modal component.
• Inside the modal, build a Form component with the fields you need.
• On form submit, run your insert query and then trigger a refresh of your table's data source query to reflect the new row.

This pattern also scales well — you can reuse the same modal for editing existing rows by pre-populating form fields with table1.selectedRow.data.

5. Dynamic Tag Dropdowns Dependent on Row Context

If you need a Tag or Select column whose options change based on another cell in the same row — for example, filtering a category dropdown based on a department column — you'll hit the currentSourceRow limitation described above. The cleanest workaround right now is:

• Make the table row selectable and use table1.selectedRow.data to pass row context into a modal.
• Inside the modal, run a query that fetches the valid options based on that row's values.
• Let the user make their selection and write back using setData() or a direct database update query.

Should You Migrate to the New Table Component Now?

The new table component is the clear long-term path — better performance, more column types, and active development. But if your app depends heavily on row background colors, dynamic per-row dropdown options, or auto height, you may want to stay on the legacy table for those specific use cases until the gaps close. For everything else, migrating now and adopting the modal-based patterns above will set you up well for where Retool is heading.

Keep an eye on the original community thread for updates directly from the Retool team as these features are reintroduced.