fix(Table): pass header colspan to th

[gigor]

🔗 Linked issue

Partially resolves: #3296

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Currently it is possible to create multi-level table headers, but colspan is not applied to th elements. This functionality is implemented in tanstack table and relies on it's internal mechanics.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pkg-pr-new]

npm i https://pkg.pr.new/@nuxt/ui@3926

commit: 807c177

[benjamincanac]

Can't we handle colspan and rowspan on th and td at the same time?

[gigor]

There is a well established tanstack way to work with grouped columns in thead and we just don't pass the attribute to table header. AFAIK, rowspan and colspan in tbody are supposed to be done via cell meta, but documentation there is confusing and I am not sure what is the right way.

This fix makes the following column definition work:

const columns = [
    {
        header: 'Asset',
        columns: [
            {
                header: 'Symbol',
                accessorKey: 'asset.code'
            },
            {
                header: 'Name',
                accessorKey: 'asset.name'
            },
        ]
    },
    {
        header: 'Strategy',
        columns: [
            {
                header: 'PCT',
                accessorKey: 'strategy.accountPct',
            },
            {
                header: 'Goal',
                accessorKey: 'strategy.goal',
            }
        ]
    }
];

[benjamincanac]

Should we unlink the #1651 issue then?

[gigor]

you are right, it should not be there

[benjamincanac]

You've also marked #3296 as resolved which doesn't seem to be the case.