Skip to content

fix(core): infer tag name for test root component #62283

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

crisbeto
Copy link
Member

Currently when a component is inserted, the tag name of its host is inferred from the selector, however in tests we always render it out as a div.

These changes switch to inferring the tag name so that things like querySelector work consistently.

Currently when a component is inserted, the tag name of its host is inferred from the selector, however in tests we always render it out as a `div`.

These changes switch to inferring the tag name so that things like `querySelector` work consistently.
@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 Jun 26, 2025
@angular-robot angular-robot bot added the area: core Issues related to the framework runtime label Jun 26, 2025
@ngbot ngbot bot added this to the Backlog milestone Jun 26, 2025
const testComponentRenderer = this.inject(TestComponentRenderer);
const componentDef: ComponentDef<T> = (type as any).ɵcmp;
const rootElId = `root${_nextRootElementId++}`;
const defaultTag = componentDef.selectors[0][0] as string;

Choose a reason for hiding this comment

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

Does this also work for non-trivial selectors, e.g. button[matButton]?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this is the selector after it has been parsed by the compiler into a CssSelectorList

Choose a reason for hiding this comment

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

@crisbeto it looks like it is roughly the same logic as in

const tagName = ((componentDef.selectors[0][0] as string) || 'div').toLowerCase();
const namespace =
tagName === 'svg' ? SVG_NAMESPACE : tagName === 'math' ? MATH_ML_NAMESPACE : null;

The main difference being that component ref takes namespace into account (?). Maybe it would make sense to factor this out and re-use?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm good callout, although I guess there aren't many usages of SVG or MathML for component roots since we haven't heard about this before.

Choose a reason for hiding this comment

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

Yeh, I was just looking at it from the "don't duplicate code / concepts" side of things

@crisbeto crisbeto marked this pull request as ready for review June 26, 2025 09:52
@pullapprove pullapprove bot requested a review from kirjs June 26, 2025 09:52
Copy link
Contributor

@thePunderWoman thePunderWoman left a comment

Choose a reason for hiding this comment

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

LGTM

reviewed-for: fw-general, public-api

// Note: injecting the renderer before accessing the definition appears to be load-bearing.
const testComponentRenderer = this.inject(TestComponentRenderer);
const componentDef: ComponentDef<T> = (type as any).ɵcmp;
const rootElId = `root${_nextRootElementId++}`;
Copy link
Contributor

Choose a reason for hiding this comment

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

Optional nit: It'd be nice to have a comment for the next two lines explaining what this is doing.

@pullapprove pullapprove bot requested a review from mmalerba June 26, 2025 09:58
Copy link
Member

@devversion devversion left a comment

Choose a reason for hiding this comment

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

LGTM

Reviewed-for: public-api

@crisbeto crisbeto removed request for kirjs and mmalerba June 26, 2025 11:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action: review The PR is still awaiting reviews from at least one requested reviewer area: core Issues related to the framework runtime target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants