[Feedback] NEW Perspective Table

Ignition Early Access
21

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
22

So awesome. Thank you!

1 Like
23

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?

24

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
25

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?

26

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

27

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.

28

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

29

Oh that sounds awesome! Thanks!

1 Like
30

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
32

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?

33

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.

34

Hi,

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

-Yousuf

1 Like
35

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

36

Hi,

The only way to do this currently is if you establish a column configuration for your desired column, then you’ll be able to style the header cell via the header prop. We have plans to expose more styles on the table including the head, foot, body, pagers, filter, etc. in the near future.

-Yousuf

37

Is there a way to trigger the ‘onDoubleClick’ event by double clicking on a row/cell anymore? It use to be possible but now I can only trigger that event by double clicking the header of the table

38

Hi,

I understand. The reason this is no longer possible is a side effect of preventing unwanted behavior from nested tables in subviews. What is it you are trying to accomplish? Perhaps a more targeted custom component event would be a better option?

-Yousuf

39

I have information displayed in the table, each row representing some abstract object. Double clicking on a row opens a popup to edit that object.
In similar use cases we have an ‘edit’ button beside the table that opens a popup to edit the object/row that is selected in the table, but double clicking the row feels a lot more intuitive