cdk-virtual-scroll-viewport - support window scroll

[abeymg]

Bug, feature request, or proposal:

Feature request

What is the expected behavior?

Allow the scroll of the cdk-virtual-scroll-viewport to be controlled by the top level window scrollbar.

See example at the link below. (Go to that page and click on parent scroll to see desired behavior)
https://rintoj.github.io/ngx-virtual-scroller

Another example of window scrolling in the context of virtual scrolling
https://bvaughn.github.io/react-virtualized/#/components/WindowScroller

What is the current behavior?

Specifying a parent scroll does not seem to be supported, from what I can tell.

What is the use-case or motivation for changing an existing behavior?

Having a single top level window/page scroll is standard in a lot of SPAs. The virtual-scroll would be a lot more useful in these cases, if it could use the same scroll bar, otherwise often times you end up with two scrollbars (one for the virt-scroll and the other for the page, or else a smaller inset container for the virt-scroll with a scrollbar), which is less than ideal.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular: 7.0.1
Material: 7.0.2

Is there anything else we should know?

[LeParadoxHD]

That would be very useful!

[flolu]

This should definitely be implemented soon!

[wunaidage]

mark to track status. This will be awesome!

[rmedaer]

@mmalerba I did a small POC to support both window and closest relative parent virtual scrolling.

Actually it's not yet ready for merge. It's still missing tests, examples, and even implementations... But at least it gives a proposal for the implementation. I would be really interested to get your feedback.

In my use-case it fits well. Hope you appreciate.

Here is a demo:

Kind regards,

[mmalerba]

@rmedaer sure, I can take a look. Can you link me to the branch where you're working?

[rmedaer]

Yeah ! I committed on master branch in my fork. I know it's bad but again my plan was just to do a test and it became probably more ..

The dev-app (demo) contains an example.

[mmalerba]

@rmedaer Overall I like the approach, though parts of the implementation I'm not too sure about. I also think we could make the nested viewport more flexible by either making a directive that can be used to mark the parent, or using an @Input() that lets the user specify the scrolling container (e.g. viewportRoot=".some-ancestor-element"), rather than just assuming it's the direct parent.

@jelbourn Do you have any thoughts about this proposal?

[jelbourn]

Could you summarize the approach?

[rmedaer]

Actually, my approach is to decouple the viewport and its container. Then I provide somehow the container to the viewport which will use its API to calculate scroll offset and so on. Here is the container's interface:

export interface VirtualScrollContainerRef {
  measureScrollOffset(from: 'top' | 'left' | 'right' | 'bottom' | 'start' | 'end'): number;
  measureContainerSize(orientation: 'horizontal' | 'vertical'): number;
  getViewportSize(contentSize: number): string | null;
  scrollTo(options: ExtendedScrollToOptions): any;
  elementScrolled(): Observable<Event>;
}

As you can see this interface is implementing more or less the same then CdkScrollable (there is no need of ElementRef).

In my POC I "provide" the container ref to the viewport using a directive that you have to apply on viewport. But as @mmalerba said, we could also use a DOM reference. We could even create a directive that you apply on parent (container) element which has to scroll.

Currently my prototype has 3 ContainerRef directives:

• CdkVirtualScrollDefaultViewport: same behavior then current impl; we are scrolling into the viewport.
• CdkVirtualScrollNestedViewport: use the closest relative parent as container => works well with offsetTop property.
• CdkVirtualScrollWindowViewport: use window as container. This one cannot use implementation from CdkScrollable.

[hezzyg]

This feature is really needed in order to use the Virtual-scroll in real apps.... We would really appreciate if it would be implemented soon.

[vahidvdn]

@hezzyg You can use this module. It's already supported window scroll.

[rmedaer]

@hezzyg otherwise if @mmalerba and/or @jelbourn are OK with my approach, I can deliver a patch ASAP. But I'm still waiting their (no)go to do it (or not). ;-)

[hezzyg]

@hezzyg otherwise if @mmalerba and/or @jelbourn are OK with my approach, I can deliver a patch ASAP. But I'm still waiting their (no)go to do it (or not). ;-)

Thanks @rmedaer . I do prefer a solution integrated into Angular Material for better support in the future. So I hope your suggestion will get there asap :-)

[hezzyg]

@hezzyg You can use this module. It's already supported window scroll.

I'll have a look. thanks @vahidvdn

[mmalerba]

@rmedaer yes I'd like to do this, please send a PR and mention me on it, thanks!

[jeetparikh]

This would be a really useful feature. We are unable to use this at the moment because we have a scrollbar at a different level.

[levitatejay]

@rmedaer @mmalerba

@hezzyg otherwise if @mmalerba and/or @jelbourn are OK with my approach, I can deliver a patch ASAP. But I'm still waiting their (no)go to do it (or not). ;-)

@rmedaer yes I'd like to do this, please send a PR and mention me on it, thanks!

Is there a pull request for the patch?
I really need to implement a window scrolling CDK viewport so I'd be grateful for any help!

[jeetparikh]

@mmalerba the PR #14287 is simply introducing the virtual adapter but is there any PR to support scrolling at parent level or window level for cdk-virtual-scroll-viewport?

[rmedaer]

@jeetparikh if it's really urgent, you can take a look at this commit. It's the POC I made to test virtual scrolling on window.
Btw I don't have so much time to do a PR for now but at least you can already play with it !

[mmalerba]

@jeetparikh yeah my bad, I saw that it was linked to this issue but didn't look closely enough, that PR is unrelated. Deleting my previous comment to avoid confusion for people reading this later.

I thought I remember seeing a PR related to this, but it may have just been a proof of concept on someone's branch

[jeetparikh]

@rmedaer thank you for sharing that. Does that work without any tweaks? Also, does it work with cdk-table? or I would have to make amendments?

[sthan001]

What i feel is that,

1. By default if we don't control overflow (overflow: auto) at cdk-virtual-scroll-viewport, that carries to parent element all the way to window.
   Now that is missing in the cdk-virtual-scroll-viewport element. and cdk-virtual-scroll-spacer should accept the element be it window, of element in local component, or element from parent component as scrollable. A attribute possibly?
2. the cdk-virtual-scroll-viewport should be calculating header and footer size to occupy the cdk-virtual-scroll-spacer. Basically accept the header, footer and any other intermediate element height to be considered to have complete scroll option. Again via attribue.
3. Either spacer to take care of the complete page available to scroll or we can set height of cdk-virtual-scroll-content-wrapper excluding header/breadcrumb/footer including media query adjustments.
4. as much as possible the position of cdk-virtual-scroll-viewport should be not fixed, or absolute. because some application may not able to reuse at their component level depth if that is the case.

Angular doing lot, not sure why this feature is on hold for long time. And again, suggesting alternative 3rd party library is another overhead. These all angular can fix and sell itself well among industries.

[ursaciuc-adrian]

Until this is merged i found a quick workaround for this. You can create a new custom scrolling strategy which is basically the same as the fixed size scrolling strategy, but for the viewPort height you use the hight of the window and for the scroll offset you use the pageYOffset of the window.
And what is left to do is to listen to the scroll event on the page and update the redered range when this happens.
Here is a basic stackblitz with it. It might not work for every case, but it's good enough for what i need it to do. Maybe it will help others too.

https://stackblitz.com/edit/window-virtual-scroll-strategy

[ghenry22]

With Ionic Framework deprecating their own virtual-scroll in favour of CDK virtual-scroller the ability to scroll based on a parent element/window is essential in order for the CDK virtual-scroller to work with other common components like pull-to-refresh, infinite-scroll and iOS style auto expanding header styling in mobile apps.

Details from Ionic team:
https://github.com/ionic-team/ionic-docs/blob/liam-v6-docs/src/pages/angular/virtual-scroll.md

I would be really great if we could pass in a scroll element to the virtual-scroller to use in a similar way to how https://github.com/rintoj/ngx-virtual-scroller works.

[vahidvdn]

@ghenry22 ionic built-in virtual list component was literally useless. Hope it's going to work with the angular CDK virtual-scroller.

[ghenry22]

@vahidvdn I've used the Ionic virtual scroll component successfully in a number of cases. It definitely has some quirks and never got the attention it needed but when you work around it's specific weirdness it does the job.

I agree though I am hoping that the cdk virtual scroller will provide a much more robust and more actively supported solution. Only time will tell!

[syam38]

Any update on this feature?

[syam38]

Until this is merged i found a quick workaround for this. You can create a new custom scrolling strategy which is basically the same as the fixed size scrolling strategy, but for the viewPort height you use the hight of the window and for the scroll offset you use the pageYOffset of the window. And what is left to do is to listen to the scroll event on the page and update the redered range when this happens. Here is a basic stackblitz with it. It might not work for every case, but it's good enough for what i need it to do. Maybe it will help others too. https://stackblitz.com/edit/window-virtual-scroll-strategy

The stackblitz link is not working, could you please re share it @ursaciuc-adrian

[ursaciuc-adrian]

The stackblitz link is not working, could you please re share it @ursaciuc-adrian

Updated the url

[vugar005]

For now, I ended up using Custom Intersection api. Stackblitz url

[spike-rabbit]

@mmalerba Would you still accept a PR adding this feature? I would be happy to provide one following the suggestions by @rmedaer

[mmalerba]

@spike-rabbit Yes, I'm happy to look at a PR along the lines of what we discussed above.

[Harpush]

Will it allow to have two virtual scroll viewports under the same container and the scroll will be in the container? Thus allowing them both to render only what's shown relative to the shared parent container.

[spike-rabbit]

@mmalerba Great, thanks for the info. I plan to provide one around March.

@Harpush Based on my current knowledge: yes. But I need to dive further into this to provide a reliable answer

[lincolnthree]

Thanks for all of you effort on this! Really looking forward to seeing it.

This feature is critical for a "native-like" feel in mobile apps with momentum scrolling. When scrolling locks up and you need to scroll again with a new gesture to continue past the virtual scroll viewport, or capture the gesture in the viewport instead of going past, it really interrupts the user experience.

I will be happy to test and contribute if there is a beta build to try!

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}