Relevancy of JS Code completion

When working with PHP, the code completion is extremely helpful. I don't have to go looking up API documentation or flicking between files in order to find variable or method names since method names and public properties can be found much quicker using the inline code-completion list. The improvement in speed is substantial and it is easier to keep my train of thought.

I'm struggling to find the same utility with JS though since the code completion list is, for want of a better word, polluted with all sorts of random variables and functions that bear little relevancy to what I'm doing. I have already tried deselecting all of the libraries in "Settings/Languages & Frameworks/JavaScript/Libraries" but to no avail. Also note that the code completion dialogue is set to order by relevancy.

By way of example, I have imported an NPM module that exports an object that includes, among other properties, "obj.compile.script.typescript". All of these keys are explicitly exported by the module and are documented with JSDoc. As such, I would expect that each property in this chain would be pushed up to the top of the code completion list. Instead, I get rubbish like "blink()" "charCodeAt()" "closedByChildren" and so on. 

All of these junk items make the code completion useless. I am quicker looking up API documentation or jumping to the source file than I am scrolling through the code completion list. Does anyone know how to make code completion with JS useful?

 

EDIT #1: I noticed that the first level in the property chain ("compile" in the example property above) is prioritised as I would expect; i.e. with the exported properties at the top of the code completion list. However, the second, third, et al levels in the chain are not. Looking at the source code, the first level properties can be easily found through static code analysis whereas the other levels are the exported result of a function. I had thought that the JSDoc comment would have resolved this but it appears not.

I'm going to see if there is a better way to document the module for improved code completion support.

 

EDIT #2: I changed the way I was documenting the module (still using JSDoc but writing the documentation in a different way) and that has sorted the code completion priorities. See comment below for solution.

0
3 comments
Avatar
Permanently deleted user

Why not state your solution so that others with the same issue can at least know how to address it?

1

As per Aaron's suggestion, my solution was as follows:

Context

The original module exported a function that, when called, returned the object that I wanted to have code completion for (there is a good reason for this). I initially wrote the JSDoc comment inside the function at the point the return variable was initialised. However, when I imported the module to use in another project, I encountered the problem described in the OP.

Solution

After trying a few different approaches, I rearranged the JSDoc comment by creating a @typedef for the return variable and then using an @returns tag to indicate that the function returned that type. This sorted the code completion issue.

Conclusion

In the end it appears to be an issue of scope. I had thought that when the IDE analysed the function and found the returned variable it would also see that the returned variable had an associated JSDoc comment. It may be that the IDE simply deprioritises JSDoc comments that are declared in a different scope unless there is an explicit type declaration that links to it. Or it may be some thing else entirely.

Regardless, being methodical and explicit with JSDoc keeps the IDE on the same wavelength.

0
Avatar
Permanently deleted user

Thanks Peter!

0

Please sign in to leave a comment.