Describe the bug
If you check a variable in HTML has a truthy value (not null, not undefined, ...) and call then a method on it, I get an error with unknown method because VSCode believes object can be undefined.
Example:
{{ foo && foo.bar() }}
In my example, I consider foo : Type | undefined;
To Reproduce
Just implement a similar simple foo attribute in an Angular component and try to call a method in the template checking truthy first.
Expected behavior
No red highlighting as value is checked using foo &&
Screenshots

In this case, startModelInstance is defined as public startModelInstance?: ModelInstance;
Can you show us the definition of ModelInstance? I tried reproducing this with public name?: string; and {{ name && name.toUpperCase }} but could not get the error to appear.
you can use this example:
import { Component } from '@angular/core';
@Component({
selector: 'issue',
template: `
{{ element && element.blur() }}
~~~~~~~~~~~~~~~
Unknown method 'blur'
`,
})
export class ApiListComponent {
element?: HTMLInputElement;
}
you can use this example:
import { Component } from '@angular/core'; @Component({ selector: 'issue', template: ` {{ element && element.blur() }} ~~~~~~~~~~~~~~~ Unknown method 'blur' `, }) export class ApiListComponent { element?: HTMLInputElement; }
That's it !
Sorry for the delayed response. I just tried this and am unable to see the error. What version of the language service and TypeScript are you using when this is observed? (This can be found by going to View > Output > Angular Language Service on the dropdown and copy/pasting the contents of that log.)
@ayazhafiz
[Info - 10:51:23 AM] Angular language server process ID: 9135
[Info - 10:51:23 AM] Using typescript v3.7.4 from /home/***/.vscode-server/extensions/angular.ng-template-0.900.7/node_modules/typescript/lib/tsserverlibrary.js
[Info - 10:51:23 AM] Using @angular/language-service v9.0.0-rc.11 from /home/***/.vscode-server/extensions/angular.ng-template-0.900.7/server/node_modules/@angular/language-service/bundles/language-service.umd.js
Strange. Can you confirm that the example @andrius-pra posted above reproduces the issue for you?
I was also unable to reproduce the error with the example that @andrius-pra showed.
Here's my screenshot:

@BenjaminB64 When you hover over startModelInstance, what does the hover tooltip show?
Specifically, does it show the type of the symbol? If so, what is it?
I was also unable to reproduce the error with the example that @andrius-pra showed.
Use strict mode in tsconfig:
"compilerOptions": {
"strict": true
},
To fix this, a couple options are to either perform true template type checking in the language service or disable strict null checks when performing diagnostics in the && context. I think the second definitely is not preferable, and in the current state the first would either be a very large change or a patch just for this use case. I know we are pushing a lot of things post-Ivy, and I think this should fall in that boat as well -- after the Ivy rewrite for the language service's backend, the way we handle expression diagnostics and types will likely be different, and there is a chance that it will be easier to implement a fix for this.
In my opinion, I think it is okay to leave this as an open bug for now (and until after the Ivy rewrite). A workaround is to use Angular's safe method calls, like startModelInstance?.getInstanceName().
What do you all think?
I agree with @ayazhafiz, the long term solution is to wait for Ivy compiler to be integrated into language service and make a proper fix.
Meanwhile, as a short term fix, we could disable strict check in the language service (regardless of the value in user's tsconfig.json).
@BenjaminB64 When you hover over
startModelInstance, what does the hover tooltip show?
Specifically, does it show the type of the symbol? If so, what is it?
It was ModelInstance | undefined
To fix this, a couple options are to either perform true template type checking in the language service or disable strict null checks when performing diagnostics in the
&&context. I think the second definitely is not preferable, and in the current state the first would either be a very large change or a patch just for this use case. I know we are pushing a lot of things post-Ivy, and I think this should fall in that boat as well -- after the Ivy rewrite for the language service's backend, the way we handle expression diagnostics and types will likely be different, and there is a chance that it will be easier to implement a fix for this.In my opinion, I think it is okay to leave this as an open bug for now (and until after the Ivy rewrite). A workaround is to use Angular's safe method calls, like
startModelInstance?.getInstanceName().What do you all think?
I think it's a nice temporary solution :)
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
you can use this example: