Coreify specific layout.js, CE, and BE functions #34810
Conversation
samouri
changed the title
|
Hey @jridgewell! These files were changed: |
| return true; | ||
| } | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Nice! More core! I think it would make sense for this whole file to live in src/core/dom/layout, with the only exception being the applyStaticLayout helpers that have dependencies on the experiment system
There was a problem hiding this comment.
Yes! But that requires changing 100s of files import paths and so I'd rather do it separately since my main goal is to unblock #34770
There was a problem hiding this comment.
If I understand correctly, this is only used in custom-element. What's the motivation for moving it into core, rather than closer to CE?
There was a problem hiding this comment.
Created #34818 to unblock any dependencies on layout; diff looks like 2ee75c4...cc4d48b excluding the import updates and actual moves
There was a problem hiding this comment.
Compiler will need to run it, and we don't want compiler to need an instance of CustomElement to run.
There was a problem hiding this comment.
Maybe just a helper in custom-element.js then?
| if (opt_replacedContent) { | ||
| element.classList.add('i-amphtml-replaced-content'); | ||
| } | ||
| applyFillContent(element, opt_replacedContent); |
There was a problem hiding this comment.
Would it make sense for applyFillContent to be defined locally in this file?
There was a problem hiding this comment.
Still relevant, since we don't really want other code using this instead of element.applyFillContent. Including it in core kinda implies it's fine, whereas no one will go out of their way to import it from here (except the compiler)
There was a problem hiding this comment.
Sure, I'm fine with that
|
This has been superseded by a few other PRs: #34818, #34858, and #34813 (comment) |
summary
Core-ifies specific functions needed for #34770.
The functions are:
getRealChildNodes,isInternalOrServiceNode, andapplyFillContentTurns out that the typing for the very old function
isInternalOrServiceNodehas been wrong this whole time.I wonder if our new type checking is more strict than it had originally been. Calling
node.tagNameandnode.hasAttributeis incorrect because aNodecould be a comment node or a text node. I fix that by adding a check for ELEMENT_NODE at the top.