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

Infinite scroll in Media #562

Merged
merged 9 commits into from
Mar 17, 2020
Merged

Infinite scroll in Media #562

merged 9 commits into from
Mar 17, 2020

Conversation

merapi
Copy link
Contributor

@merapi merapi commented Mar 12, 2020

This adds infinite scroll to the Media gallery (#23).

Next steps (can be included in this PR):

  1. Lazy load images - right now we have loading="lazy" which works in Chrome/Edge, soon FF, we can utilize IntersectionObserver to build our own solution.
    This solution loads as many pages as needed to fill the whole viewport. For example with per_page=2 and rootMargin: 400px it will load ~10 pages to fill the viewport and then load one row (2 images) as you start scrolling down - not sure if it's useful but it's there "for free" (for per_page=100 it will load 100 one time - as expected in AC).

  2. Keyboard support - be able to see all images with arrows.

  3. UX, loading states.

@spacedmonkey
Copy link
Contributor

This branch needs to be rebased.

@spacedmonkey
Copy link
Contributor

I like that after upload, the view reset and scrolls to the top 👍

Copy link
Contributor

@spacedmonkey spacedmonkey left a comment

Choose a reason for hiding this comment

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

One small tweak and a question, but otherwise, we are looking good.

@merapi merapi requested a review from miina as a code owner March 13, 2020 15:05
@merapi
Copy link
Contributor Author

merapi commented Mar 13, 2020

One small tweak and a question, but otherwise, we are looking good.

Done, I think we can merge it and work from there.

@googlebot
Copy link

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@spacedmonkey
Copy link
Contributor

@googlebot I consent.

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@github-actions
Copy link
Contributor

github-actions bot commented Mar 13, 2020

Size Change: +933 B (0%)

Total Size: 414 kB

Filename Size Change
assets/js/edit-story.js 361 kB +933 B (0%)
ℹ️ View Unchanged
Filename Size Change
assets/css/edit-story.css 225 B 0 B
assets/css/stories-dashboard.css 165 B 0 B
assets/js/stories-dashboard.js 53.4 kB 0 B

compressed-size-action

@miina
Copy link
Contributor

miina commented Mar 13, 2020

Is this fixing #23? Or #247?

(Edit: just saw that should be 23 based on the branch name, mind adding it to description as well?)

@miina
Copy link
Contributor

miina commented Mar 13, 2020

@merapi I'm getting a console error and the editor is breaking:
Screenshot 2020-03-13 at 17 32 44

Wanted to test before reviewing, does it work for you?

@merapi merapi linked an issue Mar 13, 2020 that may be closed by this pull request
@spacedmonkey
Copy link
Contributor

I am not seeing the console errors.

@spacedmonkey
Copy link
Contributor

Please use the keyword fixes #23 to denote which issue this is linked.

Also make sure to ticket to code review and assign some other devs.

@spacedmonkey
Copy link
Contributor

This PR needs to be merge into master. Much has changed in media.

assets/src/edit-story/app/api/apiProvider.js Outdated Show resolved Hide resolved
assets/src/edit-story/app/api/apiProvider.js Outdated Show resolved Hide resolved
assets/src/edit-story/app/media/mediaProvider.js Outdated Show resolved Hide resolved
mediaType,
};
}

case types.SET_PAGE: {
Copy link
Contributor

Choose a reason for hiding this comment

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

Pls clarify: what does the SET_PAGE do comparing to the FETCH_MEDIA_SUCCESS? Is this request-vs-response data? That'd seem dangerous to conflate them into a single property, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We now just have SET_NEXT_PAGE.

{resources
.filter((_, index) => isEven(index))
.map((resource, i) => (
<MediaElement
Copy link
Contributor

Choose a reason for hiding this comment

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

My first reaction to this is that, most like loading=lazy will no longer suffice here. Both because it's not well supported, and also because we'd likely want to add more logic to visible vs not visible state. It's definitely fine to do this over several pull requests, of course. To highlight here: much of the performance tradeoffs will come from the <video> where we have more granularity: we can load the video, or just metadata, etc.

And looking at the current MediaElement, this would also improve the structure of that component(s). For instance, we can split it into two tiers: MediaElementWrapper that takes care of the sizing, focus, hover, etc. And a type-specific Preview component that's only rendered when the element is "visible" and can use system resources as it sees fit. This would also make a good place to deal with "poster backfill" and any such issue.

if (!hasMore) return;
if (!entry.isIntersecting) return;

setPage({ page: page + 1 });
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking more into the use here, I don't see why we need both page and setPage. I think if we instead introduce loadNextPage() method in our context, it'd solve all of these nits: we won't be leaking bulk of the API and the meaning of this will be very clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agree, but I would call it setNextPage because it doesn't load the next page by itself.

@merapi merapi force-pushed the feature/23-infinite-scroll branch from 16d3ef5 to 5d7fb0d Compare March 16, 2020 23:11
@merapi merapi requested a review from dvoytenko March 16, 2020 23:13
Copy link
Contributor

@spacedmonkey spacedmonkey left a comment

Choose a reason for hiding this comment

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

This looks good. 👍

@spacedmonkey spacedmonkey merged commit 53c4622 into master Mar 17, 2020
@spacedmonkey spacedmonkey deleted the feature/23-infinite-scroll branch March 17, 2020 12:54
@swissspidy swissspidy added the Type: Enhancement New feature or improvement of an existing feature label Mar 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement New feature or improvement of an existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Media Library - Infinite Scroll
6 participants