Flow type arguments at callsites in class bodies
See original GitHub issueThis flow language feature is broken in class bodies (and possibly elsewhere, I haven’t looked):
class Correct extends React.Component<MyProps> {
myRef = React.createRef();
render() {
const {foo} = this.props;
return null;
}
}
class NotCorrect extends React.Component<MyProps> {
myRef = React.createRef<HTMLDivElement>(); // This causes the problem!
render() {
const {foo} = this.props;
return null;
}
}
Issue Analytics
- State:
- Created 5 years ago
- Reactions:10
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Announcing Bounded Polymorphism - JavaScript. Flow
As of Flow 0.5.0, you can define polymorphic functions and classes with bounds on their type parameters. This is extremely useful for ...
Read more >Generic Types | Flow
Classes can create generics by placing the type parameter list before the body of the class. ... You can use generics in the...
Read more >Function Types | Flow
Function Parameters. Function parameters can have types by adding a colon : followed by the type after the name of the parameter.
Read more >Class Types - JavaScript. Flow
Typing classes and using classes as types. ... Just like in functions, class methods can have annotations for both parameters (input) and returns...
Read more >Give Type a type argument such that T is Type<T> #2090
This issue is a proposal to change the built-in class Type such that it accepts a single type parameter with no bound, and...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
The
>
character is the issue. When inspecting the TM scope, it seems like it’s being treated as the>
of an arrow function (meta.function.arrow.js) which seems to break all of the syntax highlighting until the next}
(end of the make believe function. This might be a little tricky to debug, but I’ll try to take a look when I can.Yep, looks perfect!