[DataGrid] Fix events naming

[m4theushw]

Breaking changes

• [XGrid] The following events were renamed:

  1. columnHeaderNavigationKeydown to columnHeaderNavigationKeyDown
  2. columnResizeCommitted to columnWidthChange
  3. rowsUpdated to rowsUpdate
  4. rowsCleared to rowsClear
  5. columnsUpdated to columnsChange

• [XGrid] The following DOM events were removed because they were not necessary for the grid to work:

  1. focusout
  2. keydown
  3. keyup

  If you need them, attach a listener using the apiRef, as following:

  apiRef.current.rootElementRef?.current?.addEventListener('focusout', event => {
    // ...
  });

---

Preview: https://deploy-preview-1862--material-ui-x.netlify.app/components/data-grid/events/#catalog-of-events
Closes #1383

[oliviertassinari]

I'm confused. Why do we have GRID_COLUMN_HEADER_KEYDOWN but GRID_COLUMN_HEADER_NAVIGATION_KEY_DOWN (KEY_DOWN vs. KEYDOWN)?

[dtassone]

GRID_ROWS_CHANGE then?
as you remove 'update' in columns

[oliviertassinari]

@dtassone and how would you name the two other events? GRID_ROWS_SET, GRID_ROWS_CLEAR.

If we update the row update events to only fire one, then GRID_ROWS_CHANGE seem definitely better.

[m4theushw]

What's the point to have GRID_ROWS_CLEAR? It's only used by the sorting to clear the sorting once all the records are updated. GRID_ROWS_SET could be used instead.

[dtassone]

Well I like granular events and those are for internal use but ultimately they are change events.
However the clear and set occurs in 1 rendering so you can't publish change as it's for internal reset of rows to put new ones. Users should only know about the new updated set.

[dtassone]

If we have doubts, how about we keep those for the next iteration?

[oliviertassinari]

Looking at the publish:

• When GRID_ROWS_CLEARED is triggered, GRID_ROWS_SET is always triggered.

At the listeners:

• GRID_ROWS_SET is listed by applySorting, applySorting
• GRID_ROWS_CLEARED is listened by "empty sorting" (I'm sending a PR to remove it, it's noise: [DataGrid] Make GRID_ROWS_CLEAR private #1925)
• GRID_ROWS_UPDATED is listened by applySorting, applyFilters

So it seems that we only need one event, not three.

[dtassone]

GRID_ROWS_CLEARED allows to clear the sortedRows state.

[dtassone]

the split between GRID_ROWS_UPDATED and GRID_ROWS_SET was more for a user perspective where one would want to subscribe to row updates

[m4theushw]

GRID_ROWS_SET is published by setRows. But this method is mostly used in demos that programmatically call the API, so the user calling the method doesn't need an event and we can remove it. The only use of setRows outside demos is in updateRows, which also publishes GRID_ROWS_UPDATED.

Side note: setRows is actually appending rows, renaming to addRows might be better.

[dtassone]

Originally the idea was to do a reset with a clear and a set, to avoid sortedRows error... If we remove the clear, we can remove the set as well and just rename the updated to change.