This issue doesn't have a category which makes it harder for us to keep track of it. @ericlindley-g Please add an appropriate category.

ampprojectbot on 5 Jun 2018

we need this feature urgently. when do you think you can release a version?

mofidsky on 11 Jul 2018

@mofidsky We're targeting release this quarter— @cathyxz, who is working on the implementation, may or may not be able to offer a better estimate.

We'd love to hear feedback when you're able to try it out—if you can share an examples of how you plan to use it that could help us make sure we're capturing relevant use cases.

ericlindley-g on 12 Jul 2018

@ericlindley-g We're trying to build a news web site so that contents are loaded when users scroll down, something like Facebook web site or Instagram app for instance.

mofidsky on 12 Jul 2018

@mofidsky — Thanks! That sounds like the general use-case we're building for.

I should note that amp-next-page supports infinite scroll for entire documents of content (as opposed to infinite scroll for elements within a single page), in case you're interested in that experience.

ericlindley-g on 12 Jul 2018

@ericlindley-g, @cathyxz We are also have a use case for this component on the product detail pages of our e-commerce aggregator. We compare offers from different merchants selling the same product, in the case of marketplaces they even have multiple offers of the same product. We allow the user to browse for the merchant/marketplace first and then drill-down into the respective offer. Right now we are pre-loading all the content into the HTML and just playing with the visibility, that bloats the HTML quite significantly though.

For an example, check out the following page: https://iprice.my/compare/apple-iphone-8/ and scroll to the "Compare Prices" section.

This is quite high in our backlog right now, happy to help in the development or testing of the component, let us know how we can contribute.

heiwen on 25 Oct 2018

My current approach is using the recursive template mustache. This template has 2 parts. First one for loop items, another one for next items. The next section consist a form which using this template again. Check the image bellow:

Im thinking if we add high trust event for amp-position-observer we will have real infinity scroll :).

buihoanghai on 25 Oct 2018

@buihoanghai We are working a first-class support for this. It is under development but you can give it a try experimentally ( not valid in Prod ) using amp-load-more experiment (sample: https://github.com/ampproject/amphtml/blob/master/test/manual/amp-list-load-more.amp.html )
ETA for launch is Dec/Jan.

We are not planning to make position-observer emit hight-trust events as scroll is not a strong user-interaction signal to be allowed to relayout the page.

aghassemi on 25 Oct 2018

👍3

Thanks @heiwen — I defer to @cathyxz if additional help would speed up the timeline here, but we appreciate the info on your use case either way

By the way — great AMP-first implementation of your site! It's awesome to see AMP used to build great experiences on the main version of a site like yours

ericlindley-g on 2 Nov 2018

@ericlindley-g Nice to see this feature is on the radar, is there anyway we can contribute and build this thing together to achieve infinite scroll to load more data like this along with Masonry / Waterfall layout like what pinterest is having ? we are looking forward to contribute and share the workload together, but with concern of not knowing what's the current state for these components and how to step in. Please advise.

/cc @cathyxz

leonalicious on 8 Nov 2018

Thanks for reaching out, @leonalicious — @cathyxz is in the best position to know if there are opportunities to contribute on this component, so I'll let her answer that aspect. My guess is that the most important place to contribute is in testing the component when it's feature complete and experimentally available, but @cathyxz may know of opportunities to contribute to the development itself.

ericlindley-g on 8 Nov 2018

👍1

It's experimentally available under amp-list-load-more, with an in-progress demo here. I'm trying to resolve the amp-list-resizable-children right now, and will be iterating on various corner cases for infinite scroll after that.

cathyxz on 8 Nov 2018

👍2 🎉1

It's experimentally available under amp-list-load-more, with an in-progress demo here. I'm trying to resolve the amp-list-resizable-children right now, and will be iterating on various corner cases for infinite scroll after that.

Cool, any timeline for the infinite scroll ? May I assist you ? which branch are you using for development of this feature ?

leonalicious on 12 Nov 2018

@cathyxz good day there ! it has been a while since we last heard the update from you, any progress / assistance I may offer please?

leonalicious on 19 Nov 2018

Hi @leonalicious !
The target launch date for this is going to be mid January. The main challenges remaining here are:

Building out enough examples to get a good coverage of potential use cases.
Handling loading state / end state / load failed states with the proper UI affordances (there's some debugging and UX tweaking still in progress here).
Checking compatibility (or at least non-breakability) with existing features like reset-on-refresh, refresh action, changing src via bind etc.
Cross browser / device QA.

I think what would be the most helpful here, would be help with building examples, testing, and feedback on our API. I can document what we have experimentally if you'd like to try it out and give us feedback.

For reference, this is what's being worked on from our burndown list:

[ ] Show buttons (overflow, load failed, etc.) underneath content instead of overlaid on top of content.
[ ] Implement reload (button) after loading failed (reuse overflow element).
[ ] Documentation
[ ] Add "load finished" element and gracefully handle end state (bookmark = null, empty array items, etc.)
[ ] Implement defaults for loading element, overflow element, load failed, load end elements
[ ] Examples / bugs / FRs for client/server-side filtering

cathyxz on 20 Nov 2018

👍3

Hey @cathyxz, nice work ! I have tried with the infinite Scroll example and it works like a charm. But one thing I realize it is something pure amp-list approach without amp-bind. Because of the complexity of some business use cases, there are some scenario might need to include params with amp-bind when fetching for data with infinite scroll based on user selection, do you think is it possible to have trigger an amp-formevent like form-filter.submit with amp-list's load-more property ? or any workaround to work amp-list infinite scroll with amp-bind please ?

Here is the example that requires to include variety of params while fetching data with amp-list

leonalicious on 3 Dec 2018

Hi @leonalicious ! Thanks for trying this out and for your thoughtful feedback. So here's what we're thinking on client-side and server-side filtering.

Server Side Filtering
The [src] component of amp-list will be bindable (as it already is), and you can bind that on button clicks to alter the [src] of the entire list. This would result in the amp-list deleting its current items and showing new items according to the filter. What we still need to do to make this work is primarily make sure that amp-list resizes correctly.
Client Side Filtering
This you can do by toggling CSS via amp-bind. Again, the main outstanding work here is to make sure resizing works correctly.

It seems like what you're trying to do here is change the next fetch url without changing the items currently within the list. What's happening with the implementation under the hood is basically I have a class variable loadMoreSrc_, that is being retrieved from the bookmark expression, and set as [src] for the next fetch.

Here are a few options that I'm thinking:

Make the bookmark url bindable. For example, add a load-more-next bindable attribute to amp-list. Let's say your json looks like:

{ ..., "next": "/api/search?a=1&b=2"}

You can bind [load-more-next] on amp-list entirely to change this to https://www.new.com/api/search2?a=4&b=5.

Split the bookmark url into base-url and params, make params bindable via [load-more-next-params]. For example, your JSON looks like:

{..., "next": "/api/search?", "params": "a=7&b=10" }

It seems like in most cases (correct me if wrong) that people mainly just want to change the parameters.

~I'm currently seeing this as a non-launch-blocking feature request, since I think technically this can be achieved with CSS-based client-side filtering, and would primarily serve as an optimisation for returning fewer (unnecessary) items from the server. Does that sound right to you?~

It seems like the filtering functionality (size, color, shipping, etc) can be achieved with server side filtering, but the sorting (e.g. Best Match, Price, etc.) would require something like what I described above, since it's basically a client-side sort and passing in a sortBy parameter to the server for all new fetches. It seems like that parameter would need to be bound.

EDITED

cathyxz on 3 Dec 2018

👍1

Hey @cathyxz , thank you for your clarification & sorry for the late reply, hmmmm, I personally think either splitting the params or not will not make much impacts, simply because the params returned from API should be simple, those params which are complicated are mainly based on user behavior, they should remains at client side. There, I am thinking lets keep it as simple as option 1 you mentioned earlier.

After understanding how this entire flow works, I think the most possible solution I would take is stated as below:

Provided I do have a amp-state which contains all the params:

js <amp-state id="refineState"> <script type="application/json"> { "categoryId": "", "minPrice": "", "maxPrice": "", "freeShipping": "", "onePiece": "", "pop": "", "shipFromCountry": "", "shipToCountry": "", "searchTags": "", "brandIds": "", "shoppingCoupon": "" } </script> </amp-state>

Based on your suggestion I think I will only be using load-more="auto" and bind the [src] of amp-list, by pointing the [src]='m.aliexpress.com/api/search?categoryId=123' + keys(refineState).map((filterParamKey, index) => '&' + filterParamKey + '=' + refineState[filterParamKey]).join('') , and everything should work by charms , thoughts?

Lastly, why should we bother and keep calculating the height of the amp-list ? cant we just set the height to something dynamic and let it be what it is based on its content ?

leonalicious on 13 Dec 2018

Someone knows how to fix this validation errors?
screen shot 2018-12-13 at 12 58 50

I'm working on a infinite scroll with amp, but so far I couldn't make any progress in validating my HTML with the infinite scroll.

LuisKrotz on 13 Dec 2018

😕1 👍1

Hi @LuisKrotz, amp-list-load-more is currently under experiment and not launched, so it won't validate. We're still working through it and may potentially make API changes at this point, so feel free to play with it, but note that it won't work in production until launch (approximate ETA is mid Jan).

cathyxz on 13 Dec 2018

👍1

Hi @leonalicious ! Thanks for your feedback. =)

Re: amp-list height calculation, I actually think this entire thing is easier with layout container, so you'll see that in this example I've added changeToLayoutContainer.

So the code that you referenced above would achieve server-side sort / filter, which is similar to the example that I have here: https://amp-infinite-scroll.glitch.me/bind.html.

My endpoint is obviously trivial (all it does is adjust the number of items / pages / latency for testing purposes), but basically so long as you can construct the endpoint you want via amp-bind, it will refresh the amp-list and add new data. All kinds of server-side sort, filter, pagination, etc. should work already out of the box.

I thought about your question a bit more, and I think the earlier options I proposed by making the next-url bindable don't actually help in this case. Using amp-state as src for <amp-list> will unfortunately not work with amp-list-load-more due to legacy reasons of what the using <amp-state> as src API looks like (the assumption is that said <amp-state> will be a JSON array, which precludes adding new fields). Thus, client-side sort and filter is possible via manipulating CSS, but unsupported via manipulating some state containing the actual items in the list.

In fact the idea of combining client-side sorting and filtering with load-more seems to have a fundamental UX problem. So let's say I search for "dress" and get back { "items": [...], "next": "/search?q=dress&offset=50&limit=50" }, and now I filter by colorred. If I alter mynexturl to besearch?q=dress&color=red&offset=50&limit=50`, then I get back the next 50 red items. But if now I want to change my color filter to blue, doesn't that mean that the previous 50 red items that I've gotten won't show up at all? The combination of client-side sorting with server-side sorting the next items, seems to be "lying" in a sense because you've sorted the client-side items locally, but your server-side sort is a global sort. So you could theoretically have local items [5, 8, 10, 12] and then get [1, 2, 3, 4] as your next items from the server.

So after thinking about this a bit, maybe it's better just to have a pure server-side sort + filter with a load-more list, since client-side sorting with load more would often be inconsistent.

Basically I'm thinking that what I proposed with https://github.com/ampproject/amphtml/issues/14060#issuecomment-443851560 is unnecessary since the bindable [src] attribute already enables server-side sort + filter. What are your thoughts?

Some more demos in case anyone wants to play with them:
https://amp-infinite-scroll.glitch.me/shop.html
https://amp-infinite-scroll.glitch.me/bad-url.html
You can also fork your own version of it from https://glitch.com/~amp-infinite-scroll.

cathyxz on 13 Dec 2018

❤1

Hey, sorry for the late reply, it took me some time to digest these ~

In fact the idea of combining client-side sorting and filtering with load-more seems to have a fundamental UX problem. So let's say I search for "dress" and get back { "items": [...], "next": "/search?q=dress&offset=50&limit=50" }, and now I filter by color red. If I alter my next url to be search?q=dress&color=red&offset=50&limit=50`, then I get back the next 50 red items. But if now I want to change my color filter to blue, doesn't that mean that the previous 50 red items that I've gotten won't show up at all? The combination of client-side sorting with server-side sorting the next items, seems to be "lying" in a sense because you've sorted the client-side items locally, but your server-side sort is a global sort. So you could theoretically have local items [5, 8, 10, 12] and then get [1, 2, 3, 4] as your next items from the server.

Sorry to say you are wrong, if buyers changed their search criteria, a new item list will be displayed start from 0. The item list should be accumulating only if buyer is searching more items based on the SAME filter criteria via amp-list-load-more OR click on View More button (basically the idea of Pagination)

I thought about your question a bit more, and I think the earlier options I proposed by making the next-url bindable don't actually help in this case. Using amp-state as src for will unfortunately not work with amp-list-load-more due to legacy reasons of what the using as src API looks like (the assumption is that said will be a JSON array, which precludes adding new fields). Thus, client-side sort and filter is possible via manipulating CSS, but unsupported via manipulating some state containing the actual items in the list.

does amp-list-load-more here refer to load-more='auto' here ? and also i dont get about the meaning of client-side sort and filter is possible via manipulating CSS, can you please provide me with some example ?

Basically I'm thinking that what I proposed with #14060 (comment) is unnecessary since the bindable [src] attribute already enables server-side sort + filter. What are your thoughts?

Agreed with you. That's why based on my understanding, I would only need load-more="auto" and bind the [src] of amp-list to the [src]='m.aliexpress.com/api/search?categoryId=123' + keys(refineState).map((filterParamKey) => '&' + filterParamKey + '=' + refineState[filterParamKey]).join('') , but based on this approach,

when the user triggers load-more="auto", a request will be sent out
when there is any AMP.setState event which changes one of the params of amp-state binds to the [src] of the amp-list, a request will be sent out as well

Am I understanding this right ?

leonalicious on 17 Dec 2018

ezgif-2-ecdc355f95d3 1

hey @cathyxz , sorry for the delay and I have tested it on our use case and it works! but throughout the development, I wanna to share some of my thoughts with you, listed as below:

Here is some little background, because of the complicated business requirements, we are maintaining 2 styles of CSS( List layout and Gallery layout) separately. In addition to it, we do have two separate amp-list for both List & Gallery. The purpose of doing this is simply we are displaying List layout to our users by default, and we do have a default [hidden] div container which wraps the amp-list of Gallery(because by default the div that wrap this amp-list is hidden, so amp-list of gallery will NOT be triggered and rendered the HTML elements) until users choose to switch from List to Gallery (change from [hidden] to display). By using this approach, because they are sharing the same [src] (which is referring to the same Array from amp-state), we do not have any performance issue.

However, if we are changing to infinite scroll, severals issue might start to appear. With infinite scroll enabled, we understand that the [src] might not able to refer an Array, it means, the [src] of both amp-list is actually referring to URL endpoint, and a separate request will be triggered if users change the layout from List to Gallery. So, we got no choice but have to merge this two amp-list into a single amp-list and render BOTH the HTML elements of List and Gallery by default no matter which layout the users is viewing by default.

Let us think a perfect solution to enhance this in the future.

I start to wonder and agreed with your previous assumption, is there any ways that we can append the variable we got returned from endpoint via load-more-bookmark be appended to [src] or src of amp-list ?
For instance,

amp-list layout="fill" items="." [src]='m.aliexpress.com/api/search?start=0' load-more="auto" load-more-bookmark="next"

the backend API only need to return the params as next as there is no ways the hosts will be changed

js { next: 'color=blue&size=S&start=20' //Please note start=20 will overwite the previous start=0 }
thoughts ?

leonalicious on 10 Jan 2019

@cathyxz Are we still to be expecting this release Mid-January? Currently validation fails while using this experimental feature.

trjones1 on 11 Jan 2019

The validation PR is here: https://github.com/ampproject/amphtml/pull/20094. It will be the second to last PR to merge (last PR will be turning on the experiment flag). Feature and bug-wise, I think we don't have anything launch-blocking left after https://github.com/ampproject/amphtml/pull/20230. But this is all subject to QA that we're currently doing as well as feedback from people on this thread. E.g. what @leonalicious mentioned above (which I will try to get to shortly).

Basically, if anyone following this thread has the bandwidth, I'd love to hear your feedback. So far, we're on track to get everything in by the canary cut on next Tuesday (this would imply a production launch on Jan 22).

cathyxz on 11 Jan 2019

hey @cathyxz, I do have a tiny issue that would need your help, basically, every time I triggered load-more, it will fetch the data from backend and wrap the new data with a new Root Element, it is possible to append the data back to the same parent instead please?

leonalicious on 27 Jan 2019

ezgif com-video-to-gif 5
and also there is another issue which is, eventhough I didnt scroll at the bottom edge of the amp-list, it was still been triggered and sent to fetch new request ...

leonalicious on 27 Jan 2019

Hi @leonalicious ! Thanks for your feedback!

Regarding triggering and fetching a new request. The current logic is to prefetch 3 viewports down, so if the bottom of the list is within three viewports, we will send out a new request. Ideally, the UX intention here is that short of network problems, the user should never see the bottom of the list until there are no more items. We can tweak this number, but it should try to prefetch before we actually reach the bottom of the list. There was a bug with this logic fairly recently, which should be fixed by https://github.com/ampproject/amphtml/pull/20332/files#diff-cb5b59ffc6c4d1ed0c99e9f2b5d748b6R1092.
Could you send over a gist with your <template> tag? What should happen here is that all new elements are appended to the <div role="list"> tag, which is a child of <amp-list>. What I'm seeing is that you've create a child element <div class="flex flex-wrap" role="list-item">, which is attached to the the <div role="list">. I think this is working as intended. <amp-list> will create elements per the <template> tag and append them to the <div role="list"> tag, so you can assume that all new data will be appended to <div role="list"> and style that as the parent, but you cannot append items to a different parent.

cathyxz on 28 Jan 2019

@cathyxz thank you for the response.
FYI, I did have the <div class="flex flex wrap"> element and have removed to try it, but the behaviors are still the same. A new <div role="listitem"> will alway be created upon each fetch.

leonalicious on 29 Jan 2019

@cathyxz cathy, thank you for your suggeston ! everything is working fine right after we have removed the single-item attribute from amp-list.

leonalicious on 31 Jan 2019

hey sorry @cathyxz , I still got few more questions,

I do configure my amp-list with load-more="auto", but sometimes I do see the load-more-button , not too sure when will this element be displayed

For your information, my load-more-bookmark="data.nextUrl", so when there are no more items returned from server side, we will set the field to be empty "", but seems like the scrolling will still continue and by using the data.nextUrl of the previous one (because the variable is set), any ideas how to stop the scrolling please ?

leonalicious on 1 Feb 2019

Great catch.

With load-more="auto", the element will be displayed in two cases:
a) It is the default state when loading has not yet been triggered. Usually, one should never see this UI unless the network speed is terrible or scrolling was too fast. The merits of this UI is open to debate, but what usually happens in this case is that when you reach the end of the list, the load-more button will flash before it turns into the loader.
b) Overflow is triggered. <amp-list> will refuse to resize if the bottom of the list is within the viewport AND it is not within the bottom 15% and bottom 1000px of the entire page. This will prevent infinite scroll from triggering. To avoid this condition, you can size amp-list to make sure that the bottom of amp-list is always outside of the viewport.

~This is probably a bug. I think it works if you set the field to null because that's what I've been testing on, but it's possible that this is a regression from my most recent fix. I will fix it.~ Fixed by https://github.com/ampproject/amphtml/pull/20647.

cathyxz on 1 Feb 2019

🎉1 👍1

In case people following missed the issue description update: This feature is available for origin trial per #20592 as of release #20587.

cathyxz on 4 Feb 2019

Happy Chinese New Year @cathyxz, thank you for your prompt reply, a few things I found out after the changes:

With the recent commit of height: calculation, it is causing quite some issues. We are using layout: fill for our amp-list (I tried layout:fixed-height & this approach works, but actually I prefer to make the height of content more flexible based on its content, without the calculation as there are some risks that calculation might go wrong)

a. layout:fill

b. layout:fixed-height, the height is not collapsed as I have filtered with new criteria
ezgif com-video-to-gif 7

c. layout:fixed-height, there are chances that fixed-height is not working, I believe there are some RACING behind the scene.

with AMP version 1902081532110, the infinite-scroll does stop, however, the SEE MORE button is still visible.

~~Tested with keyword: Ring, with minPrice: 30000 USD and scrolled only ONE time (20 items per scroll) out of 7 items in total.~~

There is max-height: calc(100% - 80px);, and this will cause some layout issue when we hit the bottom of the data. We notice this time around the Set More becomes invisible.

~~Tested with keyword: Ring, with minPrice: 12000 USD and scrolled THREE times (20 items per scroll) out of 49 items in total.~~

Lastly, FYI, demo https://amp-infinite-scroll.glitch.me/bind.html (AMP Version 1902020001320) is broken, the infinite-scroll continues even the data hits the bottom with data returned as null.

leonalicious on 11 Feb 2019

Hi @leonalicious, happy CNY!

A bit of context on the height: calc style: this was made in order to guarantee space for the load-more button. The static pixel value is calculated based on the height of the see-more button. The purpose here is to handle an edge case, where overflow is triggered and the see-more button serves as the overflow button. Per https://github.com/ampproject/amphtml/issues/14060#issuecomment-459840135, overflow is triggered when the height of the fetched contents exceed the height of the list and the bottom of the list is in the viewport.

Re: 1.a) layout="FILL" should work with amp-list-load-more, but it will become problematic if height ever gets overridden (i.e. overflow case mentioned above). I think you can fix this by specifying a min-height for the amp-list with layout fill. If you can specify a height that is guaranteed to exceed the bottom of the viewport, then you won't ever have this issue.

Re: 1.b) You can fix this with changeToLayoutContainer. Sadly, we couldn't get amp-list to shrink.

Re: 1.c) I think we're hitting the overflow condition again, but I can't triage this further without sample code to repro this with.

Re: 2) This seems to be working on https://amp-infinite-scroll.glitch.me/ with version 1902081532110.

Re: 3) This will leave some extra space--the same size as the see-more button. This was an implementation tradeoff that we made in order to guarantee that the load-more button would be visible in the overflow case. I might be able to do remove this after we get out of overflow state, but it will have to be there initially--I'll see what I can do here.

Sorry https://amp-infinite-scroll.glitch.me/ was a staging environment that was manually set to be latest master, and I did not keep this up to date with the most recent releases. It takes binaries from master, and therefore did not accurately reflect the releases. I've updated this to source from our CDN and they seem to be behaving correctly.

cathyxz on 14 Feb 2019

cool @cathyxz, I have changed the layout of my amp-list with layout='fixed-height' because seems like changeToLayoutContainer is not working with layout='fill'. Besides it, I have also implemented changeToLayoutContainer() on each AMP Bind before #19930 is supported.

FYI, after few rounds of testing, I found some other issues and listed as below:

Initially, it is working fine with infinite-scroll, but after I have intentionally changed the Refine Criteria and make the result returned empty, I found out the "See More" button is still displaying. And right after this, I changed the Refine Criteria back to normal, but infinite scroll seems not working anymore, and instead, it changed from infinite scroll to manually SEE MORE button.

ezgif-2-ce724b3a86b2

I think we are getting closed !

leonalicious on 14 Feb 2019

Okay I think there are two different issues here, which I'm approximating using this demo.

Returning empty items with no next-url shows the See More button. This is a bug in amp-list-load-more (fixed by https://github.com/ampproject/amphtml/pull/20871).
Changing src after no next-url or empty items changes infinite scroll to manual see more. ~I tried to repro this by setting the endpoint to 0 items with 0 pages left (successfully repro-ed bug 1 above) and then setting the endpoint to something reasonable (e.g. 5 items, 5 pages). I'm noticing that if I set it to something like 2 items, it will show the see more button because there is nothing to scroll (load-more is triggered on the scroll action). But if it's set to something like 6+ items, it will load more items on scroll.~ This is probably an issue with the viewport change event triggering a null check because the <amp-list> contains no items (fixed by https://github.com/ampproject/amphtml/pull/20871).

Thank you for your help and patience!

cathyxz on 14 Feb 2019

👍1

hey @cathyxz , thank you for the fixed ! yes , right now the 2 issues we mentioned before have been resolved with version 1902191749350, however, it introduces another issue, we did not encounter this issue with version 1902151859190.

ezgif com-video-to-gif 6

I personally think it is somehow related to the overflow triggered , what do you think ?

leonalicious on 21 Feb 2019

Yup it is, @leonalicious. Aside from the JS console warning, does it break the page or otherwise interfere with functionality in any way? It should be an innocuous warning, since we provide the see-more-button element which also serves as overflow.

EDIT:
Oh I see. I think you are talking about this issue, but feel free to correct me if I'm wrong.

It still shows a see-more button instead of going directly into infinite scroll. In an ideal world, it would go directly into infinite scroll mode. Yeah, there is unfortunately not a whole lot you can do about this case. So basically, the way I get this case to happen in my local demo is I scroll down and trigger one infinite scroll, but I get to the bottom of the page before my infinite scroll loads and therefore hit the overflow conditions (bottom of list is within viewport AND it is not within 15% or 200px of the page bottom). Basically, if you click the see more button at this point, it will go back to infinite scroll and never trigger again. If you can guarantee that your initial list is long enough (or the contents after your list are short enough) so that the bottom of the list is always within 15% / 200px of the page bottom, this case should never trigger.

But I think this has always been present in amp-list-load-more because it's a hard constraint of the overflow / resize restriction that we have in AMP, and so should not be a regression in 1902191749350.

So to clarify, this is the expected behavior:

If overflow is triggered, the amp-list will resize itself to make space for the see-more-button element and the see-more-button element will be shown. This should disable scrolling to fetch because in this state, the amp-list cannot be resized. If you click on the see-more-button, it should fetch the next batch of items and subsequent infinite-scrolling should work as intended.

This is the triggering condition:
Overflow won't always trigger. <amp-list> will refuse to resize if the bottom of the list is NOT within the bottom 15% OR bottom 1000px of the entire page (basically if elementNearBottom_ returns false) . This will prevent infinite scroll from triggering.
In context of infinite scroll, it can happen two times.

On the first fetch, if the initial list is shorter than the page.
On the second fetch, if we scroll to the bottom of the page (which puts the bottom of the list in the viewport) before the items have returned.

I previously thought that case 2 is not very common, but I guess if your server endpoint or network is slow, it can actually be very common. I can think about how to solve this properly. In the meantime, the workaround is just to make sure that the bottom of your list is within 15% of the bottom of your page.

cathyxz on 21 Feb 2019

👍1

Based on UX feedback, I think the overflow behavior is working as intended. /cc @andrewwatterson

cathyxz on 23 Feb 2019

@cathyxz we noticed an issue perhaps with iPhone and infinite scrolling.

In development load more works fine for me (windows/chrome) however when I make a push to our QA servers, we never get to load any of the additional pages.

I have been able to replicate this on the example that you've provided.
https://amp-infinite-scroll.glitch.me/

This was tested on an iPhone X, iOS version 12.1.4

Please advise, as we are planning on taking this live very soon. I was previously using the experimental version of this feature using <div load-more-loading> until today when I implemented the official <amp-list-load-more> syntax.

The experimental version worked, but does not pass the AMP validation (and therefore caching) due to added JS for opting in.

PS - On my IT Director's Samsung Galaxy S9+, our paging worked just fine. Also on my coworker's Samsung Galaxy S9+, it did not work, neither did the demo you've provided.

iPhone Test:

Coworker's S9+ test.
S9 Test

trjones1 on 6 Mar 2019

Hi @trjones1, thanks for reporting. I've taken a look, and the demo operates correctly in a browser (tested on Safari iOS X) when I have the amp-list-load-more experiment enabled via the experiments page. Because the feature is experimental, users have to opt their browsers into the experiment in order to turn it on. My demo page is also https-only (I get the same error if I navigate to it in http). Without an origin trial token, pages using experimental features aren't valid AMP. Since the demo on glitch is showing unable to load more, which is the load-failed-element, this likely means that the load-more url returned a 404. I suspect it is because the page was loaded in http. If not, could you send a screenshot of your js console or network tab when this happens?

If this happens on your deployed website, I would double check that your cors setup is correct. See https://www.ampproject.org/docs/fundamentals/amp-cors-requests for specifics.

cathyxz on 6 Mar 2019

Thanks, @cathyxz - you're right. I visited the site via http on my phone and that reproduced the error.

I'm unable to make this work on our website when not using the experimental features. I am using the following markup:
<amp-list-load-more load-more-loading>Loading more </amp-list-load-more>
<amp-list-load-more load-more-end>No more products to show...</amp-list-load-more>
<amp-list-load-more load-more-button class="hide">Click here to see more...</amp-list-load-more>
<amp-list-load-more load-more-failed>Failed to load more...</amp-list-load-more>

However, with experimental features turned on, and using the following markup, it works:
<div load-more-loading>Loading more styles...</div>
<div load-more-button class="hide">Click here to see more...</div>
<div load-more-failed>Something went wrong...</div>

The unfortunate news is, the latter option makes us fail AMP validation - due to having javascript load when we opt in for the experimental features:

<meta name="amp-experiments-opt-in" content="amp-list-load-more">
<script>
(self.AMP=self.AMP||[]).push(function(AMP){
AMP.toggleExperiment('amp-list-load-more', true);
AMP.toggleExperiment('amp-list-resizable-children', true);
});
</script>

Non-Experimental works on my development machine too! (visiting the deployed website) So I cannot really give you a screenshot of my network tab since everything works. It happens strictly on device for me.

I can PM you the dev site link if you'd like to observe for yourself.

trjones1 on 7 Mar 2019

@cathyxz You get the same issue I do when it comes to passing validation:

Does this prevent the page from being entered into the Google AMP Cache? Will we not have a thunderbolt as a result?

Thanks again.

trjones1 on 7 Mar 2019

Yup @trjones1. You need an origin trial token (specific to your domain) to be able to launch this in valid AMP. Can you ping me on slack (czhu)?

cathyxz on 7 Mar 2019

So for anyone else who'd like to give this a try, the origin trial enrolment form is here.
/cc @nainar

cathyxz on 7 Mar 2019

@cathyxz Good News Cathy, we have finally gone online with Infinite scroll last week, and have steadily increased the traffic to 50% up to today date, seems everything is so cool! thank you for the effort and hard work, cheers !

leonalicious on 11 Mar 2019

Thank you @leonalicious for working with us through this 47-comment-long thread and helping us iron out all the bugs!

cathyxz on 11 Mar 2019

👍1

Just a heads up to everyone waiting for an origin trial token, we're launching this with #21355. If you want to use it, just keep track of the release issues to see when #21355 makes it to production.

cathyxz on 14 Mar 2019

@cathyxz Sorry for bothering you again. This time, I want to ask if I can got the amp-list response outside the tag. I tried to get it by id, but it does not work. I just do not want to request for the second time in the same page.

clodisewp on 15 Mar 2019

Hi @clodisewp, sorry but your question is a bit ambiguous, and I'd rather not waste cycles making poor guesses at what you're trying to ask. Just in case this is related to using amp-state as a src for amp-list and the fact that currently two XHRs are being made, there is currently an open FR and design discussion here https://github.com/ampproject/amphtml/issues/20752.

If your question here is also not a bug or a feature request, is there any chance you could ask your question on stackoverflow and link to it in our slack channel? I think that's a much better avenue for getting questions answered on how to use AMP components (others with the same question will also benefit), and people will likely respond to you faster there too. =)

cathyxz on 19 Mar 2019

Hi @clodisewp, sorry but your question is a bit ambiguous, and I'd rather not waste cycles making poor guesses at what you're trying to ask. Just in case this is related to using amp-state as a src for amp-list and the fact that currently two XHRs are being made, there is currently an open FR and design discussion here #20752.

If your question here is also not a bug or a feature request, is there any chance you could ask your question on stackoverflow and link to it in our slack channel? I think that's a much better avenue for getting questions answered on how to use AMP components (others with the same question will also benefit), and people will likely respond to you faster there too. =)

@cathyxz Sorry for my poor English.
The open FR #20752 is not what I need, and stackoverflow is an oversea website for me.
Now I describe my question with text and imge:

The following is the json in one request:

This is the data distribution:

You can see the place B is outside of amp-list. Is there any solution for this problem under the conditon of only one request?
Thanks!

clodisewp on 19 Mar 2019

Hi @cathyxz
With dev-channel version 1903191703470, visit this page.
Scroll down to Personal Flow Part(below 15 Baby & Kids), click view-more.
The height of amp-list is wrong just like below.
Screen Shot 2019-03-21 at 6 09 03 PM

Because this issue cannot be reproduced with prd version 1903141753530.
So I suppose this issue is not caused by wrong implementation?

xiaotong-kk9 on 21 Mar 2019

Hi @xiaotong-kk9,

Based on a quick look, I think this is caused by hitting our overflow condition. So note that if the bottom of your list is at the bottom of the viewport when you click the load-more button (i.e. move your view more button close to the bottom of your viewport), it will resize correctly. However, if there is significant space in the viewport below your amp-list, it will refuse to resize and push the content below it out of the viewport. I think you are running into the overflow condition discussed in https://github.com/ampproject/amphtml/issues/14060#issuecomment-466099859 (workarounds are in this thread and above).

I haven't diff-ed this against 1903141753530 yet but I think this behavior is expected given current constraints.

cathyxz on 21 Mar 2019

21355 is now in production.

cathyxz on 27 Mar 2019

🎉5 👍2 🚀1 ❤1

@cathyxz Since amp-next-page is still experimental, my company decided to experiment with element-level infinite scroll to incorporate infinite scrolling for articles. I think we got it working on staging, but we're wondering if this violates any AMP rules. Just wanna make sure our pages still index as AMP on search.

Can you please verify that using amp-list for entire AMP articles won't cause us any issues approval-wise?

Pkmmte on 11 Apr 2019

So this feature is now launched, hence any pages using it will be valid AMP, and will index in Search as AMP. However, note that this feature wasn't designed with loading more articles in mind, so its definitely possible that you might run into issues implementation-wise (I currently can't think of a great way to make the code for your use case look very clean...). On the whether this is a good idea question or goes against any AMP best practices, I defer to @nainar.

cathyxz on 11 Apr 2019

Hi @Pkmmte what are the use cases you are trying to solve for document level infinite scroll?
For e.g. what analytics support do you need? Are you able to change the URL as the user scrolls into the next article?

nainar on 11 Apr 2019

@nainar We run an editorial website, and I'm trying to surface a new articles after a user has finished reading the original article without them having to click on any suggestions.

We weren't able to change the URL as the user scrolls, but I ended up using an amp-iframe for the article body anyway, given HTML limitations with amp-mustache. The amp-iframe source is an exact copy of the AMP page, but with a special parameter (?onlyBody=true) to let the server know to only render the article body, but still log it as an analytics page view.

Everything is working as intended on our staging server right now for the most part. It was a bit hacky, but it accomplishes our primary goal. It passed the AMP Validator test, too. We just want to know if we'll get punished by Google for using amp-list in a way that it was not intended for, such as this.

I can provide more details in a private email, if necessary.

Pkmmte on 11 Apr 2019

@nainar Any further clarification on this?

Pkmmte on 15 Apr 2019

Amphtml: [Master feature] Element-level infinite scroll

Update

Related demos

Related issues

19502

Related PRs

Most helpful comment

21355 is now in production.

All 60 comments

21355 is now in production.

Related issues