Skip to content
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

Closed
lxe opened this issue May 14, 2019 · 1 comment
Closed

Hints / suggestions / autocomplete are missing #7723

lxe opened this issue May 14, 2019 · 1 comment

Comments

@lxe
Copy link

lxe commented May 14, 2019

ref: flow/flow-for-vscode#333

When types are available, key/property suggestions should be recommended by flow.

Expected Behavior (TypeScript):

Screen Shot 2019-05-05 at 8 01 45 AM

Observed Behavior (flow-for-vscode with TS/JS VSCode extensions disabled):

Screen Shot 2019-05-05 at 8 04 10 AM

It does work for classes, as demonstrated in the Readme:

Screen Shot 2019-05-05 at 8 14 35 AM

Doesn't work for React components or props:

nosuggestions1 mov

Sometimes it's showing incorrect suggestions.

Screen Shot 2019-05-14 at 12 50 31 PM

My vscode config:

{
  "editor.snippetSuggestions": "none",
  "editor.wordBasedSuggestions": false,
}

JS/TS Extension is disabled.

Flow version 0.98.1
Flow Language Support Extension 1.1.0

@maciekbb
Copy link

Are there any plans to implement this? This issue actually dates back to 2016 #3074

@goodmind goodmind added autocomplete and removed LSP labels Jul 12, 2019
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
Projects
None yet
Development

No branches or pull requests

3 participants