microsoft / microsoft/TypeScript

Type Inference Enhancement of Handler Args

Open
#61,095 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Domain: check: Type Inference Help Wanted Possible Improvement
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

🔍 Search Terms

"type inference", "type narrowing"

✅ Viability Checklist
⭐ Suggestion

Introduction

When I write React codes with TypeScript, I sometimes define Props as the following.

type Props = ({
  parentIds: string[];
  onChange: (event: { id: string }) => void
  onChange2: () => void
} | {
  parentIds?: never;
  onChange: (event: { id: number }) => void;
})

It says, "When parentId is passed, string id is passed to onChange handler and you can use onChange2. If it is not passed, number is is passed to onChange handler".

But it doesn't work correctly. When I use it, as the following

function Component(props: Props) {
  return null
}

function App() {
  return (                                 
    <Component 
      parentIds={[]}
      // Expected: Parameter e is { id: string }
      // Actual: Parameter 'e' implicitly has an 'any' type.(7006)
      onChange={e => {
        if (e.id) {
          // Do nothing
        } else {
          // Do nothing
        }
      }}
      onChange2={() => {
        console.log("parentId is detected as string[]")
      }}
    />
  )
}

The parameter e of onChange is inferred as any, not { id: string }.
I can pass onChange2 handler so it seems type narrowing works, but type inference of the args of handler doesn't work.

Suggestion

How about enhancing type inference in such case?

demo:
https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgIilQ3wChSYBPMJOABRzAGc4BeOACgG9S44wURAHYwAkgBMAXHCYwowIQHMA2gF0A3LzgQhAYQAWKJUmkckANyQjpXOMCky5CxXAC+ASjYA+OOYj2tHQMjRSQAJlNPVh8-ANc4AB84Hj4BYTFxAH5pIQskKE0+IMNjUzzrZLsHIQBXEAAjfLcomP9xTQ9yTBqhDGAdOAA5HQBxK3zgNF1cSFyRDjBGJmkGCGZPFLgiGBqoIThagBtD0lcunr6BgEEwMA4NrW3d-Y4+N-ePz6-PrT4AHmGQjGuXkUxmOis8F+bzSkIkrC4ajOnwA9Ci4ABRAAeNAwSAcdEEKBASBgTVowBYtns0lk8iUbmhfDRcCuGBqKEOKyJJLJUDgAHIkAK7OBDpNgDBDpQ4IYWEZBUZKCKqDQAHQcADsAAZtQA2dxM7R6EqhBG0aLJI18YCYThINX2B7fZnogAiEAOEBg+mc1rccCQhyYtE23xZHq9Pr932RH1ccfexRC4QR928Vu+aB0TAghwdhwgig4+FhIgkdhY4lJSDx4jgKBYdOcanwhs+CehKK8WkNriAA

📃 Motivating Example

When you want to use same function or component for various purposes.

💻 Use Cases
  1. What do you want to use this for?
  2. What shortcomings exist with current approaches?
  3. What workarounds are you using in the meantime?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the linked TypeScript Playground example and confirm the implicit-any diagnostic (7006) for the handler parameter. No source file or test is named, so first locate the type-inference and contextual-typing entry points, then establish tests showing that the parameter is inferred as { id: string } while preserving the existing narrowing behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.