[core] Rework useGridRows high frequency update

[flaviendelangle]

Preview: https://deploy-preview-2561--material-ui-x.netlify.app/components/data-grid/rows/#high-frequency

• Remove the systematic 100ms delay before update and replace it with a throttleRowsMs option
• Remove GridEvents.rowsClear and GridEvents.rowsUpdate
• Rename InternalGridRowsState => GridRowsState for consistency
• Make current tests pass
• Add richer test around the throttling
• Update the docs

New option props.throttleRowsMs

I think it's better to let the user choose if he wants to throttle or not.
Today, every Grid has a 100ms delay on update even if it's not useful in most cases.
I went for a throttle instead of a debounce to avoid scenarios when we never have enough time between two updates so we never update the state.

Consequences on the events

Before, we were updating the state when receiving an update but we weren't publishing the event right away.
I think we should avoid that.
Now, the state is only updated after the throttle period if any. And the event is published at the same time.
By default (and in the large majority of cases), their is no throttle so the update of the rows is as synchronous as any other update.

[DanailH]

props.throttleRowsMs sounds to me like a good candidate for being a Pro feature (it already kind of is since you use it in combination with the apiRef but if we are to expose the apiRef then that won't be the case - based on 3. from this #2522 (comment)). I think we should make it only available in DataGridPro.

[flaviendelangle]

As I built it, the throttleRowsMs also works for frequent props.rows update so it is usable in the free version.
But we can decide to limit it to the paid version.

@oliviertassinari , @m4theushw what is your view on that topic ?
Note that it's a very simple prop to switch back to the free version if we change our mind later.

[m4theushw]

Should we keep the 100ms as default? AG-Grid uses 50ms: https://ag-grid.com/javascript-data-grid/data-update-high-frequency/#flush-async-transactions

If we change the default value, we need to update the useEffect to run immediately when the prop changes. I think throttleRowsMs is only for setRows and updateRows.

[flaviendelangle]

My idea was to let the default value at 0 and if the user defines a throttle value, then it applies even on rows update.
But if you prefer to have a default value other than 0, then we should probably not run throttle the props update.

[m4theushw]

Let's keep the default as 0. I remembered that we don't have a separate method for throttled updates, so having a non-zero default will affect updateRows too.

With this PR, it should be possible to remove the following setTimeout:

https://github.com/mui-org/material-ui-x/blob/67864f8077b842eedcfc9f4f6765b055efa09988/docs/src/pages/components/data-grid/editing/FullFeaturedCrudGrid.tsx#L91-L92

[flaviendelangle]

We just need to wait for the next render in order to focus

  const handleClick = () => {
    const id = randomId();
    apiRef.current.updateRows([{ id, isNew: true }]);
    apiRef.current.setRowMode(id, 'edit');
    setTimeout(() => {
      apiRef.current.scrollToIndexes({
        rowIndex: apiRef.current.getRowsCount() - 1,
      });
      apiRef.current.setCellFocus(id, 'name');
    })
  };

Screencast.2021-09-13.14.49.58.mp4

[flaviendelangle]

We could think of a better API to do so later on

[m4theushw]

As I built it, the throttleRowsMs also works for frequent props.rows update so it is usable in the free version.
But we can decide to limit it to the paid version.

I would keep it only for the API calls. Users can throttle the prop update in their applications. Once I have a value for throttleRowsMs and I want to immediately change the rows I can't, unless setting throttleRowsMs to zero before.

[flaviendelangle]

@mui-org/x can we merge this PR once the release is done ?

[oliviertassinari]

AFAIK, no spaces when using a slash, unless it's separating multiple words.

Suggested change

	* It can be useful if you have a high update rate but do not want to do heavy work like filtering / sorting or rendering on each individual update.
	* It can be useful if you have a high update rate but do not want to do heavy work like filtering/sorting or rendering on each individual update.