A central issue with autocompletion is that frequently, completion is requested when the template is not strictly valid. For example, the user may attempt to complete the expression foo., where the template parser expects an identifier, but none is present prior to the completion.
To allow for the best possible autocompletion experience, the template parser should still be able to produce ASTs for templates that are "invalid" in certain ways.
A few scenarios here stand out:
{{foo.}} should parse to an AST, even though it will (rightfully) produce an error about the expected identifier.
Ideally, this AST has a PropertyRead with an empty name, which the type-checking engine can use to generate correct auto-completion code.
{{foo should parse to an AST, even though it also produces an error about the missing interpolation ending tag }}.
<foo should parse to an AST, even though the element start closing marker > is missing. For example, <foo<bar></bar> should probably be interpreted as <foo></foo><bar></bar>. This will allow for autocompletion of tag names.
<foo [ and <foo [input should both parse to ASTs, even without expressions that follow or the closing ]. The same goes for event bindings.
<foo [bar]="... - this one is very tricky, since it's completely ambiguous where the expression is supposed to end. We might be able to cheat here and look at the cursor position, and attempt a parse that assumes a closing quote at the cursor position if the original parse results in unbalanced quotes. This is an "advanced" case and might be better left for future efforts.
A central issue with autocompletion is that frequently, completion is requested when the template is not strictly valid. For example, the user may attempt to complete the expression
foo., where the template parser expects an identifier, but none is present prior to the completion.To allow for the best possible autocompletion experience, the template parser should still be able to produce ASTs for templates that are "invalid" in certain ways.
A few scenarios here stand out:
{{foo.}}should parse to an AST, even though it will (rightfully) produce an error about the expected identifier.Ideally, this AST has a
PropertyReadwith an empty name, which the type-checking engine can use to generate correct auto-completion code.{{fooshould parse to an AST, even though it also produces an error about the missing interpolation ending tag}}.<fooshould parse to an AST, even though the element start closing marker>is missing. For example,<foo<bar></bar>should probably be interpreted as<foo></foo><bar></bar>. This will allow for autocompletion of tag names.<foo [and<foo [inputshould both parse to ASTs, even without expressions that follow or the closing]. The same goes for event bindings.<foo [bar]="...- this one is very tricky, since it's completely ambiguous where the expression is supposed to end. We might be able to cheat here and look at the cursor position, and attempt a parse that assumes a closing quote at the cursor position if the original parse results in unbalanced quotes. This is an "advanced" case and might be better left for future efforts.{{ a | }}