Repository navigation
Conversation
50f29c1 to
554e814
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
alxhub
left a comment
There was a problem hiding this comment.
First round of review! Overall this is in pretty good shape.
A few meta-comments about the PR as a whole:
- Ideally, we would split this up into multiple commits.
For example, one commit could deal with adding the extra metadata to .d.ts files (starting as never always), another could do the parsing, another the template type-checking, etc.
- This should not be a
featcommit if the feature is not actually implemented.
Instead, make it a refactor commit. We don't want any entry in the changelog until the feature is usable to users. For a big implementation like this, we can have multiple PRs adding implementation details that aren't exposed, and then a final feat commit which only makes the API public.
- On that note, we shouldn't also add
hostDirectivesto the public@Directivemetadata just yet.
That is, we shouldn't change the public API and allow users to access the feature until it's fully implemented and working.
|
Regarding splitting it up into multiple commits: I agree that this is a huge change, but I ended up going with the single commit, because the majority of it are the actual tests, not the compiler code, and in order to make some tests work, most of the compiler changes would have to be in place. Regarding the commit message: I can target this to the Regarding exposing the new API in the |
1b42abd to
9a0bbf5
Compare
|
@alxhub I've addressed the feedback above and the things we talked about in person. All the changes are in the second fixup commit. Here's a high level overview of what has changed:
|
`ComponentRef.setInput` works by calling `setInputsForProperty` internally. It can be problematic, because it will set the all inputs on the specific node matching the passed-in name, including other directives that aren't associated with the `ComponentRef`. Currently this isn't a problem, because the only way to get a `ComponentRef` is as a result of `ComponentFactory.create` and there is no way to apply other directives through there, however I see a couple of ways that it can manifest itself in the future: 1. Once the runtime for host directives is implemented (after angular#46868), users will be able to apply directives to the root component. 2. If we were to make it possible to inject `ComponentRef` in the future. These changes add some extra logic so that the input is only assigned to the component instance that is associated with the `ComponentRef`.
4ae9164 to
3bfea17
Compare
pkozlowski-opensource
left a comment
There was a problem hiding this comment.
LGTM
Reviewed-for: public-api
This is the compile-time implementation of the `hostDirectives` feature plus a little bit of runtime code to illustrate how the newly-generated code will plug into the runtime. It works by creating a call to the new `ɵɵHostDirectivesFeature` feature whenever a directive has a `hostDirectives` field. Afterwards `ɵɵHostDirectivesFeature` will patch a new function onto the directive definition that will be invoked during directive matching. For example, if we take the following definition: ```ts @directive({ hostDirectives: [HostA, {directive: HostB, inputs: ['input: alias']}] }) class MyDir {} ``` Will compile to: ```js MyDir.ɵdir = ɵɵdefineComponent({ features: [ɵɵHostDirectivesFeature([HostA, { directive: HostB, inputs: { input: "alias" } }])] }); ``` The template type checking is implemented during directive matching by adding the host directives applied on the host to the array of matched directives whenever the host is matched in a template. Relates to angular#8785.
a0dff5f to
454dbd1
Compare
jessicajaniuk
left a comment
There was a problem hiding this comment.
reviewed-for: public-api
|
This PR was merged into the repository by commit 54ceed5. |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This is the compile-time implementation of the
hostDirectivesfeature plus a little bit of runtime code to illustrate how the newly-generated code will plug into the runtime. It works by creating a call to the newɵɵHostDirectivesFeaturefeature whenever a directive has ahostDirectivesfield. AfterwardsɵɵHostDirectivesFeaturewill patch a new function onto the directive definition that will be invoked during directive matching.For example, if we take the following definition:
Will compile to:
The template type checking is implemented during directive matching by adding the host directives applied on the host to the array of matched directives whenever the host is matched in a template.
Relates to #8785.