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.
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.
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.
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).
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.
"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.
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:
enabled: boolean, // Enables filtering.
text: string, // The filtering text, can be both read from and written to
enabled: boolean, // Enables filter results to be written back to props, doing so my cause performance decline
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.
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.
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.
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?
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
I’m trying to implement something along these lines to highlight a row if a value is true in that row, but I’m not sure how to configure this since the data is being pulled from a named query, so it removes any style properties I’ve added when it re-polls.