[DataGrid] Add possibility of null in the return type of the useGridApiRef() hook

[arminmeh]

Closes #16000

Also related to #16279
since it is adding the v8 part of the types matrix

Changelog

Breaking changes

• Return type of the useGridApiRef() hook and the type of apiRef prop are updated to explicitly include the possibilty of null. In addition to this, useGridApiRef() returns a reference that is initialized with null instead of {}.

  Only the initial value and the type are updated. Logic that initializes the API and its availability remained the same, which means that if you could access API in a particular line of your code before, you are able to access it as well after this change.

  Depending on the context in which the API is being used, you can decide what is the best way to deal with null value. Some options are:

  • Use optional chaining
  • Use non-null assertion operator if you are sure your code is always executed when the apiRef is not null
  • Return early if apiRef is null
  • Throw an error if apiRef is null

[mui-bot]

Deploy preview: https://deploy-preview-16353--material-ui-x.netlify.app/

Updated pages:

• docs/data/migration/migration-data-grid-v7/migration-data-grid-v7.md

Generated by 🚫 dangerJS against 310365f

[cherniavskii]

It's messy, but the type is more accurate now 👍🏻
Thanks!

[lauri865]

@arminmeh, for tests though, wouldn't it be better to have an internal implementation that is not null? I'd rather have a runtime error if I forgot to bind the apiRef to the grid than have an optional chaining function call that silently never gets invoked.

[arminmeh]

@lauri865 that makes sense.
I will go through all test changes later and check where the change could actually make the test false positive.

For most of the test it will not matter, since the optional chaining affects certain action(s) that if silently fails will fail the test assertion

[lauri865]

@lauri865 that makes sense.

I will go through all test changes later and check where the change could actually make the test false positive.

For most of the test it will not matter, since the optional chaining affects certain action(s) that if silently fails will fail the test assertion

I didn't mean that the change would break any old tests, but more a thought about writing new tests going forward.

[arminmeh]

I didn't mean that the change would break any old tests

Well, you made me doubt it now 😅

I didn't spend to much time on the test updates as I tried to make the CI pass as fast as possible
But as I said I plan to go once more through it and set an example for future as well (that also means changes in the current tests)