-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Hints / suggestions / autocomplete are missing #7723
Labels
Comments
Are there any plans to implement this? This issue actually dates back to 2016 #3074 |
7 tasks
facebook-github-bot
pushed a commit
that referenced
this issue
Aug 20, 2019
Summary: consider autocomplete inside an object literal, like this: ``` const x: T = { }; ^^ cursor between braces ``` we insert the autocomplete token `AUTO332` before parsing, so we actually parse `{ AUTO332 }`, which is a shorthand property, which is an identifier, so we return results for identifiers in scope, rather than for the valid properties of `T`. this is almost certainly not what anyone wants. but it's a bit tricky right now to actually autocomplete the right properties, because of the way hooks fire while traversing the AST in statement.ml. we need to know the upper bounds that the literal's ObjT flows into, or match certain syntax like assignments, destructuring, and casts. this diff makes us stop treating it as an identifier completion, and to return no results instead. but it also classifies it as an object key completion so we can measure how pervasive this is at the same time as we fix it properly. Issue: #7723 Reviewed By: panagosg7 Differential Revision: D16866760 fbshipit-source-id: b352fe3044a0fb3fe583dc11c0d362f792637224
facebook-github-bot
pushed a commit
that referenced
this issue
Aug 21, 2019
Summary: consider autocomplete inside an object literal, like this: ``` const x: T = { }; ^^ cursor between braces ``` we insert the autocomplete token `AUTO332` before parsing, so we actually parse `{ AUTO332 }`, which is a shorthand property, which is an identifier, so we return results for identifiers in scope, rather than for the valid properties of `T`. this is almost certainly not what anyone wants. but it's a bit tricky right now to actually autocomplete the right properties, because of the way hooks fire while traversing the AST in statement.ml. we need to know the upper bounds that the literal's ObjT flows into, or match certain syntax like assignments, destructuring, and casts. this diff makes us stop treating it as an identifier completion, and to return no results instead. but it also classifies it as an object key completion so we can measure how pervasive this is at the same time as we fix it properly. Issue: #7723 Reviewed By: panagosg7 Differential Revision: D16866760 fbshipit-source-id: c72edb54891e619afcd4c69db643ac6d342f9d62
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ref: flow/flow-for-vscode#333
When types are available, key/property suggestions should be recommended by flow.
Expected Behavior (TypeScript):
Observed Behavior (flow-for-vscode with TS/JS VSCode extensions disabled):
It does work for classes, as demonstrated in the Readme:
Doesn't work for React components or props:
Sometimes it's showing incorrect suggestions.
My vscode config:
JS/TS Extension is disabled.
Flow version 0.98.1
Flow Language Support Extension 1.1.0
The text was updated successfully, but these errors were encountered: