type: update SpecialString type to use NonNullable #1361
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Walkthrough在 src/interface.ts 中，将类型别名 SpecialString 的交叉类型由 string & unknown 调整为 string & NonNullable。该变更仅影响类型层面，无运行时改动或逻辑流程变更。 Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Summary of Changes
Hello @afc163, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request refines the SpecialString type definition by incorporating NonNullable<unknown> instead of unknown. This modification aims to enhance type safety and correctness, specifically addressing an identified issue related to how string intersection types handle potential null or undefined values. The change is part of an ongoing effort to improve the robustness of the codebase.
Highlights
- Type Definition Update: The
SpecialStringtype definition has been updated insrc/interface.ts. - NonNullable Usage: The
unknowntype within theSpecialStringdefinition was replaced withNonNullable<unknown>to refine type handling. - Issue Resolution: This change addresses and closes issue #1360, likely resolving a type-related bug or inconsistency.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Pull Request Overview
Updates the SpecialString type definition to use NonNullable<unknown> instead of unknown for better type safety, addressing issue #1360.
- Replace
unknownwithNonNullable<unknown>in theSpecialStringtype intersection
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
|
||
| // SpecialString will be removed in antd@6 | ||
| export type SpecialString<T> = T | (string & unknown); | ||
| export type SpecialString<T> = T | (string & NonNullable<unknown>); |
There was a problem hiding this comment.
Using NonNullable<unknown> is equivalent to unknown since unknown is already non-nullable. This change has no practical effect. Consider using NonNullable<{}> or {} instead if the intent is to exclude null/undefined from the intersection.
| export type SpecialString<T> = T | (string & NonNullable<unknown>); | |
| export type SpecialString<T> = T | (string & {}); |
There was a problem hiding this comment.
@copilot Don't use {} as a type. {} actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want
objectinstead. - If you want a type meaning "any value", you probably want
unknowninstead. - If you want a type meaning "empty object", you probably want
Record<string, never>instead. - If you really want a type meaning "any non-nullish value", you probably want
NonNullable<unknown>instead.eslint@typescript-eslint/ban-types
There was a problem hiding this comment.
Code Review
This pull request updates the SpecialString type to use NonNullable<unknown> instead of unknown. This is a good change that correctly implements the string & {} pattern in TypeScript to improve autocompletion for string literals while still allowing any string. I've added one comment regarding a potential pre-existing issue with the SpecialString< T> type definition itself, which seems to incorrectly allow a record object to be used as a dataIndex. While the change in this PR is correct, it's a good opportunity to highlight this related issue for future improvement.
|
|
||
| // SpecialString will be removed in antd@6 | ||
| export type SpecialString<T> = T | (string & unknown); | ||
| export type SpecialString<T> = T | (string & NonNullable<unknown>); |
There was a problem hiding this comment.
This change correctly applies the string & {} pattern to improve autocompletion. However, the SpecialString< T> type itself appears to have a flaw.
By including T in its definition (T | ...), and since T becomes the RecordType when used in DataIndex, this type incorrectly allows a whole record object to be passed as a dataIndex. This is likely a bug.
A more correct approach would be to remove T from the union. For example:
export type SpecialString = string & NonNullable<unknown>;This would then require updating its usage in DataIndex on lines 88 and 90 (e.g., ... | SpecialString | ...).
Given this change is out of scope for the current PR, consider creating a follow-up issue or PR to address this typing issue.
There was a problem hiding this comment.
@gemini-code-assist Don't use {} as a type. {} actually means "any non-nullish value".
If you want a type meaning "any object", you probably want object instead.
If you want a type meaning "any value", you probably want unknown instead.
If you want a type meaning "empty object", you probably want Record<string, never> instead.
If you really want a type meaning "any non-nullish value", you probably want NonNullable<unknown> instead.eslint[@typescript-eslint/ban-types](https://typescript-eslint.io/rules/ban-types)
There was a problem hiding this comment.
Thank you for the clarification, @afc163. You are absolutely correct that {} should generally be avoided as a type, and NonNullable<unknown> is indeed the appropriate way to represent 'any non-nullish value' in TypeScript. My apologies for using {} as a shorthand in my previous comment when referring to the pattern.
My primary concern, however, remains with the inclusion of T in the SpecialString<T> definition (T | (string & NonNullable<unknown>)). As T becomes RecordType when SpecialString is used within DataIndex, this type currently allows an entire record object to be passed as a dataIndex, which seems unintended and could lead to runtime issues.
The suggestion to define SpecialString as export type SpecialString = string & NonNullable<unknown>; (without the generic T) and then update its usage in DataIndex was aimed at addressing this specific issue, ensuring that dataIndex only accepts string-like values or DeepNamePath<T>, but not the full RecordType itself.
I believe addressing the T in SpecialString<T> is important for type correctness, even if it's considered out of scope for this particular PR.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1361 +/- ##
=======================================
Coverage 96.10% 96.10%
=======================================
Files 57 57
Lines 3441 3441
Branches 630 630
=======================================
Hits 3307 3307
Misses 129 129
Partials 5 5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
src/interface.ts (1)
84-84: 该改动是 no‑op，无法修复 #1360 指出的“DataIndex 精确度丢失”
NonNullable<unknown>与unknown等价，string & NonNullable<unknown>仍会化简为string，不会恢复基于string & {}的补全/精确度行为。建议直接回退为string & {}（或等价的string & NonNullable<{}>）。-export type SpecialString<T> = T | (string & NonNullable<unknown>); +export type SpecialString<T> = T | (string & {});TypeScript 中 `NonNullable<unknown>` 是否等于 `unknown`？`string & NonNullable<unknown>` 会不会化简为 `string`？
🧹 Nitpick comments (1)
src/interface.ts (1)
86-90: SpecialString 将整个 RecordType 也纳入 DataIndex，可导致把对象误传给 dataIndex由于
SpecialString<T>包含T，DataIndex<T>现有定义允许把整条记录对象作为dataIndex传入（类型层面不报错）。这与期望的「键路径/键名/索引」语义不符。建议后续移除T，仅保留“带品牌”的字符串类型，并相应更新DataIndex。为避免在当前 PR 扩大变更面，建议另起 PR 处理。可选后续修正示例（单独 PR 执行）：
- export type SpecialString<T> = T | (string & {}); + export type SpecialString = string & {}; export type DataIndex<T = any> = | DeepNamePath<T> - | SpecialString<T> + | SpecialString | number - | (SpecialString<T> | number)[]; + | (SpecialString | number)[];
close #1360
Summary by CodeRabbit