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
Create amp-carousel 0.2 based on amp-base-carousel #23393
Conversation
- Uses amp-base-carousel's implementation, with the amp-carousel API / styling.
- Fix race condition with reset window position and scroll.
7201324
to
20826cd
Compare
@alanorozco If you don't have the bandwidth to review this, feel free to re-assign. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass
@@ -270,7 +270,7 @@ exports.extensionBundles = [ | |||
}, | |||
{ | |||
name: 'amp-carousel', | |||
version: '0.1', | |||
version: ['0.1', '0.2'], | |||
latestVersion: '0.1', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What effect does it have adding 0.2
but leaving latestVersion: '0.1'
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest version is what amp-carousel-latest
will point at, which is 0.1
. The background to this field is that we originally had amp-base-carousel
as 0.2
, but it had an incompatible API and was under experiment, which broke people relying on "latest". It was decided that the latestVersion
would be locked at the existing latest version at the time of the change for all extensions, and that we would deprecate the usage so we didn't break people again in the future.
/** | ||
* @private | ||
*/ | ||
setupActions_() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it's unusual to have a private method before the constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its something I am trying out and also trying it out for amp-stream-gallery, which I will send out later: https://github.com/sparhami/amphtml/blob/9634040f99658bb2651b5d3a48c58fd9c97b66a3/extensions/amp-stream-gallery/0.1/amp-stream-gallery.js#L53-L128
The thinking is that actions and attributes are the public API of the component, and usually the first thing I want to see in the file to figure out what it does. I can move this down for now, but there may be some way to make this less awkward. Any thoughts?
} | ||
|
||
/** | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: add descriptive comment.
This happens to me so often when I just want the red lines to go away 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops! Added comments and renamed these methods.
* } | ||
* ``` | ||
*/ | ||
export class ChildLayoutManager { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed because Layers hasn't launched yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. When layers is ready, we might either take this away, or perhaps figure out if there is some value to having a carousel specific implementation (are there cases where we know what to do better than layers, which is more general?).
I think one (not very common, but possible) case is if you are say on the first slide and want to go to the nth slide (either by clicking a pagination dot, or some programmatic action). Since we smooth scroll, layers and this code will possibly (likely) load may slides along the way.
We could be a bit smarter and say to not load any slides along the way, and only load the destination slide.
Another possible difference is that we may not want to unlayout slides (or defer it) in case a user wants to go back and forth through a carousel. Currently, I believe runtime will unlayout things that exit the extended viewport area. This code does the same for now.
This actually differs from how carousel 0.1 works, which never does unlayout on slides (though it does display: none
them).
* @private | ||
*/ | ||
setupActions_() { | ||
this.registerAction( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you help me understand the difference between <amp-base-carousel>
and <amp-carousel>
0.2? I see that it imports the Carousel
class from amp-base-carousel but the AMP element amp-base-carousel is still around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. <amp-carousel>
0.2 is an almost exactly API compatible replacement for 0.1, with a minor breaking change on how arrow buttons are laid out (as far as I know, that should be the only breaking change, there could be more).
<amp-base-carousel>
has a different API and way of doing things that makes the API considerably different. For example, the way that the equivalent type="carousel"
is handled is quite different.
The idea here is that they can share an internal implementation, which fixes a lot of outstanding issues with amp-carousel
without requiring developers to do too much work to figure out how to make <amp-base-carousel>
work for their use case.
In the longer term, we think most developers will want to use the amp-stream-gallery
and amp-inline-gallery
components, with amp-base-carousel
serving as a building block.
I did consider actually instantiating an <amp-base-carousel>
internally here, but wasn't sure if that was a good idea for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM smash that merge button
* cl/262363476 Add width and height attributes to the svg SYMBOL tag validation rules. * cl/262384419 Revision bump for #23406 * cl/262398573 Revision bump for #23393 * cl/262415464 Add devmode validation logic. * cl/262420139 s/amphtml-dev-mode/ampdevmode/ in our error strings. * cl/262430869 Convert python scripts to be python3 compatible. * cl/262440817 Revision bump for #23800 * cl/262442134 Revision bump for #23826
The main goal of this PR is to create a mostly API compatible update to `<amp-carousel>`, addressing numerous bugs. This is not strictly API compatible due to how the arrow buttons are positioned to allow automatic flipping in RTL. This uses the same DOM structure as amp-carousel as far as slides and their classes are concerned for both `type="slides"` and `type="carousel"`. This maintains the API of the existing carousel. This does not add support for media queries in attributes, handling updating the slides or any other features of `<amp-base-carousel>`. - Fix a bad usage of `clamp` - Rename some base carousel classes to not clash - Make scrollbar hiding optional, as `type="carousel"` does not hide the scrollbar - Use `setOwner` for managing when to schedule layout for children - Use `IntersectionObserver` to determine when to layout/unlayout/pause/resume slides * This is mostly important for `type="carousel"`, where slides can be of mixed length, and we cannot rely on the current index to tell when to actually layout adjacent slides * If IntersectionObserver is not supported, this currently skips `setOwner` and just relies on the runtime - Fix arrow button hiding when at the start/end for RTL - Fix bug where if you touch/wheel scrolled exactly when the scroll position was being reset, the current index would not be reported correctly
* cl/262363476 Add width and height attributes to the svg SYMBOL tag validation rules. * cl/262384419 Revision bump for ampproject#23406 * cl/262398573 Revision bump for ampproject#23393 * cl/262415464 Add devmode validation logic. * cl/262420139 s/amphtml-dev-mode/ampdevmode/ in our error strings. * cl/262430869 Convert python scripts to be python3 compatible. * cl/262440817 Revision bump for ampproject#23800 * cl/262442134 Revision bump for ampproject#23826
The main goal of this PR is to create a mostly API compatible update to
<amp-carousel>
, addressing numerous bugs. This is not strictly API compatible due to how the arrow buttons are positioned to allow automatic flipping in RTL.This uses the same DOM structure as amp-carousel as far as slides and their classes are concerned for both
type="slides"
andtype="carousel"
. This maintains the API of the existing carousel. This does not add support for media queries in attributes, handling updating the slides or any other features of<amp-base-carousel>
.clamp
type="carousel"
does not hide the scrollbarsetAsowner
for managing when to schedule layout for childrenIntersectionObserver
to determine when to layout/unlayout/pause/resume slidestype="carousel"
, where slides can be of mixed length, and we cannot rely on the current index to tell when to actually layout adjacent slidessetAsOwner
and just relies on the runtimeWill add some e2e tests in a subsequent PR to keep this from growing too large. Also, once we are comfortable with the state of the component, docs/examples can be updated to point to 0.2.