List: Parameterize generic type for item with any as default

[KevinTCoughlin]

Pull request checklist

• Addresses an existing issue: Fixes #0000
• Include a change request file using $ npm run change

Description of changes

I've found working with List and components that wrap it difficult as an end-user. This is partially because the backing items Array is typed as any[] and therefore type-safety is lost for TypeScript developers.

Last week on Shield, I watched a developer run into problems during a debug session as a result of this lack of type safety and thought it was worth fixing IFF backwards-compatibility could be maintained.

To reduce this barrier, I'm proposing that we parameterize the generic type for List's items as T which defaults to any.

This should maintain backwards compatibility as item and items will continue to be typed as any if a parameterized type is omitted. If the type is provided, then the intellisense and other goodness should then be provided.

Note: As part of our next major release we should look to remove the need for any as the default type.

IDE Output

Here is a brief comparison of Code's intellisense before and after this change for the code snippet below:

Usage:

export interface IListBasicExampleProps {
  items: IExampleItem[];
}

<List items={items} onRenderCell={this._onRenderCell} />

Before

onRenderCell prop:

(JSX attribute) onRenderCell?: ((item?: any, index?: number | undefined, isScrolling?: boolean | undefined) => React.ReactNode) | undefined
Method to call when trying to render an item.

items prop:

(JSX attribute) items?: any[] | undefined
Items to render.

List class definition

(alias) class List
import List

After

onRenderCell prop:

(JSX attribute) onRenderCell?: ((item?: IExampleItem | undefined, index?: number | undefined, isScrolling?: boolean | undefined) => React.ReactNode) | undefined
Method to call when trying to render an item.

items prop:

(JSX attribute) items?: IExampleItem[] | undefined
Items to render.

List class definition

(alias) class List<T = any>
import List

Focus areas to test

• CI should pass
• API file modifications should maintain backwards compatibility

Related to: #5557

Microsoft Reviewers: Open in CodeFlow

[KevinTCoughlin]

My primary concern here is maintaining backwards-compatibility. I believe this change achieves that. However, if it does not then I am fine with targeting 7.0 branch.

[ecraig12345]

Agreed that with T = any, you'll probably be safe for compatibility. Someone else correct me if I'm wrong.

[size-auditor]

Size Auditor did not detect a change in bundle size for any component!

[cliffkoh]

[msft-github-bot]

🎉[email protected] has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Official NPM Release
• Test the release with Developer Demo Site

[KevinTCoughlin]

For anyone that may land here due to compiler errors, the solution is likely as follows:

If you have previously defined your List's onRenderCell method as:

onRenderCell?: (item: Foo, index?: number, isScrolling?: boolean) => React.ReactNode;

Where item of type Foo is not marked as an optional parameter then you will need to mark it as such as it has been defined in IListProps. The modified signature would look like:

onRenderCell?: (item?: Foo, index?: number, isScrolling?: boolean) => React.ReactNode;

Also, in the body of the function you may want to guard against the case where item is undefined.

This bug was previously masked by the usage of any.