Questions about new "Add type hint" code intention

[Jason Clark]

Just watched the 2.2.1.9 release notes video - very cool stuff. After years of using IJ community edition, I’m trying out WebStorm to get all the new JS goodies. So apologies in advance if I overlooked something because I’m new to the JetBrains JS support.

In the vid, you demonstrated a new code intention, “Add type hint”. It works fine on a class-level property, but it isn’t working on a getter function. For example, my LWC’s html contains a lightning-input-rich-text and a custom LWC, c-modal, which is defined locally in the code. My JS file has these two getters:

    get modal() {
        return this.template.querySelector('c-modal');
    }

    get editor() {
        return this.template.querySelector('lightning-input-rich-text');
    }

The line of code this.modal.show() (in another function) which calls the @api method show() on the Modal LWC shows the warning “Unresolved function or method show()”, and pressing F1 on the symbol modal in that line shows only the method returns Element. So I'd like a type hint for get modal(). But Opt-Space (I’m on Mac) doesn’t show “Add type hint” as an option. I manually added the doc comment /* @type {Modal} **/ and everything works fine- warning went away and F1 and completion help look good. It just seems to be an issue with the code intention not recognizing the getter syntax. It would be nice if the system could recognize the the arg to querySelector is a simple LWC name and infer the type, but I also understand how complex .querySelector expressions could be, so doc hints are fine.

However, i’d like this.editor to have the same benefits of type info, but I cannot make that work. I tried /** @type {LightningInputRichText} **/ but that gives an error that LightningInputRichText is not a recognized type. It would be useful if the built-in LWC components would also give type info.

Also, just to make sure I’m not doing something wrong… WebStorm prompted me to update my file association for .js files to ‘JavaScript'; previously it was ‘JavaScript Files (Improved Syntax Highlighting)’. I think ‘JavaScript' must be right because everything seems to work as you showed in the video, but I don’t know where the other association came from. It was possibly imported from my IntelliJ CE install, but I still don’t know what ‘JavaScript Files (Improved Syntax Highlighting)’ is or what provides it, so I wanted to confirm that I’m configured correctly. Thanks!

‌

[Scott Wells]

Hey, Jason. The Add type hint intention only being available for fields and variables is an artificial limitation. That's how I'm filtering right now. It's trivial to open it up to other declaration types, and it makes sense to do so for property getters for sure. I may even be able to squeeze that into tomorrow's build. If not, the next one for sure.

As for the second point, you should use InputRichText and not LightningInputRichText. To be precise, it's InputRichText from the lightning/inputRichText module:

declare module 'lightning/inputRichText' {
    /** A WYSIWYG editor with a customizable toolbar for entering rich text */
    export default class InputRichText extends LightningElement {
        ...
    }
}

These are all defined in lwc-standard.d.ts which is bundled with IC2 and generated from lwc-standard.json which is used for all of the LWC standard tag and attribute completions.

Finally, because you came from Community Edition, you were using the "Improved Syntax Highlighting" simple file types for JavaScript and CSS that it includes to provide reasonable syntax highlighting and simple code completions. When you moved to a commercial JetBrains IDE, the .js and .css extensions needed to be moved to the associated first-class file types included in those IDEs. However, plugins aren't allowed to reassign file types, so IC2 tells you they're not set up properly and opens the appropriate settings view to do so. Now that you've done so you'll have the full editor experience for those file types.

There's quite a bit more in this general area coming in tomorrow's build. I'll see if I can squeeze in property getter function support for the code intention real quick in the morning before spinning a final build.

[Scott Wells]

It was trivial to support getters in the Add type hint code intention:

That will be in tomorrow morning's build.

[Jason Clark]

tomorrow morning's build

Brilliant, thank you! It’s not hard to type the doc hint, but I use the getter pattern quite often in LWCs, and I already see that hint as a time saver.

you should use InputRichText and not LightningInputRichText

Of course that makes sense, and I did think I tried that, but I must have typo’d it, as it certainly works now. You mentioned that your Typescript file is generated from lwc-standard.json; I’m guessing you mean this file from the forcedotcom/lightning-language-server repo? I noticed that InputRichText doesn’t have a completion for the setRangeText method, which is currently labeled “beta”, but I was surprised to note the JSON file in the repo is unchanged since August 2020. It seems like there have been a few LWC changes since that. At any rate, if that is the correct source you are using, I’ll file an issue on that repo to ask if the method is missing because of its beta status, or if it can be added.

Finally - Any way to give you credit when I purchase WebStorm before my trial ends? I’ve been using IJ for years due to Illuminated Cloud, and now I’ll be purchasing WebStorm for the same reason. And I suspect I won’t be the only one.

Thanks for the explanation and the quick turn-around. Please close once the build is out.

‌

[Scott Wells]

IC2 includes a heavily modified version of that JSON file. I've kept it up to date across releases and even fixed some issues. Same with some other docs like the bundled JSON schema files for SFDX config files.

Appreciate the offer to share your motivation for purchasing WebStorm. Not sure how you'd do that, though.

You'll see this go to resolved once the release is out tomorrow.

[Scott Wells]

Add type hint support for getters delivered in 2.2.2.1. The overall behavior of that action should also be smoother now.