Skip to content

Conversation

rictic
Copy link
Contributor

@rictic rictic commented Oct 18, 2019

And keep DomApiNative type compatible with PolymerDomApi.

Upstreaming cl/275091781

And keep DomApiNative type compatible with PolymerDomApi.

Upstreaming cl/275091781
@aomarks
Copy link
Member

aomarks commented Oct 18, 2019

I think this should go to legacy-undefined-noBatch, since that's what Google tracks?

@kevinpschaaf
Copy link
Member

Either place... we're regularly merging master into legacy-undefined-noBatch.

@kevinpschaaf
Copy link
Member

Curious what was relying on node? It's basically an implementation detail of the PolymerDomAPI class (despite it not being prefixed), so it smells odd that something would reference it.

@rictic
Copy link
Contributor Author

rictic commented Oct 18, 2019

It looks like it's from a desire to unwrap a PolymerDomApi value back to its underlying dom value in order to pass it to a basic DOM handling API. Might have been totally based on a type error from the compiler and it may have worked fine at runtime, in which case maybe they should just cast the PolymerDomApi as a Node instead.

To check out the code, see http://cs/setPolymerNodeContent

@kevinpschaaf
Copy link
Member

@sorvell Can you review?

Copy link
Contributor

@sorvell sorvell left a comment

Choose a reason for hiding this comment

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

I think this is basically fine. The original intent was that this was private, but it was never marked so and it's not going to change at this point so it seems ok.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants