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

Bento: Validate Facebook components #35395

Merged
merged 14 commits into from Aug 4, 2021

Conversation

caroqliu
Copy link
Contributor

@caroqliu caroqliu commented Jul 26, 2021

This PR introduces validations for the 1.0 versions of amp-facebook, amp-facebook-comments, amp-facebook-like, and amp-facebook-page, all of which are provided by the amp-facebook-1.0.js extension script.

In particular we want to guard for the following cases:

  • use of any of the amp-facebook(-*) tags is valid with inclusion of an amp-facebook-1.0.js script
  • use of any of the amp-facebook(-*) tags other than amp-facebook is invalid if only amp-facebook-0.1.js script is included (they must include their corresponding 0.1 script if not that amp-facebook-1.0.js script)
  • none of the amp-facebook-*-0.1.js extension scripts can be used on the same document as the amp-facebook-1.0.js script

Continuation from #35064 for the validator change discussions.

@amp-owners-bot
Copy link

amp-owners-bot bot commented Jul 26, 2021

Hey @ampproject/wg-caching! These files were changed:

extensions/amp-facebook-comments/0.1/test/validator-amp-facebook-comments-invalid.html
extensions/amp-facebook-comments/0.1/test/validator-amp-facebook-comments-invalid.out
extensions/amp-facebook-comments/0.1/test/validator-amp-facebook-comments.html
extensions/amp-facebook-comments/0.1/test/validator-amp-facebook-comments.out
extensions/amp-facebook-comments/validator-amp-facebook-comments.protoascii
extensions/amp-facebook-like/0.1/test/validator-amp-facebook-like-invalid.html
extensions/amp-facebook-like/0.1/test/validator-amp-facebook-like-invalid.out
extensions/amp-facebook-like/validator-amp-facebook-like.protoascii
extensions/amp-facebook-page/0.1/test/validator-amp-facebook-page-invalid.html
extensions/amp-facebook-page/0.1/test/validator-amp-facebook-page-invalid.out
extensions/amp-facebook-page/validator-amp-facebook-page.protoascii
extensions/amp-facebook/1.0/test/validator-amp-facebook-comments.html
+10 more

| layout="responsive"
| data-href="https://www.facebook.com/zuck/posts/10102593740125791">
| </amp-facebook>
| <!-- Example of a valid amp-facebook-comments -->
Copy link
Member

Choose a reason for hiding this comment

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

Do you intend for this to be valid? You may want to add the extension script in that case.

Same question for a few of the other tests below.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this example, amp-facebook-comments, amp-facebook-like, and amp-facebook-page are all registered by the one amp-facebook script included. As long as amp-facebook-1.0 is being used, all four components should have valid use. Is that possible?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For reference, this is what I was having trouble expressing in this PR:

  • The script inclusion is not exclusive after applying satisfies/excludes, as can be seen with the passing cases that should be failing in extensions/amp-facebook/1.0/test/validator-amp-facebook-exclusive.html
  • Use of the amp-facebook-* components is not valid with the amp-facebook-1.0.js script alone -- it appears to be running into the requires_extension line, i.e.:

    I assume there's not such a thing as requires_extension_oneof like we have with other properties? Example test file that should pass but fails: extensions/amp-facebook/1.0/test/validator-amp-facebook-page.out

Copy link
Member

@Gregable Gregable Jul 30, 2021

Choose a reason for hiding this comment

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

I think I see now. I'm not 100% sure this'll work without running the tests, but can you define two amp-facebook-comments tagspecs, one requiring each extension but otherwise identical?

To reduce duplication a tiny bit, you can use a named attr_list with all of the attrs in it which you then include in both tagspecs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for this recommendation! It looks like your recommendation, plus giving the 1.0 script a spec_name and requiring by that, did the trick for the second bullet point above (allowing amp-facebook-* to be used when importing amp-facebook:1.0). I added more tests to verify also that importing 0.1 does not work, but it helped me to notice that the secondary tag spec obscures the validation message for amp-facebook-*, which might normally recommend importing the script corresponding to the tag in use. Instead the invalid message shows:

The tag 'amp-facebook 1.0' is missing or incorrect, but required by 'amp-facebook-page'.

Copy link
Member

Choose a reason for hiding this comment

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

You'll need to give the different tagspecs spec_names now that there are more than one tag_spec for each of the tag names like amp-facebook-comments

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for this recommendation! Adding spec_name now suffices for the other bullet point above (exclusion between tags).

As for the "obscured message", the more I think about it, the more I settle on the perspective that it is WAI. In that case things are all set for review. :) Thank you again for all your patience and wisdom here 🙏

extensions/amp-facebook/validator-amp-facebook.protoascii Outdated Show resolved Hide resolved
@caroqliu caroqliu requested a review from Gregable July 30, 2021 13:39
Copy link
Member

@Gregable Gregable left a comment

Choose a reason for hiding this comment

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

Suggestion for a few comments to toss in, but otherwise looks good.

mandatory: true
}
requires: "amp-facebook-comments 0.1"
attr_lists: "amp-facebook"
Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest leaving a comment for the reader on where to find this list, since it's in a different file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

html_format: AMP
tag_name: "SCRIPT"
spec_name: "amp-facebook 1.0"
satisfies: "amp-facebook 1.0"
Copy link
Member

Choose a reason for hiding this comment

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

This would be a good place to leave a comment for the reader on what this scheme is trying to do, maybe even just linking to the discussion in this PR as sufficient. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea, linked this PR and a brief explanation.Thanks for the recommendation

@amp-bundle-size amp-bundle-size bot requested a review from samouri August 4, 2021 14:03
@caroqliu caroqliu merged commit b087dbd into ampproject:main Aug 4, 2021
@caroqliu caroqliu added this to Done in Bento Aug 9, 2021
@westonruter
Copy link
Member

After looking at how the changes here relate to the AMP-WP plugin, I have a question about how this might impact extension auto-importing. Namely, if someone adds a <amp-facebook-comments> to the page, given that the 0.1 and 1.0 versions look identical, how should extension auto-importing (e.g. in the Optimizers) know which version to include? For one, the amp-facebook-comments 0.1 script is required but for the other amp-facebook 1.0 script is required. It seems that currently in the Node.js Optimizer will end up importing one version depending on which occurs last in the spec: https://github.com/ampproject/amp-toolbox/blob/c4093bfb167de112de03752c8e6abe07ab92ea1b/packages/optimizer/lib/transformers/AutoExtensionImporter.js#L92-L103

@caroqliu
Copy link
Contributor Author

After looking at how the changes here relate to the AMP-WP plugin, I have a question about how this might impact extension auto-importing. Namely, if someone adds a <amp-facebook-comments> to the page, given that the 0.1 and 1.0 versions look identical, how should extension auto-importing (e.g. in the Optimizers) know which version to include? For one, the amp-facebook-comments 0.1 script is required but for the other amp-facebook 1.0 script is required. It seems that currently in the Node.js Optimizer will end up importing one version depending on which occurs last in the spec: https://github.com/ampproject/amp-toolbox/blob/c4093bfb167de112de03752c8e6abe07ab92ea1b/packages/optimizer/lib/transformers/AutoExtensionImporter.js#L92-L103

This is a good question. The amp-carousel versions 0.1 and 0.2 may set a useful example on what we should do here, or amp-next-page 0.1 and 1.0. Do you know whether the optimizer has accounted for these in the past? I suspect this may be one of the original use cases for us providing a -latest.js for components to use.

In terms of the qualitative difference between 0.1 and 1.0 for amp-facebook-comments in particular, the ideal behavior is likely subject to whether the document author intends to have a Bento document. I could imagine bento being a standalone option in the optimizer itself or an expansion of the autoExtensionImporter option.

Another consideration too is that the 1.0 version is still under experimental. Though the experiment is likely to be removed soon, in the immediate short term, I assume that would make 0.1 a safe default for the time being.

@westonruter
Copy link
Member

westonruter commented Aug 11, 2021

I think the difference between these Facebook components and amp-carousel/amp-next-page is that not only is there a version difference there is also a script requirement difference. As far as I know, this is the first time this has been the case. So it seems that what auto-extensions importers will have to do is remove from consideration any versions of the components that they don't want. For example, in the AMP plugin we're going to have a Bento opt-in experiment and when this is active we'll need to make sure that we exclude this spec:

tags: { # <amp-facebook-comments>
html_format: AMP
tag_name: "AMP-FACEBOOK-COMMENTS"
requires_extension: "amp-facebook-comments"
requires: "amp-facebook-comments 0.1"
# The amp-facebook attr_list is defined in the amp-facebook protoascii
attr_lists: "amp-facebook"
attr_lists: "extended-amp-global"
amp_layout: {
supported_layouts: FILL
supported_layouts: FIXED
supported_layouts: FIXED_HEIGHT
supported_layouts: FLEX_ITEM
supported_layouts: NODISPLAY
supported_layouts: RESPONSIVE
}
}

And only consider this one:

tags: { # <amp-facebook-comments> via amp-facebook script
html_format: AMP
spec_name: "amp-facebook-comments 1.0"
tag_name: "AMP-FACEBOOK-COMMENTS"
requires_extension: "amp-facebook"
requires: "amp-facebook 1.0"
attr_lists: "amp-facebook"
attr_lists: "extended-amp-global"
amp_layout: {
supported_layouts: FILL
supported_layouts: FIXED
supported_layouts: FIXED_HEIGHT
supported_layouts: FLEX_ITEM
supported_layouts: NODISPLAY
supported_layouts: RESPONSIVE
}
}

The metadata to do so seems a bit fuzzy however.

@westonruter
Copy link
Member

In short, we'll have to merge bundles.config.extensions.json with the validator spec data. We're doing that now to a degree, but we'll have to go further.

@honeybadgerdontcare
Copy link
Contributor

You're saying there needs to be more metadata to assist the Optimizer in doing this, right? Whether that be having another file that contains just the known metadata (e.g. when bento don't use this spec_name, use this one instead) or add a metadata identifier within the validator.proto to be used in the rules just for bento and for the optimizer (e.g. is_bento: true, defaults to false).

@westonruter
Copy link
Member

Right. Basically, when there are two different tag specs that look the same except they have differences in the required_extension, where one requires a Bento extension and another requires a non-Bento extension, this is where we need to tell the difference between the two.

I was able to work out a way to do so by using the requires and satisfies to link them together along with data from bundles.config.extensions.json (in not a terribly elegant way, but it works).

It seems it would be useful if there was an is_bento: true field added to the extension_spec:

tags: { # amp-facebook 1.0
html_format: AMP
tag_name: "SCRIPT"
# The 1.0 amp-facebook script registers all amp-facebook-* components.
# See https://github.com/ampproject/amphtml/pull/35395 for context.
spec_name: "amp-facebook 1.0"
satisfies: "amp-facebook 1.0"
excludes: "amp-facebook 0.1"
excludes: "amp-facebook-comments 0.1"
excludes: "amp-facebook-like 0.1"
excludes: "amp-facebook-page 0.1"
extension_spec: {
name: "amp-facebook"
version_name: "v1.0"
version: "1.0"
}
attr_lists: "common-extension-attrs"
}

This would prevent us from having to consult bundles.config.extensions.json, but then it would mean there'd be some duplication in the information across these two sources.

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

Successfully merging this pull request may close these issues.

None yet

6 participants