bug(MatTable): trackBy does not differentiate between multiTemplateDataRows templates

[gremlin896]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

When using a MatTable with multiTemplateDataRows and trackBy, the provided TrackByFn will be passed the same arguments (index and the row object) for each of the templates for the same row object. This makes it extremely difficult to write a viable TrackByFn when using conditional multiTemplateDataRows via the when option.

Reproduction

By logging the output inside the TrackByFn, we can see that each row template is passed the same arguments (index and row object), and there is no simple way to differentiate between different row templates within the TrackByFn.

A typical use case which is very close to the multiTemplateDataRows example in the MatTable docs shows the issue clearly

Stackblitz example of a typical use case where the row object unique identifier is used for the TrackByFn.

Steps to reproduce:

1. toggle the first row 3 times

Expected Behavior

The TrackByFn should be provided with some differentiator per row template. (ideally some way to identify which template the trackBy was triggered for).

In the provided Stackblitz example, it would be expected that when using a typical TrackByFn, that the rows are rendered in the correct position always, instead of occasionally.

Actual Behavior

The TrackByFn is passed the same arguments for each row template per row.

In a typical use case (the provided Stackblitz) the table will misplace the rows under certain conditions, which can be seen by expanding and collapsing the first row a few times, the multiTemplate for the 2nd row will eventually be shown in the first row (video below).

Screen.Recording.2022-10-24.at.11.30.11.mov

Environment

• Angular: 14.2.7
• CDK/Material: 14.2.5
• Browser(s): Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): macOS

[gremlin896]

Currently the only workaround for this I have found is to use an auxiliary object to keep track of how many times the TrackByFn is called per id, and then appending this value to the returned unique identifier, resetting this auxiliary object whenever the data changes or the rows are toggled.

This solution seems to work fine, but can be very complex and hard to read given more complex situations (for example, with additional conditional row templates)