Use "strictNullChecks": true in ra-core

[sixers]

This PR enables strictNullChecks mode in ra-core, which is required by many useful TypeScript packages (e.g. https://github.com/colinhacks/zod or https://trpc.io/)

The current implementation is just bare minimum to make it compile, and has a handful of ugly type casts. I submitted it to open a a discussion on the best approach to resolve issues - there are a few alternatives.

I added some comments which explain the issues and lists possible solutions.

[sixers]

This is the controversial part I guess, because the current ListControllerResult types are incorrect, and data can actually be undefined. I tried to make ListControllerResult conditional, but unfortunately it's not sufficient to just condition on isLoading. E.g. query could be disabled and idle or return error, and have both data: undefined and isLoading: false.

Therefore, the easiest option was to just make the data optional, which unfortunately means that I had to augment demo code with additional checks.

[sixers]

This complained about authProvider.getIdentity possibly being undefined. There is a check, but it's in outer scope, and this is async function which can be executed later, so this check doesn't apply to the inner function. Therefore, I changed it to call authProvider.getIdentity() immediately in the current scope and simply use .then() / .catch() to store the results.

[sixers]

This is a bit of a hack. I assume the intention is that you either have to provide resource in useCreate() invocation, or you need to pass it to returned mutation function:

const [create] = useCreate('product')
const doCreateProduct = useCallback((data) => create({data}));

const [create] = useCreate();
const doCreateProduct = useCallback((data) => create({resource: 'product', data}));

Only these 2 cases should be allowed. If that's the intention, then I see 2 options:

1. Make UseCreateResult result conditional based on the provided resource, so that it's required param in the returned mutation function if it's undefined, or optional if it's not undefined
2. Just do a runtime check and don't call dataProvider if callTimeResource is undefined.

WDYT?

[sixers]

Similar to the hack above, and we have similar options: 1) callTimeId should only be optional if params.id is not undefined, and required otherwise 2) just do a runtime check

[slax57]

This is really a massive work you started here!
This was not in our top priorities at the moment, so I don't know when we will have time to review and discuss about your PR, but it will certainly help that you started to tackle the work this far, and I definitely appreciate the initiative!
Thanks!

[fzaninotto]

I can foresee this will be very hard to review - I've seen nasty impacts with that type of changes in the past. I'd prefer if you split it into several smaller PRs.

[sixers]

I can foresee this will be very hard to review - I've seen nasty impacts with that type of changes in the past. I'd prefer if you split it into several smaller PRs.

I understand that. This PR is not ready to be fully reviewed and merged, it just highlights all the places that have to be updated to support strictNullChecks. And it also surfaces key decisions that have to be made to fully support strictNullChecks. I believe there is value in looking at all the changes in aggregate, to make sure the API is consistent. It would be great if you could do a high-level review and if we could agree on the general direction, and then I can split the final set of changes into a few smaller PRs.

If it makes things easier, I identified the following main "buckets" for changes.

• A. Update default values of custom Contexts (e.g. ListContext)
• B. Update types of async query hooks which return data (e.g. useListContext)
• C. Update types of async mutation hooks, which expects certain parameters to be passed either to a hook itself, or returned mutation function (e.g. useCreate)
• D. Bugs, incorrect implicit types, etc. (e.g. in useGetIdentity)

I added a comment for each of the buckets, but I'm also happy to describe each bucket / issue in detail.

If you insist on splitting this work upfront, I can do that as well.

I've seen nasty impacts with that type of changes in the past.

Could you give me an example? It would be helpful for me to get some context and make sure this change doesn't cause issues.

[WiXSL]

Related to #7588

[djhi]

Thanks for the PR but as @fzaninotto said, we'll work on it in smaller chunks