Add type support for function/getter which returns a result of template.querySelector
Current behaviour:
-
The linter recognises public properties when called directly from querySelector, e.g.
this.template.querySelector('c-toast').customNotification('test')
recognises public propertycustomNotification
exposed on the custom Toast lwc.
-
The linter does not recognise public properties if the same is returned from a function or getter, e.g.
get toastComponent() { return this.template.querySelector('c-toast'); }
this.toastComponent.customNotification('test')
does not recognise public propertycustomNotification
exposed on the custom Toast lwc.
Requested behaviour:
- Persist the returned type from template.querySelector through a function/getter.
Comments (6)
-
repo owner -
repo owner Logged with JetBrains as WEB-57544.
-
repo owner - changed status to resolved
I'm going to resolve this for now assuming that it is something JetBrains has to address, but if they determine that I'm doing something incorrectly, I'll reopen to track my own fix.
-
Account Deleted reporter Related to the ticket - could you add linter support to elements returned by querySelectorAll when used in a loop.
e.g. this.template.querySelectorAll('c-component').forEach(element => element. /* does not show */ )
-
repo owner Darrion, I’m not seeing that last behavior. It seems to be resolving properly for me for both standard and custom components, e.g.:
To be specific, this is under 2022.2.3. Are you on the same underlying IDE version?
-
Account Deleted reporter Hi Scott, no I am 2022.2.2, will update and retest. Thanks.
Thanks and Regards,
[A picture containing text, clipart Description automatically generated]
Darrion Singh
Business Integration & Arch Analyst
[cid:image002.png@01D8DCCC.7F5DC340]
Buildings 3 & 6, Waterfall Corporate Campus, 74 Waterfall Dr, Waterval City, Midrand, 2090
Tel: +27 (11) 208 3203 Mobile: +27 (81) 736 4548
accenture.comhttp://accenture.com/
[Accenture][cid:image004.png@01D8DCCC.7F5DC340]
- Log in to comment
This seems to be a limitation (likely even a bug) of JetBrains' JS/ES6/TS type inference engine. As you point out, the following does not work:
while the following two do work:
and:
So I’m not sure there’s anything to do in IC2 here. It’s more likely that a bug needs to be opened against JetBrains. I can try to do that since I’ve already logged a number of bugs in their type inference engine that were unveiled by IC2 added information to it dynamically. Let me see if I can reproduce the issue in isolation of IC2 which would be best, but even if not, I can explain what I’m doing and what does/doesn’t work properly in that situation.