feat: improve key type to support React.Key

[madocto]

ref: ant-design/ant-design#47837

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.58%. Comparing base (d21b6bb) to head (e7abb7e).
⚠️ Report is 82 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #692   +/-   ##
=======================================
  Coverage   99.58%   99.58%           
=======================================
  Files          27       27           
  Lines         721      721           
  Branches      196      198    +2     
=======================================
  Hits          718      718           
  Misses          3        3           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[crazyair]

这个好不容易是 string 了，又要改会 key 吗，如果要改，改成 T 吧

[madocto]

React.Key 会有问题吗？

[crazyair]

里面包含 number，如果我想执行处理字符串的方法，还需要转一次字符串

[madocto]

还是希望 string | number 都能支持，并且输入的类型和输出的类型一致，如果合并了 #692 ，那 React.Key 默认是不是就支持了？

[crazyair]

用泛型

[MadCcc]

范型 +1，React.Key 有时会包含奇怪的东西，让用户自己指定 key 类型比较好

[PaulCordo]

React.Key is the type used in the dependency rc-menu

menu/src/interface.ts

Line 54 in f94aec3

key: React.Key;

and correctly suited to be used as the key prop, I feel this type should follow the dependency type instead of forcing string

[nrps9909]

I revalidated exact head e7abb7e63206dd9786e779c4c32cf8cd541fb884 with the dependency range recorded by this branch. npx tsc --noEmit passes with zero errors on exact base cfce76e45070af8f65877786d12bb1a4662f3502, but the PR head fails compilation after widening the controlled/event API to React.Key.

Two direct examples are docs/examples/antd-switch.tsx:33 and docs/examples/debug.tsx:121: each stores open keys in string[], while the changed onOpenChange now supplies Key[], producing TS2345 (Key[] is not assignable to string[]; number is not assignable to string). The head also produces further downstream example errors, whereas the exact base does not. This confirms the compatibility issue raised in the 2024 review thread: a blanket React.Key return type widens existing string-key consumers even when they never opt into numeric keys.

Please rebase onto current master and use a type design that preserves the caller-selected key type (the maintainer suggestion was a generic) rather than unconditionally widening every controlled state and callback. The refreshed branch should include compile-time coverage for both the existing string-only consumer and an opted-in numeric-key consumer, plus runtime coverage for selection, open paths, and keyboard navigation. Runtime tests on this old head reached 115/116, with the lone StrictMode warning assertion affected by today’s dependency environment; lint has no errors. The compile regression above is deterministic and base-differential, so it is the blocking finding.