Library

React Components / v9 (@fluentui/react-components)

Describe the feature that you would like added

Per documentation, in order to use <Tree> component in a controlled fashion, we need to assign an id of type TreeItemId to each of the child <TreeItem> component. Currently, TreeItemId is a type alias of string.

The request is to augment this type definition so it can accept "anything":

export type TreeItemId = unknown;

and set up a convention that "each TreeItem can be identified by a unique value, and the uniqueness is the same as === comparison". This way, value types (e.g., string / number / etc.) with same values, or object types with same references can be treated as same, and can be used to identify the <TreeItem>.

Also, I'm not sure whether it's intended to apply the TreeItemProps.id property to the rendered DOM element like as shown in the following screenshot, but it seems the id DOM attribute should be globally unique in the document and I won't recommend to reuse this attribute for consumption in React components.

You may probably consider to change the name of this property. This TreeItem identifier looks more like a "key" from React's concept to me.

Have you discussed this feature with our team

N/A

Additional context

Our usage scenario is, we have a file-system-like structure like this (simplified representation)

export class File {
    name: string;
    rename(newName: string): Promise<void>;
    // ...
}

export class Folder {
    name: string;
    rename(newName: string): Promise<void>;
    children: Array<File | Folder>;
    // ...
}

And a file system can be represented with its root Folder instance.

While we'd really like to identify each of the <TreeItem> with the File or Folder instance (the class instances are unique per physical file / folder), we cannot and are forced to set up a workaround that assigns an artificial string ID to each of the File / Folder instance, only to enable it to work with <TreeItem>. This need looks somewhat weird to me.

Validations

• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.