Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support two-way bindings in Ivy native language service #40185

Closed
wants to merge 7 commits into from

Conversation

atscott
Copy link
Contributor

@atscott atscott commented Dec 17, 2020

This PR adjusts various pieces of the Ivy native LS implementation to account for two-way bindings (aka banana in a box syntax).

Each commit has a very targeted goal to make it easier to review incrementally.

@google-cla google-cla bot added the cla: yes label Dec 17, 2020
@pullapprove pullapprove bot added area: compiler Issues related to `ngc`, Angular's template compiler area: language-service Issues related to Angular's VS Code language service and removed cla: yes labels Dec 17, 2020
@ngbot ngbot bot modified the milestone: Backlog Dec 17, 2020
@google-cla
Copy link

google-cla bot commented Dec 17, 2020

☹️ Sorry, but only Googlers may change the label cla: yes.

…y binding

This commit fixes the Template Type Checker's `getSymbolOfNode` so that
it is able to retrieve a symbol for the `BoundEvent` of a two-way
binding. Previously, the implementation would locate the node in the TCB
for the input because it appeared first and shares the same `keySpan` as
the event binding. To fix this, the TCB node search now verifies that
the located node matches the expected name for the output subscription:
either `addEventListener` for a native listener  or the class member of the Angular `@Output`
in the case of an Angular output, as would be the case for two-way
bindings.
@atscott atscott force-pushed the bananabox branch 2 times, most recently from b4d141d to 2b3181e Compare January 6, 2021 23:04
@atscott atscott requested review from kyliau and AndrewKushnir and removed request for AndrewKushnir January 6, 2021 23:07
packages/language-service/ivy/template_target.ts Outdated Show resolved Hide resolved
*/
export interface TwoWayBindingContext {
kind: TargetNodeKind.TwoWayBindingContext;
nodes: [t.BoundAttribute, t.BoundEvent];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Consider using explicit fields like input and output instead of a tuple.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alxhub and I talked about this and kind of liked that if we find more MultiNodeTarget types at some point, there would still be the consistent nodes property.

packages/language-service/ivy/template_target.ts Outdated Show resolved Hide resolved
…icate multi-node targets

The current template target implementation only allows a way to
represent the template position as targeting a single node in the
template AST. However, there is at least one case (banana-in-a-box)
where a given template position refers to two template targets.

This commit expands the contexts that the `TemplateTarget` can return to
include support for the banana-in-a-box syntax, which has two logically
targetted AST nodes given a position within the `keySpan` of the
binding.
…dings

Adjust the visitor logic of the template target as well as the
consumption of the visitor result to account for two-way bindings.

This sets up downstream consumers for being able to handle the
possibility of a template position that targets both an input and an
output.
Rather than expecting that a position in a template only targets a
single node, this commit adjusts the approach to account for two way
bindings. In particular, we attempt to get definitions for each targeted
node and then return the combination of all results, or `undefined` if
none of the target nodes had definitions.
Rather than expecting that a position in a template only targets a
single node, this commit simply adjusts the approach to account for two way
bindings. Specifically, we attempt to get references for each targeted
node and then return the combination of all results, or `undefined` if
none of the target nodes had references.
This commit adds special handling to the completion builder by detecting
a two way binding context and ensuring that we filter out any `Input`s
that do not support two way binding.
…two-way bindings

This commit simply adds a comment about why quick info only gets data
for the `BoundAttribute` of a two-way binding.
@atscott
Copy link
Contributor Author

atscott commented Jan 7, 2021

presubmit

@atscott atscott added action: merge The PR is ready for merge by the caretaker target: minor This PR is targeted for the next minor release labels Jan 7, 2021
@atscott atscott removed the request for review from AndrewKushnir January 7, 2021 17:55
@atscott atscott closed this in 46ea684 Jan 7, 2021
atscott added a commit that referenced this pull request Jan 7, 2021
…icate multi-node targets (#40185)

The current template target implementation only allows a way to
represent the template position as targeting a single node in the
template AST. However, there is at least one case (banana-in-a-box)
where a given template position refers to two template targets.

This commit expands the contexts that the `TemplateTarget` can return to
include support for the banana-in-a-box syntax, which has two logically
targetted AST nodes given a position within the `keySpan` of the
binding.

PR Close #40185
atscott added a commit that referenced this pull request Jan 7, 2021
…dings (#40185)

Adjust the visitor logic of the template target as well as the
consumption of the visitor result to account for two-way bindings.

This sets up downstream consumers for being able to handle the
possibility of a template position that targets both an input and an
output.

PR Close #40185
atscott added a commit that referenced this pull request Jan 7, 2021
#40185)

Rather than expecting that a position in a template only targets a
single node, this commit adjusts the approach to account for two way
bindings. In particular, we attempt to get definitions for each targeted
node and then return the combination of all results, or `undefined` if
none of the target nodes had definitions.

PR Close #40185
atscott added a commit that referenced this pull request Jan 7, 2021
…#40185)

Rather than expecting that a position in a template only targets a
single node, this commit simply adjusts the approach to account for two way
bindings. Specifically, we attempt to get references for each targeted
node and then return the combination of all results, or `undefined` if
none of the target nodes had references.

PR Close #40185
atscott added a commit that referenced this pull request Jan 7, 2021
This commit adds special handling to the completion builder by detecting
a two way binding context and ensuring that we filter out any `Input`s
that do not support two way binding.

PR Close #40185
atscott added a commit that referenced this pull request Jan 7, 2021
…two-way bindings (#40185)

This commit simply adds a comment about why quick info only gets data
for the `BoundAttribute` of a two-way binding.

PR Close #40185
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: compiler Issues related to `ngc`, Angular's template compiler area: language-service Issues related to Angular's VS Code language service cla: yes target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants