Skip to content

Add unit tests for amp-layout#35157

Merged
samouri merged 3 commits intoampproject:mainfrom
samouri:test-layout
Jul 8, 2021
Merged

Add unit tests for amp-layout#35157
samouri merged 3 commits intoampproject:mainfrom
samouri:test-layout

Conversation

@samouri
Copy link
Copy Markdown
Member

@samouri samouri commented Jul 8, 2021

summary
Adds two basic unit tests for <amp-layout>.
The second test in particular would have caught #35154

@samouri samouri self-assigned this Jul 8, 2021
@samouri samouri requested a review from processprocess July 8, 2021 19:24
@samouri samouri requested a review from rcebulko July 8, 2021 19:26
@samouri samouri marked this pull request as ready for review July 8, 2021 19:27
import {createElementWithAttributes} from '#core/dom';
import {Layout} from '#core/dom/layout';

describes.realWin('amp-layout', {amp: true}, (env) => {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can we move this to test/unit/builtins/test-amp-layout to mirror the tree structure?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I was thinking the same.
Need to move all 3 builtins though, so figured i should leave it for a followup.

'amp-layout',
attrs
);
ampLayout.innerHTML = innerHTML;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

fyi, the more common way unit tests normally set up dom is with htmlFor:

const element = html`
<amp-iframe src="https://www.wikipedia.org"></amp-iframe>
`;
doc.body.appendChild(element);

Copy link
Copy Markdown
Member Author

@samouri samouri Jul 8, 2021

Choose a reason for hiding this comment

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

Sorry if this is obvious...but can you speak to the benefit of htmlFor vs. innerHTML?

Copy link
Copy Markdown
Contributor

@caroqliu caroqliu Jul 9, 2021

Choose a reason for hiding this comment

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

Good question! It's one of those things that has a bit of that "we've always done it this way" bias, so it's good you're asking.

Component unit tests tend to prefer htmlFor for static DOM that's even the slightest more complicated than single node, otherwise DOM APIs are preferred next. There's a stronger guarantee over innerHtml in both of those approaches that the markup your inserting is well formed, plus you also get auto formatting for html blocks.

In this specific test, things could be more readable by using htmlFor as well:

const ampLayout = html `
  <amp-layout layout="fixed" width="100" height="100">
    <span>hello</span>
    <span>world</span>
  </amp-layout>
`

I personally tend to avoid innerHtml whenever there are other tools to accomplish the same goal, and often recommend the same for others, but it's not a hard and fast rule. There is rarely a benefit that I've seen to using it, and avoiding it is more critical in production code particularly in cases where XSS or performance may be a concern, but here it's more of a stylistic choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants