feat(cdk-experimental/scrolling): support scrollToIndex

[spike-rabbit]

implements VirtualScrollStrategy#scrollToIndex in AutoSizeVirtualScrollStrategy.

Approach:
With this change, the item size and the total content size are no longer aligned to reasons described later on.
Due to this, the recalculating of the content for the current offset was changed. The first visible index is now calculated based on the relation from the current scrollOffset to the max scrollOffset.
Since the total content size can be off for a larger amount, it is now smoothly corrected and no longer just set to the estimated total content size.

The virtual-for-of.ts had a bug (?) which made it impossible to measure the size of the last item. This is now fixed, but probably a breaking change.

Scrolling to an index is now implemented. When scrolling to an index, the target offset for the index is calculated based in the estimated item size and a correction in case there is already a difference between the current offset and the current estimated offset. When smooth scrolling is activated, multiple scroll events will occur.

While scrolling to an index, the behavior is different from normal user scrolling. The problem that needs to be solved in this case is, that we are scrolling to an estimated offset, which could be off but cannot be corrected anymore. Therefore, we need to adjust the content offset, even if it increases the amount of error.
This is done in two steps:

• while scrolling, the rendered range is calculated based in the already scrolled amount in relation to the max scroll distance
• once the target index is rendered for the first time, the content will be ideally adjusted and then no longer modified till the scroll is completed

There are some special cases, that need extra care:

• target index is already rendered --> scrolling precisely by the amount of pixels
• estimated target scroll offset is already rendered, but target index is not --> scroll by sizes of rendered items in between - estimated item sizes for non-rendered items in between
• scrolling to an index which close to the end of the list, so that the remaining items are smaller than the viewport --> scroll to the end as far as possible

See #10113

@mmalerba Can you please provide some feedback here. Tests are still missing, I will add them later if you confirm that this could be merged if everything is completed.

• Do you agree on the overall strategy?
• Is there a change that this could be merged if I complete everything?
• Any mistakes you can see so far?
• Should I move the adjustment in virtual-for-of.ts to another commit?
• I guess it makes sense to have the "scrolling controls" from the demo app available for every scroll viewport. Do you mind if I change this by extracting them into an extra component?
• FYI: horizontal window resizing causes content adjustment when scrolled (was an issue before my changes)
• FYI: refreshing the page after scrolling will break scrolling to and index. I will deal with this later

[mmalerba]

@spike-rabbit Sorry for the delay, I recently got back from a long vacation. Let me address your questions point-by-point:

Do you agree on the overall strategy?

Yes, overall this makes sense and thanks for the detailed explanation & comments. That really helps to understand what's going on here.

Is there a change that this could be merged if I complete everything?

I think there's a good chance of getting it merged since most of the changes are to the experimental strategy which is not heavily used inside google (though it does have some). I'll kick off our internal tests to get an exact sense of how many failures we'd be looking at.

Any mistakes you can see so far?

So far looks good, though I need to do a more careful review. This is some pretty dense code, so it will take a little time to fully digest :)

Should I move the adjustment in virtual-for-of.ts to another commit?

Yes, splitting this into smaller chunks would be good, particularly the virtual-for-of change since it affects the non-experimental version as well.

I guess it makes sense to have the "scrolling controls" from the demo app available for every scroll viewport. Do you mind if I change this by extracting them into an extra component?

Yep, totally fine with that.

FYI: horizontal window resizing causes content adjustment when scrolled (was an issue before my changes)
FYI: refreshing the page after scrolling will break scrolling to and index. I will deal with this later

Ack, lets call that out as a known issue in the JSDoc for those properties, and we'll obviously want to fix it before moving the strategy out of experimental.

Thanks a lot for the really thorough and thoughtful work on this!

[spike-rabbit]

@mmalerba How can I debug the unit tests?

I tried yarn test src/cdk-experimental/scrolling --debug. Opening the browser on http://localhost:9876/ but when I click the debug button I get a blank page (http://localhost:9876/debug.html). Without the debug mode, the sources are not available.

Already rebased on the latest main today.

Using Ubuntu, Firefox and Chrome are both affected

[mmalerba]

I think it just appears blank because the tests execute quickly and then the DOM is cleaned up. I typically put a debugger; statement in the test I'm interested and then refresh the debug.html (with the console open) it should hit the debugger line and pause execution with the DOM still up

[spike-rabbit]

Sorry to bother you once more with a problem. Whenever recompiling the test in debug mode, I get this error:

iBazel [11:56AM]: IBAZEL BUILD SUCCESS
17 05 2023 09:56:14.736:WARN [filelist]: Pattern "/home/maxi/.cache/bazel/_bazel_maxi/de2e33f8fa65b21e12a005108e16eb84/execroot/angular_material/_tmp/418bc9cea3ac2f66e003d8400ebea81f/25l9w0b9vx.js" does not match any file.
17 05 2023 09:56:14.848:ERROR [karma-server]: UnhandledRejection: Error: ENOENT: no such file or directory, open '/home/maxi/.cache/bazel/_bazel_maxi/de2e33f8fa65b21e12a005108e16eb84/execroot/angular_material/_tmp/418bc9cea3ac2f66e003d8400ebea81f/1n2wr930q6'
    at Object.openSync (node:fs:585:3)
    at Object.writeFileSync (node:fs:2155:35)
    at Server.<anonymous> (node_modules/@bazel/concatjs/index.js:58:16)
    at Server.emit (node:events:532:35)
    at Server.emit (node:domain:475:12)
    at emit (node_modules/karma/lib/file-list.js:30:21)
    at FileList._emitModified (node_modules/karma/lib/file-list.js:35:19)
    at node_modules/karma/lib/file-list.js:110:14
17 05 2023 09:56:14.849:ERROR [karma-server]: Error: ENOENT: no such file or directory, open '/home/maxi/.cache/bazel/_bazel_maxi/de2e33f8fa65b21e12a005108e16eb84/execroot/angular_material/_tmp/418bc9cea3ac2f66e003d8400ebea81f/1n2wr930q6'
    at Object.openSync (node:fs:585:3)
    at Object.writeFileSync (node:fs:2155:35)
    at Server.<anonymous> (node_modules/@bazel/concatjs/index.js:58:16)
    at Server.emit (node:events:532:35)
    at Server.emit (node:domain:475:12)
    at emit (node_modules/karma/lib/file-list.js:30:21)
    at FileList._emitModified (node_modules/karma/lib/file-list.js:35:19)
    at node_modules/karma/lib/file-list.js:110:14 {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/home/maxi/.cache/bazel/_bazel_maxi/de2e33f8fa65b21e12a005108e16eb84/execroot/angular_material/_tmp/418bc9cea3ac2f66e003d8400ebea81f/1n2wr930q6'
}

So initial compiling works, but after changing something it breaks. Any ideas how I can fix this? Already deleted ~/.cache/bazel, ~/.cache/bazelisk and node_modules

[mmalerba]

Hmm, the same thing happens to me. Let me bring the issue up to our dev-infra people and see what they say about it. In the mean time, its not a great solution, but I would say just kill the command and rerun it after you make your changes

[GirishKumar-Muniraju]

Hello mmalerba/spike-rabbit,
Any progress on this activity ???