-
Notifications
You must be signed in to change notification settings - Fork 12.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@ts-ignore is hard to use with calls to overloads #33795
Comments
This is only a problem with class components, interestingly. Function components are fine. |
Briefly, the reason that this fails is that reporting of errors on overloads doesn't want to stack tonnes of errors on individual parameters. Instead it puts a span on the entire call Because overload error reporting can report one error per overload per parameter, the non-overload behaviour of sticking errors on individual parameters would put multiple errors on each parameter. Instead it gives a multiline report-style error, but its span is the entire call. React.FC doesn't have overloads, so it will only ever have one error per parameter, so it keeps error on each parameter. (React.Component's constructor has two overloads, one of which is deprecated =( constructor(props: Readonly<P>);
constructor(props: P, context?: any); To fix this, we'd need to come up with a better way to correlate and display per-parameter errors with overloads. I'm not sure what that would look like. Thanks all for the playground links. React repros are 💯 easier now that the playground has react. |
That does work in the snippets above. How would you do it for this?
This stops the errors but puts a string into the JSX expression:
Flow supports
|
@turadg How would |
@sandersn I just want to make sure you know this works as-expected in 3.5 and it feels like a regression in 3.6 - almost like something changed so that Putting |
@sandersn In JSX within <> expressions, You can see the ts-ignore string appear in // style and be absent in {/* */} style
+1, this is a regression in 3.6 and persisting in 3.7 |
It's nothing specific to JSX, but rather a change to errors on overloads in general. It's affecting React because of the use of overloading in @types/react (interface Component + class Component) overload in DefinitelyTyped here. Here's an example of an overloaded function and the difference between 3.5.1 and 3.7.0: Might be a good question for the maintainers of the React types; I don't really understand why the interface overload is there. |
This worked for me ,
|
Agree that in 4.2.2 the problem in #31147 is gone. (What @vamshi9666 said now works.) Closing this issue since that is a fine work-around for the problem reported. |
TypeScript Version: 3.7.0-beta, 3.6.3
(Works in 3.5.1)
Search Terms: ts-ignore, JSX, React, props
Code
(See links on the version numbers above for TS Playground)
Expected behavior: no errors
Actual behavior: Error on
foo
and onbar
. Deleting either prop makes for no errors.Playground Link:
Related Issues: I first thought it was #33256 but @sandersn advised to file a separate issue
The text was updated successfully, but these errors were encountered: