Setting column width in a table

[yvedb]

Is there a way to set the column width of a Table (e.g. as a % of the table width) in Forge without using Custom UI?
I would assume that to be basic functionality.

[AdamMoore]

Not at the moment, but we’re working on a client-side version of UI Kit that will have much more flexible styling and layout. You can follow this card on the roadmap.

If you need a solution immediately them Custom UI is the best option.

[ddraper]

Hey Yve,

I’m keen to understand more about your use cases for Table … is setting the overall width the only thing you’re looking to achieve or are you looking for more fine grained control of individual column widths. Are there any other limitations that you’ve found that you’re looking to resolve?

Many thanks,
Dave

[hopel]

Hi @ddraper - not the original poster here, but related use case, I think, so chiming in:
Our first and most important ask to make UI Kit tables somewhat usable would be the same as what I understood @yvedb to have asked, i.e. an option to set individual column width indeed (not sure what you mean by ‘overall width’).

[ddraper]

Hey Henrik,

My apologies, I misread the question and misinterpreted as wanting to set the overall width of the table - not that of an individual column. I agree that setting individual column widths is an essential requirement for a table component.

Would you preference for tables to have a compositional approach using multiple components for the table, rows, cells, etc (similar to HTML) or a more programmatic / props with a single table component that you configure?

Are table requirements quite simplistic or is there a need for pagination support, dynamic column / row reordering / resizing, etc.

These are the sorts of other behaviours that I was interesting in seeing if there was a need for,

Regards,
Dave

[hopel]

@ddraper

Would you preference for tables to have a compositional approach using multiple components for the table, rows, cells, etc (similar to HTML) or a more programmatic / props with a single table component that you configure?

That is hard to judge, as it highly depends on use case and offered options - a single component with respective props sounds tempting, but I guess the required props data structure would get unwieldy pretty fast, if you start to offer more advanced features to control the behavior/layout. So sticking to multiple components might fit better with the ‘just one use case at a time’ implementation approach currently favored by Atlassian?

@ddraper

Are table requirements quite simplistic or is there a need for pagination support, dynamic column / row reordering / resizing, etc.

We’d certainly make good use of such ‘advanced’ features once they get available - the current, implicit pagination logic is somewhat ok(isch) for lower single digit page numbers, but not sufficient for larger ones, especially in the absence of sorting. If I would be forced to put an ad hoc order on the importance from my current use cases, I’d go width:

1. Column width settable
2. Sorting by column (i.e. classic ‘user clicks column header’ to trigger a reordering by that column, second click reverses the order)
3. Improved pagination support (e.g. allow for dynamic/staggered retrieval of large datasets)

[ddraper]

Thanks for the feedback @hopel !

As a developer my preference would be composition (with pre-composed components made available) but it’s always important for us to check what our partners and developers in the Ecosystem would prefer.

I agree that is it hard to judge (which is why I’m keen to gather a broad a range of feedback as possible).

My experience of tables is that there can be an incredibly wide-array of use cases. An interesting example here is your use cases for both column sort and pagination.

Would your expectation here be for column sort to resort the existing page in memory, or trigger a call to refetch the table data based on the new order? With some prototyping I’ve done for our libraries I think a composable solution can work here because we could provide both InMemory and AsynchronousPaginated flavours of a table that are composed from the same underlying components.

It’s definitely an interesting problem to solve in such a way that it satisfies the broad range of experience and use cases that we have in the ecosystem!

[yvedb]

@hopel

• Column width settable
• Sorting by column (i.e. classic ‘user clicks column header’ to trigger a reordering by that column, second click reverses the order)
• Improved pagination support (e.g. allow for dynamic/staggered retrieval of large datasets)

I concur.

[hopel]

@ddraper

Would your expectation here be for column sort to resort the existing page in memory, or trigger a call to refetch the table data based on the new order?

Ideally, I’d expect two options, configurable depending on use case:

1. For small(ish) datasets, passed in one go without dynamic retrieval of further pages (i.e. ones that work with the implicit pagination we currently have), I’d expect a resort of the existing table in memory, i.e. independent from whether it is paginated or not.
2. For larger datasets with callback based dynamic retrieval of further pages (i.e. point 3 of the ‘wishlist’), I’d expect a callback based approach for sorting as well, given there is no sensible option for the component to sort in any meaningful way in memory.

Of course, option 1. would mainly be a (nice) DX convenience, so option 2. would be the more important one.

What I’d never, ever expect would be resorting of only the current page in memory, as that would be highly confusing (unless the table consists of a single page only, of course).

[ddraper]

@hopel

What I’d never, ever expect would be resorting of only the current page in memory, as that would be highly confusing (unless the table consists of a single page only, of course).

I absolutely agree… I was including that as an example to indicate that even sorting by column is not a trivial addition because the required behaviour can change depending upon the context. This why I think a single table implementation will struggle to meet everyone’s needs.

So this I’m personally in favour of “atomic” table components that can then be composed into different types of table for convenience, but still allow bespoke customisations where you can swap out individual table elements if required.

[FabienLydoire]

Hello Atlassian Forge Team,
@AdamMoore @ddraper

I looked up the card and the target is Jul-Sep 2023.
It’s been 11 months that this subject has been open.

I understand the gigantic task represented by implementing Forge in all kinds of systems at Atlassian. But from an application perspective, the state of UI Kit 2 UI components is not really ready for business, except for very simple and minimalistic UI. As stated in this thread, you cannot make a decent looking Table at the moment.

Any update on additional options/components in UI Kit 2 for the upcoming months ?

[PeterCock]

Just adding to the feedback here.

Simply wanted to set “table-layout: auto” instead of the “table-layout: fixed” which is current.
A little frustrating that I had to use the custom a UI solution for something so simple and loose the benefits of UI kit.
A mixture of auto and set width columns would be best. Your DynamicTable from ‘@atlaskit/dynamic-table’ is great.

Current (table-layout: fixed):

Configurable improvement (table-layout: auto):

[shushen]

Bump this - I’m in a similar situation and I hate to be forced to use Custom UI just because of this table column width issue.

[shushen]

Hmm, interestingly it appears the columns width are adaptive when the “rowsPerPage” are set to non-zero (i.e., pagination enabled). I’m on 9.1.4 of @forge/react.