-
Notifications
You must be signed in to change notification settings - Fork 26.6k
fix(devtools): DOM traversal bug #62719
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
Conversation
42ade78
to
2e5e2c5
Compare
2e5e2c5
to
bcd4a54
Compare
@@ -92,30 +92,6 @@ describe('render tree extraction', () => { | |||
expect(rtree[0].children[0].children.length).toBe(0); | |||
}); | |||
|
|||
it('should go all the way to the root element to look up for nodes', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic to traverse up to the DOM is no longer the responsibility of RTree strategy so this test is no longer necessary.
The new behaviour is now tested for in devtools/cypress/integration/node-search.e2e.js
.
bcd4a54
to
e9685f3
Compare
devtools/projects/ng-devtools-backend/src/lib/component-tree/component-tree.ts
Show resolved
Hide resolved
devtools/projects/ng-devtools-backend/src/lib/directive-forest/index.ts
Outdated
Show resolved
Hide resolved
cec7d4d
to
2f3278e
Compare
27f7703
to
82192b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a good step in the right direction, so I think it's fine to move forward with this PR. I suspect there might be a future change we should consider in the framework so ApplicationRef
actually has correct knowledge of all the root views in an application so we don't need to do this work in DevTools at all.
devtools/projects/ng-devtools-backend/src/lib/component-tree/component-tree.ts
Show resolved
Hide resolved
devtools/projects/ng-devtools-backend/src/lib/component-tree/component-tree.ts
Show resolved
Hide resolved
devtools/projects/ng-devtools-backend/src/lib/directive-forest/index.ts
Outdated
Show resolved
Hide resolved
devtools/projects/ng-devtools-backend/src/lib/directive-forest/index.ts
Outdated
Show resolved
Hide resolved
4d3cf76
to
740f871
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple minor suggestions to think about, but nothing too significant. Thanks for looking into this!
devtools/projects/ng-devtools-backend/src/lib/component-tree/component-tree.ts
Show resolved
Hide resolved
devtools/projects/ng-devtools-backend/src/lib/component-tree/component-tree.ts
Outdated
Show resolved
Hide resolved
return []; | ||
} | ||
|
||
return strategy.build(element, i++); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider: I think flatMap
provides an index argument you can use instead of tracking i++
directly.
You might want to flatMap element
to [element, strategy]
first to handle the !strategy
case first:
elements.flatMap((element) => {
const strategy = selectStrategy(element);
if (!strategy) return [];
return [element, strategy];
}).map(([element, strategy], index) => strategy.build(element, index));
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Returning an array from the map causes weird things to occur with the typing of element and strategy. They both end up being treated as RTreeStrategy | LTreeStrategy | Element
. I think the current approach is sufficient to avoid this
dbc3524
to
0c7fe11
Compare
Previously, Angular devtools would mistakenly traverse the same DOM elements multiple times while doing traversal for the component tree explorer. This error case would occur when more than 1 Angular application root component was present on the same page and in distinct DOM branches. Some example cases that did work previously: ```html <app-root> ... </app-root> ``` ```html <app-root> ... <app-root-2></app-root-2> ... </app-root> ``` An example of where it would enter the irregular behaviour ```html <app-root> ... </app-root> <app-root-2> ... </app-root-2> ``` Now, we properly ignore duplicate DOM paths when looking for application and non-application root component to begin the Angular DevTools component discovery logic.
0c7fe11
to
4cc57d5
Compare
Previously, Angular devtools would mistakenly traverse the same DOM elements multiple times while doing traversal for the component tree explorer. This error case would occur when more than 1 Angular application root component was present on the same page and in distinct DOM branches. Some example cases that did work previously: ```html <app-root> ... </app-root> ``` ```html <app-root> ... <app-root-2></app-root-2> ... </app-root> ``` An example of where it would enter the irregular behaviour ```html <app-root> ... </app-root> <app-root-2> ... </app-root-2> ``` Now, we properly ignore duplicate DOM paths when looking for application and non-application root component to begin the Angular DevTools component discovery logic. PR Close #62719
This PR was merged into the repository by commit 5115050. The changes were merged into the following branches: main, 20.2.x |
Previously, Angular devtools would mistakenly traverse the same DOM elements multiple times while doing traversal for the component tree explorer. This error case would occur when more than 1 Angular application root component was present on the same page and in distinct DOM branches.
An example of where it would enter the irregular behaviour (previous state)
Now, we properly ignore duplicate DOM paths when looking for application and non-application root component to begin the Angular DevTools component discovery logic.