New table component missing features from legacy table

App Building
1

I'm actively building apps with the new table component and really like some of the advanced functionality and improved performance. However, at least 2 features that I happened to use in the legacy table component appear to be missing:

  • Ability to set row colour with a JS expression, e.g. {{currentRow.status === "Pending" ? "grey" : "green"}}

  • Option to have set the table height to automatic when paginated

I could use the legacy table, but I much prefer the new table overall.

It's entirely possible I haven't found them buried in the new editor UI which I'm still getting acquainted with - apologies if that's the case!

3 Likes
2

Hey @ryanm!

Thanks for bringing this up, you're not missing anything! Auto height is something that the dev team is still looking into for the new table and I can let you know here when there's an update on that.

As for setting row colours - would you mind expanding a bit more on what you're looking to communicate to the user with them? Could something like a status indicator column type or add-on work for your use case?

1 Like
3

Thanks @Kabirdas, I will sit tight for auto table heights!

As for row colour, that’s more a nice-to-have than a must-have. I don’t mind using the tag column type to display a status field - a bespoke column type sort of thing would be cool though, maybe with dynamic icons too? Just a thought :smile:

1 Like
4

I find that currentRow is not accessible in the new table component!

This is not just "nice to have", it's critical. :slight_smile:
Jeremy

5

Hey @jclutterbuck!

In the new table, you can try referencing currentSourceRow instead of currentRow:

Does that work?

As a side note, there are also docs for the new table component up here!

6

Dear @Kabirdas

Thanks for your reply. As usual, I should have given more detail.

I have a "tag" type dropdown as one of my fields in the table and I filter the options of the dropdown according to one of the values in the table for that row. Neither currentRow nor currentSourceRow seem to be available in the new version, unless I need to do it differently in the new version.

image
image1920×1080 199 KB

I found the docs useful, I read them twice, but they don't go quite deep enough, unless I've missed something.

Regards

Jeremy

1 Like
7

Also, is there a way to add a new row, like the old one, without having a separate form?

Jeremy

1 Like
8

The dev team is looking into reintroducing an updated toolbar to the new table! If you were able to open a modal with a separate form from a button on the table's toolbar would that work for adding a row?

As far as setting the option list for a tag component, it looks like for now, it's intentional to not have currentSourceRow be accessible in that field in order to keep the table highly performant. Would you mind expanding a bit on the details of your use case? I'm wondering if there might be a workaround or avenue that could be worth exploring.

1 Like
9

I like the idea of a modal to add a row rather than the inline way it was done before. If that could be a standard feature of the table component, well that would cover half of my of add row use cases (the other half would require a more customized experience and that is fine.)

10

@Kabirdas let me add my use cases while exploring retool, for both color & dynamic tags.

  1. column background color is useful to distinguish columns from others (e.g. grouping) i.e. highlighting the different sources or to help focus depending on the task. Conditional cell setting is even better to highlight outliers, exceptions,... Having an add'l column with tags for the same clutters the table even more, requiring more horizontal scrolling.

  2. dynamic tag values (dropdowns) is a must when valid options depend on the row context. There is no good alternative: opening a modal where options are pulled (from query) based on other columns would be ideal because, for our use case we would want to show an iframe (with dynamic url) too.
    Unfortunately it's not possible because there is no triggeredRow concept and the table doesn't allow to update a given cell value from other components or by JS. You can only replace the whole dataset (setData()) which btw will also reset the state (previous pending changes are reverted).

One comment on not exposing currentSourceRow for performance reasons. This would not be the case if the mapped query is run on-demand i.e. only if user edits the cell/tags. Why would the engine run the query for each row beforehand ?? They never will be used all-at-once. Just my 2 cents.

Is there a beta program for the new table ? If not, pls consider as this would save time and headaches on both sides, and is a good way to manage expectations and scope.

11

Dear @Kabirdas

Thanks for opening up this "discussion".

I think @yiga2 has the gist of it. I restrict the dropdowns to valid options depending on the value of another column for that same row.

E.g. first you choose the product in the first column, and then the colour, shape or size in the second column, depending on what was chosen on the first column.

For a new row, a modal would work, might even be better as there was some undesirable behaviours with the old one, but it did save a lot of work: not having to create a "subform".

Looking forward to further developments.

Jeremy

12

Would it also be possible to have a modal, e.g. to implement filtering? Or is this to be reintroduced?

Jeremy

13

@Kabirdas

A suggestion on how to have our performance cake and eat it too.

In JS queries you have the option to Keep variable references in sync. It is disabled by default to improve performance, but sometime the need outweighs the performance hit (never notice the performance hit however.)

Is the same thing for the table possible? And I am sure there are other features that have been sacrificed for the same reason.

14

There doesn't appear to be any way to reference currentRow (or similar) in a table action event handler either. Each row in my table contains a uuid which I want to pass to the action event handler that opens an app with the respective uuid as the hash parameter. This was easily accomplished in the legacy table.

15

Thanks for sharing those use cases here @yiga2!

It sounds like, for 1, people using your app need to be able to identify specific groups of rows, or outliers, quickly while staying within the context of the larger dataset - is that right? Is that so they can quickly switch between different groupings, or for comparison, or something else?

For 2, is it possible to use one of the selected row properties to identify the currently active row? There are actually quite a few that offer different portions of the data: selectedRow, selectedSourceRow, selectedRowKey, or selectedRowDataIndex but I know that people have requested click handlers to be separated from row selection in the past.

Thanks for adding your perspective here as well @jclutterbuck!

These are very valid use cases and they're definitely things for the dev team to consider. More support for filtering is also something coming soon. In the meantime, there's a post here from Alexi on a potential workaround you can use with the new table.

@bradlymathews that's certainly an interesting idea! I personally don't know how feasible it is but can see it being useful :thinking:

As for the currentRow issue @ryanm - the currentRow and currentSourceRow variables currently don't autocomplete in the "Go to app" handler of action buttons and might throw a linting error but they should still work. Can you let me know if that's not the case? This is something currently being tracked and will get looked into!

Again that you all for your feedback here, the folks working on the new table are also reading these posts. It's great to see so many people chiming in on this thread :grinning:

As a last note, I just want to clarify that the legacy table will be around for a while! The new table has been in various stages of beta before this release, and while it might not be a complete replacement yet, it functions really well as its own component. I know I'm personally very excited to have people start to use the new table because it offers a lot of options and improvements in certain cases. The dev team understands that it's really important to bring the new table into more feature parity with the legacy table before doing something like deprecating it, and in the meantime, hopefully folks will benefit a lot from being able to use both.

5 Likes
16

Thanks for keeping us posted @Kabirdas, I look forward to these fixes/improvements!

17

Thx @Kabirdas for the answer.
For 1, I am not so much concerned about row-coloring (nice to have, I use that for alternate-coloring like a ledger-style, gray, blank, gray, blank,... Very useful if table takes up most of the canvas). My comment was specifically for column-coloring, and cells (conditional).

For 2, selected-whatever only works for single select, not multiple. But Cell click event should tell the underlying value (self?). My comment was more about the inability to change another field on the same edited row, or "bring back" the value to set from a modal, without having to set (reset actually) the whole table source.
This is not unique to New table as legacy lacks that too so is out of scope of this discussion (while a big deal for us as setData for every change is very inefficient for large tables).

Eager to see future improvements though !

18

Adding allowing single-clicking to edit cells.
Legacy allows both single- and double-clicking to edit. New requires double-clicking with no other option. Quite annoying if lots to edit.

1 Like
19

Hi @Kabirdas,

Just chiming in on the discussion regarding column and cell colouring. I'm agreeing with @yiga2 that this is a great way to highlight any important information such as outliers in a table with a lot of data.

I understand that the Retool team is working towards feature parity with the old table, but can you give some insight if you're considering adding column and cell colouring to the new table?

Thanks for your time!

20

Hey @avr!

Coloring is being considered, the dev team is particularly interested if there are any other features they could include that would fit the same use cases in an attempt to prioritize features that enable more accessible design patterns. So, the more information they can hear about your use case the better! Especially, if you've considered other patterns, which of those might not be available in Retool, and why you're choosing color-coding in particular.

Also, thanks for surfacing the issue of having edits made through a separate component persist without being saved @yiga2. It's something that has come up a number of times before (one recent example) and the workarounds can be a bit tricky. Admittedly, though I've seen people ask for it, I'm not super familiar with all of the reasons why they are :sweat_smile: would you mind sharing a bit more about how it's useful for you?

For the issue with multi-select, the new table has unique properties for the collection of rows that have been selected as well as the most recently selected row. They are, respectively, selectedRows/selectedSourceRows (purple) and selectedRow/selectedSourceRow (orange):

Also, single-click to edit cells should be possible as long as single-cell selection is turned off.

2 Likes