[Feedback] NEW Perspective Table

Selection data now includes data of columns added by additional column configs.

Do you have an example on how to use the data attribute under the selection?

Hello,

Here are some of the latest features, updates and fixes to the table component.

  • Rows of the table component are now virtualized, meaning based upon the scroll position and height of the table, only the rows needed are rendered. This equates to being able to render thousands of rows in fractions of a second. Overall, a massive performance boost from the previous iteration. NOTE: There is a minor downside that comes from this virtualization. Columns that are set to render as view cells require that min row height be specified if the height of the configured view is greater than the default height of the rows. This is due to the fact that views have not completed their initialization lifecycle when pre-measuring row dimensions. This downside is a small price to pay for the performance gained from virtualization. Within the next few months, there will be an option to switch between virtualization and standard mode, so that you may choose which mode best suits your needs.

  • Cell editing is now full functional. There is a custom component event on the table called ‘onEditCellCommit’ which fires after changes are committed (‘Enter’ or ‘Return’ key press) to an editing cell. The event object has the shape: { column: string | number, row: number, value: any }. Please let us know what else you’d like to see included in the event object.

  • More intelligent column auto render modes. If the data happens to be a dataset, the render mode is derived from the dataset’s types.

  • New string render mode for column configs. Effectively just wraps the data in a string.

  • Various bug fixes including, applying specified formatting to valid dates, pager updating when the length of the data property changes, boolean auto render detection, and more.

1 Like

Is there going to be a way to access the filter value? I have two tables where I want to click one table to temporary filter the values in the second table. Outside of manipulating the dataset in the background I was looking to take some of the selected value data from table 1 to populate the filter in table 2. I’ve looked through available properties but don’t see a way to do that. Is this something that will be exposed in the property set for the table?

We can definitely look into exposing the filter property, but filtering the dataset using a binding + transform should also be an easy way to get it done.

1 Like

Is it possible for someone to provide an example of how to pass parameters to a subview?

You don’t expressly pass parameters to the subview - they’re sent implicitly by the Table. If you have a Table with columns “city”, “country”, and “population”, then your subview should have the following parameters configured:
22%20PM
The Table will pass along a rowIndex parameter, which is the row of the table this subView belongs to, and a value parameter which contains a case-sensitive matching key for each column of the Table.

5 Likes

So awesome. Thank you!

1 Like

Will it/could it be possible to define custom parameters as well as the row data?
Maybe adding a params object like you would for an embedded view component?

Sort of.
Long-term, we’d have to implement something like that as a feature.
Short-term, you could always include the parameter as part of the Table data, and just configure the column which holds this custom parameter to not display.

4 Likes

Is there a way to dynamically highlight specific rows based on a column value in that row?
I see that if the data is an array of objects, I can assign styles:

But in my case I am populating the table with a dataset by binding it to a query.

Is this something that I can do? Or will the feature possibly be introduced in the future?

You could create a transform for the binding which creates the array of objects from your Dataset, and apply the logic there.

I don’t suppose that once I apply the logic I can somehow convert back to a dataset to store in the table? In other words is there a way for a dataset to store complex data types that would contain style information?

The issue I have with storing the data as an array of objects is that I am accessing these tables in multiple scripts that would all need to be changed in order to use arrays of objects instead of datasets.

Hi,

The next iteration of the table component (hopefully to be available in the next couple of weeks) will allow you to configure options on individual rows. These options will include the style property, subview property, and a few others. It will have a structure similar to custom options on a cell. This will allow designers to specify options that override those inherited from the rows config.

-Yousuf

Oh that sounds awesome! Thanks!

1 Like

Hello,

Thank you for your patience while we work to improve the table component. Here’s an update on features and fixes that are available in the latest nightly, or 8.0.2.

Fixes:

  • The table header’s z-order is no longer greater than other components, so it no longer always shows as being on top of other components if the table happens to be overlayed with other components.

  • View cells (cell belonging to a column configured to render as a view) should receive row data (rowData) as a view parameter. We added this feature a while ago, yet some reported that it wasn’t working as it should. That should no longer be the case.

  • You should now be able to configure the subview of a row to be a table that may grow as further nested table subviews are expanded revealing more tables. This can be done by allowing tables in subviews to be configured as non-virtualized via the virtualized prop and configuring them as a child of a root flex container, with both the child (flexGrow: 1) and the flex container configured to grow (set a style property on the root flex container to flex: 1 0 auto). I would suggest also setting a left margin on the nested table components to approximately 30px to give it that neatly stepped look.

  • Columns configured to render as checkbox’s no longer always renders as true, instead of the actual value.

  • A column of boolean values will render as checkboxes when render mode is configured to auto.

  • Filtering should no longer break if certain special characters are typed out

  • Filtering should no longer breaks when data contains null values

  • When virtualized, expanded subviews that are scrolled out of view will remain open when scrolled back into view.

  • The rows of the table should now grow and expand along with the client assuming that they have not been given fixed widths (note: we have a feature request for column percent widths which is in the works).

Features:

  • Editable cells that are not configured as boolean or views, are rendered as a text area when editing, which provides the user with the ability to add new lines via Alt + Return keys.

  • Added justify prop to column configs which will justify the content of the cell horizontally.

  • The column configs align prop now handles vertical cell content alignment.

  • Custom cell configurations can now include the align and justify properties to position the cell content in a way that overrides rules inherited from the associated column configuration.

"city": {
  "value": "Folsom",
  "editable": true,
  "style": {
    "backgroundColor": "ignition-orange",
    "classes": "some-class"
  },
  "align": "top" // Also accepts center and bottom
  "justify": "left" // Also accepts center and right
}
  • If an actively edited cell is determined to be no longer editable, the actively edited cell is set to reflect the fact that it’s no longer editable, without any commits.

  • Copying values from selection, when only one cell is selected, will copy only that cells value and not it’s JSON representation.

  • Column configs can now specify view additional view params to provide view cells via the viewParams prop.

  • Rows can be configured to override the subview configuration of the rows config, specifying their own view path and view params. This means that you may have some rows that render subviews and some that don’t.

    { 
        "value": {   // The rows value. 
            "city": "Folsom" 
            "country": "United States", 
            "population": 1000000 
        }, 
        "subview": {  // Row subview configuration. Can override configuration from rows config.
            "enabled": true, 
            "viewPath": "myView", 
            "viewParams": { 
                "param1": 3 
            } 
        } 
    } 
  • Rows can now be configured with their own styles.
    { 
        "value": {   // The rows value. 
            "city": "Folsom" 
            "country": "United States", 
            "population": 1000000 
        }, 
        "style": {  // Custom row styles.
            "backgroundColor": "#F7901D",
            "classes": "some-class"
        }
    } 
  • The table header, footer, header groups, and footer groups can all be toggled individually. It’s no longer required for the header or footer to be present in order to render the header and footer groups.

  • The prop enableFiltering is now an object called filter where it can be toggled and where filter text and filter results can be written. The schema looks like this:

filter: {
        enabled: boolean, // Enables filtering.
        text: string, // The filtering text, can be both read from and written to
        results: {
                enabled: boolean, // Enables filter results to be written back to props, doing so my cause performance decline
                data: Array<PlainObjects>
            }
        }
    }
}
  • justify and align are also available for header, footer, header group, and footer group configurations.

  • The pager has been properly redesign to a more professional standard.

  • Selection data and filtering data does not include custom cell and row configurations as the have been configured, but instead the values only.

  • Designers can now toggle between a virtualized table body and a non-virtualized table body via the virtualized prop. To be virtualized means that the number of rows rendered are determined by the dimensions of the table body, and a few overscan rows above and below the visible rows. This way you get only the rows that you need, when you need them. Non-virtualized means that all of the rows will render all at once, which can cause loading performance decline if thousands of rows are rendered, and therefore the number of rows rendered are not determined by the dimensions of the table body.

We hope you find these fixes and features useful. If you have any questions about anything, please let us know and we’d be happy to provide answers.

-Yousuf

3 Likes

Is there a way to hide, say, an id column, that is needed for scripting so that it would still display a value in the selected array, but it wouldn’t have to be visible on the table?

Add a new entry in props.columns so that you have as many columns as you have data columns you want represented, and then set props.columns[x].field to the column name you want represented in that column. Any data columns omitted will not be displayed.

Hi,

No, not at the moment, but that should be available very soon.

-Yousuf

1 Like

Can I change the color of header of table? I couldn’t find the way.