feat(cdk/scrolling): Viewport needs asynchronous functions to set data

[jzabinski-dolios]

Feature Description

The virtual scrolling viewport is asynchronously initialized. Normally developers can expect that when ngAfterViewInit() is called in a component's parent, the component will be ready for interaction, but the viewport is not yet ready at that point. The application needs to wait a tick so that the viewport can finish initializing before using functions like scrollToIndex. Developers should not need to know this before using the viewport.

I request that all functions requiring a fully initialized viewport be replaced with asynchronous versions that defer the execution of those functions until the viewport is finished with initialization. A viable alternative would be to provide an Observable that declares that the viewport is ready to receive commands.

Use Case

I want to be able to use the viewport in ngAfterViewInit as can normally be done with child components. See this Stackblitz.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.

[jackalvrus]

Yes, please.

My use case is: I want to scroll to a specific point in the list on load of the component that uses the scroller.

Having to call scrollTo* from a setTimeout and hoping for the best is very hacky. Some way to know when the scroller is ready to receive scrollTo* calls would be much better.

Possibly even better for my use case would be a way to initialize the scroll position without an explicit call to scrollTo*.

[siqiluo7]

Another workaround I use is to use scrolledIndexChange which emits when the index of the first element visible in the viewport changes. Therefore, when the viewport initialized, this event will be emit as well. And in ur code, you can use take(1) to only react on the viewport initialization.