Closed
Labels
BugA bug in TypeScriptA bug in TypeScriptDomain: JSX/TSXRelates to the JSX parser and emitterRelates to the JSX parser and emitter
Milestone
Description
Type inference is not working for the ref callback prop.
I believe this is the same issue as in #7088, which was fixed over a year ago.
TypeScript Version: 2.3.2
Code
// A *self-contained* demonstration of the problem follows...
class Other extends React.Component<any, any> {
render() {
return <div />;
}
}
class Container extends React.Component<any, any> {
private _ref: Other;
render() {
// Parameter 'ref' implicitly has an 'any' type.
return <Other ref={ ref => this._ref = ref } />;
}
}Expected behavior:
Type of parameter ref should be inferred as Test
Actual behavior:
Parameter 'ref' implicitly has an 'any' type.
Reacted by flatline, Stan Luo, Gianfranco P and Nikolay Kuchumov
Metadata
Metadata
Assignees
Labels
BugA bug in TypeScriptA bug in TypeScriptDomain: JSX/TSXRelates to the JSX parser and emitterRelates to the JSX parser and emitter
Activity
mhegazy commentedon May 24, 2017
The issue here is that the type of
propsisany, sinceOtheris declared to extend fromReact.Component<any, any>. The result here is that all references to props are practically unchecked.if this component does not have any properties, then declare it as
extends React.Component<{}, any>.if the intention is to allow any property to be defined on this component, then declare at as
extends React.Component<Record<string, any>, any>.simonvizzini commentedon May 24, 2017
Thank you, Mohamed Hegazy (@mhegazy)! In my concrete case I actually did have a concrete Props interface defined, I just didn't think about this when trying to come up with a minimal example (I'm still learning the nuances of the type system). Nonetheless, I'm simply unable to properly type the ref callbacks, especially when defining Props interfaces that extend other, generic props (e.g.
interface Props extends React.HTMLProps<HTMLInput>). Typescript gave funny errors along the lines of "got type A but expected B", where A extends from B, and when I changed the type def to type to B it said "got B but expected C", where B again extends from C...It's most likely a misunderstanding on my side, still learning ts and so I'll come up with a more concrete example today or tomorrow.
mhegazy commentedon May 24, 2017
this works for me. if you have a sample we can look more.
simonvizzini commentedon May 30, 2017
Thank you, your example indeed works. Finally I had time to come up with a better example that doesn't work for me. I'm probably doing something wrong I think:
When I try to explicitly set a type like
ref={(p: MyInput) => 0}then I get following compiler error:When I try to set the type to
HTMLInputElementI get:Clearly I have no idea what's going on here and I'm just randomly throwing types at my code until the compiler stops complaining 😆
simonvizzini commentedon May 30, 2017
I'm so sorry for spamming your inbox :) I think I finally figured out why TS is complaining (somehow I always missed the
Property 'render' is missing in type 'HTMLInputElement'.'part of the error message, which gave me a hint in the right direction):When I change the props interface to this:
(note the
MyInput & HTMLInputElement) then the compiler is happy. Automatic type inference ofpis stillany(not sure if this is a bug or a limitation), but at least I can explicitly define the type in the ref callback now. Could you confirm if I'm doing this right?mhegazy commentedon May 31, 2017
React.ChangeTargetHTMLPropsextendsReact.ClassAttributeswhich overridesrefto be a union type. here is the definition from react declaration file on DT.The result here is that there is no contextual type for the function, and this
pisany. this looks like a bug that we should fix. this should behave the same way it does with something like:17 remaining items
timc13 commentedon Apr 19, 2018
would love to see this get fixed!
ImAbhishekTomar commentedon Jun 6, 2021
i am also facing similar type of issue.
ERROR
Andarist commentedon Nov 1, 2024
The reported case is about the parameter not being contextually typed for this
ref. It works today so I think it's fair to close this issuecc Ryan Cavanaugh (@RyanCavanaugh) Jake Bailey (@jakebailey)