Skip to content

Extra entries for JavaScript auto complete(intellisense) make no sense #15679

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

Open
LucioMS opened this issue May 8, 2017 · 5 comments
Open
Labels
Committed The team has roadmapped this issue Domain: Completion Lists The issue relates to showing completion lists in an editor Domain: JavaScript The issue relates to JavaScript specifically Suggestion An idea for TypeScript

Comments

@LucioMS
Copy link

LucioMS commented May 8, 2017

TypeScript Version: 2.2.1 / nightly (2.2.0-dev.201xxxxx)

Code
The following code in javascript:

/**
* @param {MessageActivity} activity
* @param {IConversationContext} context
*/
export function Prompt_beforeResponse(activity, context)
{
  // MessageActivity is defined in typescript definition provided to the editor as having 4 properties (attachements, text, speak, type). 
 // Typing activity. will show those for properties but also: 
 //     activity  - why should activity be under itself?
 //     context - why should the second parameter be under activity?
 //     IConversationContext - why would a type, that is not a property in any object be under activity?
 //     MessageActivity - same question as above
 //     onRun - why should a global function be under activity
 //     Prompt_when - same as above
 //     Prompt_beforeResponse - same question as above and this is the function itself


//  Here is another example. obj. should display only a and b, but it also shows activity, context, MessageActivity, IConversationContext, etc.
   /**
    * @type {{a: number, b: string }}
   */
   var obj = {};
   obj.
}
// A *self-contained* demonstration of the problem follows...

Expected behavior:
When a javascript type is not "any", i.e. when it is definded in jsdoc or in the typescript definition helper (See https://github.com/Microsoft/TypeScript/wiki/JavaScript-Language-Service-in-Visual-Studio#unsupported-patterns) only those defined members should be part of intellisense.
Even if the type is any, throwing everything on intellisense like that defeats the purpose of finding out what reasonably could be under the object.

Actual behavior:
A bunch of extra entries show up in intellisnese that make no sense for either typed or untyped scenarios, but it is specially bad for typed scenarios where some thought was put in place in what should appear in intellisense. Adding all those entries makes the intellisense feature less useful.

@LucioMS
Copy link
Author

LucioMS commented May 8, 2017

Note: This document: #4793 mentions:
As the type inference (and maybe even definitions) will not be accurate in all scenarios, the IDE should also provide affordances for selecting from the broader list of identifiers in the project, or manually entering any completions.

Which might have been the origin of this. But I see no point in all the entries added above, specially for the typed case.

@DanielRosenwasser DanielRosenwasser added the Working as Intended The behavior described is the intended behavior; this is not a bug label May 10, 2017
@DanielRosenwasser
Copy link
Member

There's honestly no guarantees we can make in JS mode. You could have captured the value in a closure and done something to it, and I'm not certain it makes sense to do extra checks to ensure of the scenario.

Additionally, while you don't find it useful, other people might. Specifically, identifiers used elsewhere in the file might be used to define a property on the current object. It seems unnecessarily restrictive to remove those. Personally, I appreciate the flexibility when I'm not getting any type-checking.

If you're seeing this behavior in --checkJs or // @ts-check mode, then that may be a problem we should consider.

@LucioMS
Copy link
Author

LucioMS commented May 10, 2017

There is one guarantee that is made by adding those entries: It is guaranteed to diminish the usefulness of the intellisense feature for javascript.

I would like to hear from someone the use anyone can make for the specific entries I mentioned. Types? One argument inside another? The identifier itself inside the identifier? All global symbols?

What is --checkJs ?

@mhegazy mhegazy added Suggestion An idea for TypeScript and removed Working as Intended The behavior described is the intended behavior; this is not a bug labels May 10, 2017
@mhegazy
Copy link
Contributor

mhegazy commented May 10, 2017

@mhegazy
Copy link
Contributor

mhegazy commented May 10, 2017

Based on the discussion in #15747, there seems to be value in pruning the completion list for values we know have an explicit type. There is no planned changes for values that have type any or { [x:string]: any }.

@mhegazy mhegazy added Committed The team has roadmapped this issue Domain: Completion Lists The issue relates to showing completion lists in an editor Salsa labels May 10, 2017
@weswigham weswigham added Domain: JavaScript The issue relates to JavaScript specifically and removed Salsa labels Nov 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Committed The team has roadmapped this issue Domain: Completion Lists The issue relates to showing completion lists in an editor Domain: JavaScript The issue relates to JavaScript specifically Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants