Skip to content
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

fix(ivy): Ensure proper namespace is used to create elements in JIT #28144

Closed
wants to merge 3 commits into from

Conversation

benlesh
Copy link
Contributor

@benlesh benlesh commented Jan 15, 2019

Updates render to properly use the namespace URL that Ivy passes around rather than use it to look up the namespace URL ala ViewEngine.

Resolves FW-811

@benlesh benlesh requested a review from a team as a code owner January 15, 2019 00:24
@mary-poppins
Copy link

You can preview 6131b4a at https://pr28144-6131b4a.ngbuilds.io/.

@AndrewKushnir
Copy link
Contributor

@benlesh it looks like you've created this PR on top of the master while it was in a state where "integration_test" was broken. Please rebase it from the latest master to make "integration_test" pass. Thank you.

@benlesh benlesh added target: major This PR is targeted for the next major release comp: ivy labels Jan 15, 2019
@ngbot ngbot bot added this to the needsTriage milestone Jan 15, 2019
@mary-poppins
Copy link

You can preview 3c7b67d at https://pr28144-3c7b67d.ngbuilds.io/.

@mary-poppins
Copy link

You can preview 5033202 at https://pr28144-5033202.ngbuilds.io/.

return document.createElementNS(NAMESPACE_URIS[namespace], name);
// In cases where Ivy (not ViewEngine) is giving us the actual namespace, the look up by key
// will result in undefined, so we just return the namespace here.
return document.createElementNS(NAMESPACE_URIS[namespace] || namespace, name);
Copy link
Contributor

Choose a reason for hiding this comment

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

There are two other places where we look the namespace up in this file - setAttribute and removeAttribute. Can you update those too?

Copy link
Contributor

Choose a reason for hiding this comment

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

Update based on offline discussion:

  • add TODO comments to setAttribute and removeAttribute
  • remove fixme for test

@AndrewKushnir
Copy link
Contributor

@kara @benlesh I think we may also need to check how VE and Ivy handle the case when invalid/unsupported namespace is specified and align this behavior (and have a test to capture this). My understanding is that we'll see a difference after this change due to the fact that we return namespace as is in case it's not registered in NAMESPACE_URIS.

Copy link
Contributor

@mhevery mhevery left a comment

Choose a reason for hiding this comment

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

Presumably there is a failing tests which this unblocks. I don't see any changes to the tests.

@trotyl
Copy link
Contributor

trotyl commented Jan 16, 2019

What if some custom renderers do need the raw namespace text? Renderer is a public API, how could a breaking change being introduced directly?

@benlesh
Copy link
Contributor Author

benlesh commented Jan 18, 2019

Copy link
Contributor

@kara kara left a comment

Choose a reason for hiding this comment

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

LGTM, aside from typo

@@ -154,6 +156,8 @@ class DefaultDomRenderer2 implements Renderer2 {
setAttribute(el: any, name: string, value: string, namespace?: string): void {
if (namespace) {
name = `${namespace}:${name}`;
// TODO(benlesh): Ivy may cause issues here because it's passing around
// full URIs for namespaces, therefor this lookup will fail.
Copy link
Contributor

Choose a reason for hiding this comment

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

Same below:

Suggested change
// full URIs for namespaces, therefor this lookup will fail.
// full URIs for namespaces, therefore this lookup will fail.

@kara kara dismissed mhevery’s stale review January 18, 2019 02:37

Comment has been addressed

@benlesh benlesh added the action: merge The PR is ready for merge by the caretaker label Jan 18, 2019
@alxhub alxhub closed this in 2b9cc85 Jan 18, 2019
@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 Sep 14, 2019
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 cla: yes risk: low target: major This PR is targeted for the next major release type: bug/fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants