Files
angular__angular/goldens
Kristiyan Kostadinov 06ca0dcf27 refactor(core): remove assumptions that component will be first in directives list (#47490)
`TNode`s have the `directiveStart` and `directiveEnd` properties that indicate the indexes at which directive instances (including components) have been stored. Currently there are several places throughout the codebase which assume that if a component matches a node, its index will always be `directiveStart`.

As far as I can tell, we probably ended up accumulating these assumptions, because we needed a quick way of accessing the component instance and it happened to be conventiently stored at `directiveStart`. The reason why it's always stored at `directiveStart` is likely to match the lifecycle hook execution order from ViewEngine.

With host directives these assumptions won't be valid anymore, because we want the host directives to _always_ execute before the host component that they're on so that the host has a chance to override them. To achieve this we have to insert host directives before the component.

These changes address the issue by introducing a new `TNode.componentOffset` property which indicates the offset after `TNode.directiveStart` at which the component is stored. Furthermore, I've removed the `isComponentHost` flag since it was duplicating the information from `TNode.componentOffset` and I've audited and fixed all the places where we read `directiveStart` to account for the changed data structure.

Reasons for some of the decisions I made along the way:
* In the case of host directives, I decided to go against our current convention of executing the component lifecycle hooks before the directive, because lifeycle hooks are a chance to change the component state (e.g. in `ngOnChanges`) and running the component hooks first would allow the host directives to undo any overrides made by the host.
* I decided to go with a `componentOffset`, instead of a `componentIndex` indicating the exact index the component is at, because as the runtime is set up at the moment, it would be difficult to know what index the component is going to end up at. Another problem is that we appear to have some logic that moves the entire "directive window" by incrementing both `directiveStart` and `directiveEnd`. By using an offset, we don't have to worry about the index remaining correct.

PR Close #47490
2022-09-21 10:05:32 +02:00
..

public-api/

This directory contains all of the public api goldens for our npm packages we publish to NPM. These are tested on all PRs and commits as part of our bazel tests.

To check or update the public api goldens, run one of the following commands:

yarn public-api:check
yarn public-api:update

packages-circular-deps.json

This golden file contains a list of all circular dependencies in the project. As part of the lint CI job we compare the current circular dependencies against this golden to ensure that we don't add more cycles. If cycles have been fixed, this file is also updated so that we can slowly burn down the number of cycles in the project.

To check or update the golden, run the following commands:

yarn ts-circular-deps:check
yarn ts-circular-deps:approve