[XGrid] Add onViewportRowsChange prop

[DanailH]

Part of #1247
Fixes #2387

Based on this comment #1715 (comment)

Preview: https://deploy-preview-2038--material-ui-x.netlify.app/components/data-grid/virtualization/

[oliviertassinari]

For the tests, we have more related to the virtualization inside rows.XGrid.test.tsx. Would it be a better place for them?

Also, I think that we should better control the rendering parameters. The same feedback as @m4theushw did on the PR of @flaviendelangle #1986 (comment). IMHO, it's easier to resonate based on the size of the viewport, rather than the size of the whole data grid container.

Otherwise, for the tests, I think that we should add more. For instance, we could assert that the initial event is correct, that if a row is visible by 1 pixel, it's included in the viewport. That if we scrollTop = 10 pixels, it triggers (not need to go to the bottom).

[oliviertassinari]

Feedback I did in the last O3: we can't add a demo for this feature until #1911 is fixed. The data grid is displaying rows that have nothing to do with what the given scroll top should display. To make progress here, we would need to work in TDD.

[oliviertassinari]

@DanailH Could you use this case:

import * as React from 'react';
import { XGrid } from '@material-ui/x-grid';
import { useDemoData } from '@material-ui/x-grid-data-generator';

export default function XGridDemo() {
  const { data } = useDemoData({
    dataSet: 'Commodity',
    rowLength: 100000,
    editable: true,
  });

  return (
    <div style={{ height: 520, width: '100%' }}>
      <XGrid
        {...data}
        loading={data.rows.length === 0}
        rowHeight={38}
        checkboxSelection
        onViewportRowsChange={(params) => console.log('onViewportRowsChange', params)}
        disableSelectionOnClick
      />
    </div>
  );
}

and test that it supports all the required cases? Here is one example where it doesn't meet the expected outcome:

event.not.firing.mp4

Regarding what should be the expected outcome, 1. I would be in favor of saying whatever is the scroll-top value which would mean not respecting what's displayed, but at least, it would eventually be correct once we fix the rendering. 2. Now, if it's simpler to have it based on the rendering state, then why not. 3. We could also give up on the feature and wait for #1911 or #1933 to complete the effort (they can be considered blockers). Merging this PR as a first step in the right direction, with the right API and a beginning of a support (but noting that can be used by developers yet, so keeping it undocumented).

updated

[oliviertassinari]

@DanailH Great, a good step forward! I have proposed what we could do next on #1247 (comment).