-
Notifications
You must be signed in to change notification settings - Fork 178
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
Conversation
assets/src/edit-story/components/library/panes/media/mediaPane.js
Outdated
Show resolved
Hide resolved
This branch needs to be rebased. |
I like that after upload, the view reset and scrolls to the top 👍 |
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.
One small tweak and a question, but otherwise, we are looking good.
Done, I think we can merge it and work from there. |
16d32af
to
2b5c8a0
Compare
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 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 ℹ️ Googlers: Go here for more info. |
@googlebot I consent. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Size Change: +933 B (0%) Total Size: 414 kB
ℹ️ View Unchanged
|
@merapi I'm getting a console error and the editor is breaking: Wanted to test before reviewing, does it work for you? |
I am not seeing the console errors. |
assets/src/edit-story/components/library/panes/media/mediaPane.js
Outdated
Show resolved
Hide resolved
This PR needs to be merge into master. Much has changed in media. |
assets/src/edit-story/components/library/panes/media/mediaPane.js
Outdated
Show resolved
Hide resolved
mediaType, | ||
}; | ||
} | ||
|
||
case types.SET_PAGE: { |
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.
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?
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.
We now just have SET_NEXT_PAGE
.
assets/src/edit-story/components/library/panes/media/mediaPane.js
Outdated
Show resolved
Hide resolved
assets/src/edit-story/components/library/panes/media/mediaPane.js
Outdated
Show resolved
Hide resolved
{resources | ||
.filter((_, index) => isEven(index)) | ||
.map((resource, i) => ( | ||
<MediaElement |
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.
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 }); |
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.
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.
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.
Agree, but I would call it setNextPage
because it doesn't load the next page by itself.
ES6 import is failing (repo cause): https://travis-ci.com/github/google/web-stories-wp/jobs/297848579
16d3ef5
to
5d7fb0d
Compare
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.
This looks good. 👍
This adds infinite scroll to the Media gallery (#23).
Next steps (can be included in this PR):
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).
Keyboard support - be able to see all images with arrows.
UX, loading states.