[Table] Remove requirement for a header or data row template

[andrewseguin]

It's valid that tables may not want any header, or a table could only be a header. Support this use case by letting users avoid defining a cdk-header-row or cdk-row which means that they should not be inserted.

Motivation: A table footer row could be a single row composed of a single row without a header. If placed after a preceding table, it acts as a sticky footer. Works well for cases where the header should not affect the rows, e.g. a totals row

Note that this doesn't help in cases where a scrollbar appears on one container but not the other. This will cause misalignment on browsers that push content left to show a scrollbar rather than overlay it (e.g. safari)

[andrewseguin]

For those giving a thumbs up, can you provide some context in how you'd want to use this? I'm starting to lean towards keeping the API strict (require both mat-row and mat-header-row). If you want to hide the rows or header, using display: none should be sufficient. That way, there's no magic going on behind the scenes that might complicate the usage of the table.

[willshowell]

@andrewseguin maybe tag them since you don't get notifications for reactions? From a strictly high-level view, it does seem strange that to have just data, that you still need to render the row but then hide it with css.

I assume it becomes a problem when you define headers for some columns but not others?

[Lakston]

I personally went the display route like this

<mat-header-row 
    *cdkHeaderRowDef="['col1', 'col2']"
    style="display: none;">
</mat-header-row>

and it works fine on all browsers, I use the paginator so I didn't encounter any problems regarding the scroll bar since well, I don't have one.

[ahinni]

@andrewseguin My use case is a table where the header columns go down the left side, instead of at the top. Example: a two column table of key/value pairs for displaying properties. I don't want a header of ['key', 'value'], just the rows. Sure, adding a style="display: none;" works, but it would be more natural to just exclude the mat-header-row element completely. It was what I tried first, before searching and ending up here...

[simeyla]

For my case I'm showing a list of tracking events for a package, eg 'Picked up', 'Delivered'

The data simply doesn't need a header that says Dateand Event because it's obvious and I have limited space. I want it to still be a mat-table so it matches the style of other tables.

[marioagarcia]

For my case I want to use the same header for two different tables as part of my rows is static data and the other part is inputs. It's a golf scorecard. So I would like to use one table for the static data and another for user input but just have one table header.

[zdzarsky]

I want to have a key-value table with no header.

[Anomnimel]

bump

[Wilt]

It would be nice to be able to simply skip rendering some rows. We have two tables using the same DataSource consuming the same data model. Like that we only need to send one request to the backend and maintain only the state of one collection (filters, sorting etc).
Now we simply want to render half of the data in one table and half of the data in another based on some property value. With using when we can nicely exclude the rows that we not want to render in the table but then I get a circular error message: Converting circular structure to JSON

Caused by getTableMissingMatchingRowDefError

Why not simply "skip" rendering a row... Why would that be a problem for the underlying DataSource? It is a simple feature request IMO.

Sure they can be hidden with [hidden]="true", or by using [ngStyle]="{ display: false }", but it influences performance poorly because under the hood it still keeps tracking changes and updating the template for both tables.

[Wilt]

@andrewseguin You suggest:

using display: none should be sufficient. That way, there's no magic going on behind the scenes that might complicate the usage of the table.

But I would like to refer to this post on Angular WiKi:

And even though the component is hidden, the component will be attached to its DOM element. It will keep on listening for events. Angular keep on checking for changes related to data bindings. The component behavior still exists even though it is hidden.

The component and its children components will be tie up resources. Memory burden might be high which results in poor performance, responsiveness can degrade and the user has no knowledge, why the application is slow.

So it’s better to add or remove elements to the component element to the HTML DOM rather than hiding or showing them.