Skip to content

Conversation

@crisbeto
Copy link
Member

@crisbeto crisbeto commented Nov 25, 2024

Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a Record<string, string> since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE.

These changes aim to report a more accurate error for the most common case where the host object is initialized to a string -> string object literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases like host: SOME_CONST, but it's still better than the current setup.

Before:
image

After:
image

@crisbeto crisbeto added action: review The PR is still awaiting reviews from at least one requested reviewer target: patch This PR is targeted for the next patch release labels Nov 25, 2024
@crisbeto crisbeto requested a review from JoostK November 25, 2024 10:30
Copy link
Member

@JoostK JoostK left a comment

Choose a reason for hiding this comment

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

One additional gotcha here could be for duplicate host binding expressions; they would report individual errors for each occurrence, but will then all get reported on the first host binding occurrence.

Overall this still seems like an improvement 👍

@crisbeto
Copy link
Member Author

I was thinking about duplicates as well, but I don't think they'll be a problem because we throw a FatalDiagnosticError for the first invalid expression we see so the rest won't be reported.

…errors

Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a `Record<string, string>` since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE.

These changes aim to report a more accurate error for the most common case where the `host` object is initialized to a `string -> string` object literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases like `host: SOME_CONST`, but it's still better than the current setup.
@crisbeto crisbeto force-pushed the better-host-binding-errors branch from 8abee16 to 119877b Compare November 25, 2024 10:55
@crisbeto crisbeto added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Nov 25, 2024
thePunderWoman pushed a commit that referenced this pull request Nov 25, 2024
…errors (#58870)

Currently host bindings are in a bit of a weird state, because their source spans all point to the root object literal, rather than the individual expression. This is tricky to handle at the moment, because the object is being passed around as a `Record<string, string>` since the compiler needs to support both JIT and non-JIT environments, and because the AOT compiler evaluates the entire literal rather than doing it expression-by-expression. As a result, when we report errors in one of the host bindings, we end up highlighting the entire expression which can be very noisy in an IDE.

These changes aim to report a more accurate error for the most common case where the `host` object is initialized to a `string -> string` object literal by matching the failing expression to one of the property initializers. Note that this isn't 100% reliable, because we can't map cases like `host: SOME_CONST`, but it's still better than the current setup.

PR Close #58870
@thePunderWoman
Copy link
Contributor

This PR was merged into the repository by commit 4e92449.

The changes were merged into the following branches: main, 19.0.x

@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 Dec 26, 2024
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 target: patch This PR is targeted for the next patch release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants