[1998] UI-TABLE only renders data when layout configuration is set to auto

[n-lark]

Description

When a ui-table was given a fixed size, the data table got clamped to a single grid row, hiding the header and all but one row. This was because the component had multiple root elements, so the grid-row-end style that makes a widget fill its configured height never applied to it.

Wrapped the table in a single root element and used a flex column so it now fills its configured height and scrolls internally, while auto sizing still grows to fit. Added a fixed-size table to the test fixture with a regression test.

Related Issue(s)

Resolves #1998

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
• Link to Changelog Entry PR, or note why one is not needed.

Labels

• Includes a DB migration? -> add the area:migration label

[Steve-Mcl]

My only pause is any custom styles added by users may now break with an additional div wrapper around the div->.v-table & wonder if new CSS proposed could be applied to the existing (multiple) parent wrapper divs?

If not, then fine, lets get this merged (will let you decide / merge)

[n-lark]

Hey @Steve-Mcl so I looked into alternate solutions for this and what I came up with was adding a tableGridStyle computed that works out the table's start row:

   tableGridStyle () {
            if (!this.props.height) {
                return {}
            }
            const startRow = 1 + (this.props.label ? 1 : 0) + (this.props.showSearch ? 1 : 0)
            return {
                'grid-row': `${startRow} / -1`,
                'min-height': 0
            }
        },

So what this does is count the optional header rows (label/search) and set an explicit grid-row on the table so it spans the widget's full fixed height instead of collapsing to one row. This doesn't change the HTML structure, but it does assume label/search are one row each which could break in future. I added Cypress tests to catch that.

I'm not sold that this is a better solution since it feels a little fragile to me, but if keeping the DOM structure identical is important then this is the way to go. What do you think?

[Steve-Mcl]

I'm not sold that this is a better solution since it feels a little fragile to me, but if keeping the DOM structure identical is important then this is the way to go. What do you think?

It is probably a very small percentage of people who apply custom styling then an even smaller subset who target the table with an ultra specific selector - so I would say the blast radius is small enough to go with the original solution. Thanks for taking the extra time to look into this and lets go back to your v1 solution.

[colinl]

@n-lark It would be worth checking this with the row height set to Compact in the theme if you have not already done that.

[n-lark]

Hi @Steve-Mcl thanks for the consult, I moved back to the original solution.

@colinl I did check all 3 row heights - thanks for the heads up!

Compact

Comfortable

Default