[$60] - Replace "Load More" with infinite scroll

[ajefts]

On Challenges/Contests (https://www.topcoder.com/my-challenges/?status=completed), after first "Load More," we should switch to infinite scroll, as we do on Member Search

[talesforce]

@ajefts - This is included as part of https://www.topcoder.com/direct/contest/detail?projectId=30056070 that has been launched today

[birdofpreyru]

Expected Fixes

1. The infinite scrolling of challenges has been implemented at https://www.topcoder.com/my-challenges/?status=completed already, but needs several enhancements:
   1. As of now, the loading of an additional portion of the past challenges is triggered when the user scrolls to the very end of the currently rendered page. I should be triggered earlier, when the last one or two (make it easily configurable via a constant) rows of already loaded challenge cards appear in the viewport.
   2. Now, when I first load the page, I see 14 challenges loaded. When I reach the end of the page, 24 more challenges are loaded. The same amount of challenges should be pre-loaded, and then loaded each time. The actual number should be easily configurable via a constant.
   3. The original problem still persists at the page with the listing of past challenges in a specific track, e.g. https://www.topcoder.com/members/birdofpreyru/details/?track=DEVELOP&subTrack=CODE&tab=challenges That listing page should be modified in the same way, to implement the infinite scrolling.
   4. When the loading of an additional portion of challenges is triggered, the loading indicator should be shown in the bottom of the page. It should look the same, as the current LOAD MORE button at https://www.topcoder.com/members/birdofpreyru/details/?track=DEVELOP&subTrack=CODE&tab=challenges, but it should read LOADING and have a rotating spinner after the label. Sure, the loading indicator should disappear once the new portion of challenges is loaded.

[mhikeo]

@birdofpreyru I'd like to take up this ticket. Thanks.

[birdofpreyru]

@mhikeo You have it :)

[mhikeo]

@birdofpreyru Which user has enough data to test?

[birdofpreyru]

@mhikeo If you can configure it to work against production database, then my profile has enough challenges in the history to test it.

[birdofpreyru]

@mhikeo Any update on this?

[mhikeo]

@birdofpreyru I'm releasing this for others to have a look.

[shubhendusaurabh]

@birdofpreyru For loading more indicator is it ok to use ripple effect currently being used other pages? Styling would feel more consistent then.
What no of challenges should be loaded each time? 12? 16?

[birdofpreyru]

@shubhendusaurabh If you feel that it looks nice, and more consistent with other places in the site, them I am totally agree for it. My line of thinking is: if scrolling down you reach the end, and you immediately notice that indicator, thus not trying to scroll further when you are supposed to wait, then we are fine. If in that place this indicator is not the first thing, which catches your eyes, then add Loading more label next to it, styled the way it fits the place.

What no of challenges should be loaded each time? 12? 16?

I'll tell you once I play with the result :-D For now, let it be 12, just declare this number like a CHALLENGES_LOADING_CHUNK constant in the beginning of the corresponding .js file, and place around some comments, that this is the section of code, where all similar constants should be declared, and what does this one, in particular, controls.

[shubhendusaurabh]

This is what i meant.

[birdofpreyru]

@sumansaurabh This looks fine. With this one, probably, no need for labels.

[birdofpreyru]

@shubhendusaurabh Ok. I accept this one, but still want to comment, that there is a flaw in your implementation (which has no impact now, but it will eventually).

You use the INFINITE_SCROLL_OFFSET constant as the fixed offset from the page's bottom to the control point, where you trigger the loading of the next chunk of challenges into the list. This relies on footer's height being constant, which is not true because (1) the footer may be changed through development, and the person who change it, surely will forget to update your INFINITE_SCROLL_OFFSET constant; (2) the footer's layout may (and will) become responsive to the page width, thus its height will change if you resize the window, and your implementation does not take it into account.

Thus, the perfect implementation should measure the offset from the bottom of the challenge listing container, so that it does not care about the layout and size of surrounding page elements. Though, as it does not have an impact now, I accept your solution and close the issue. We'll come back to this, once we start having problems with it.