Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TypeScript] Fix useGetOne and useGetMany params type when id param is undefined #9971

Merged
merged 4 commits into from
Jul 10, 2024

Conversation

fzaninotto
Copy link
Member

@fzaninotto fzaninotto commented Jul 2, 2024

Problem

TypeScript complains when useGetOne is called with an undefined id. This is fine, except when using the enabled option:

image

This is a consequence of the strictNullCheck flag in ra-core.

Solutions

  1. Use type overloads to allow optional id when enabled is specified. This forces the developer to set teh enabled flag when id may be undefined - not ideal.
  2. Change input type for the data provider hooks to allow an undefined id, and set the enabled flag in the hook accordingly. this offers a better DX as TypeScript won't complain but user land code won't break either.

We choose solution 2.

… false

## Problem

TypeScript complains when `useGetOne` is called with an undefined `id`. This is fine, except when using the `enabled` option:

```jsx
const { data, error, isPending } = useGetOne<Post>(
    'posts',
    { id: comment?.post_id },
    { enabled: !!comment }
);
```

## Solution

Use type overloads to allow optional id when enabled is specified.
@fzaninotto
Copy link
Member Author

Now I wonder if that's the right fix. Instead of forcing users to set the enabled flag when the main param may be undefined, shouldn't we relax the params type to accept undefined values, and set the enabled flag ourselves if the main param is undefined?

@djhi
Copy link
Contributor

djhi commented Jul 3, 2024

Now I wonder if that's the right fix. Instead of forcing users to set the enabled flag when the main param may be undefined, shouldn't we relax the params type to accept undefined values, and set the enabled flag ourselves if the main param is undefined?

I like this idea 👍

@fzaninotto fzaninotto changed the title [TypeScript] Fix useGetOne and useGetMany params type when enabled is false [TypeScript] Fix useGetOne and useGetMany params type when id param is undefined Jul 3, 2024
Comment on lines +302 to +335
describe('TypeScript', () => {
it('should return the parametric type', () => {
type Foo = { id: number; name: string };
const _Dummy = () => {
const { data, error, isPending } = useGetOne<Foo>('posts', {
id: 1,
});
if (isPending || error) return null;
return <div>{data.name}</div>;
};
// no render needed, only checking types
});
it('should accept empty id param', () => {
const _Dummy = () => {
type Comment = {
id: number;
post_id: number;
};
const { data: comment } = useGetOne<Comment>('comments', {
id: 1,
});
type Post = {
id: number;
title: string;
};
const { data, error, isPending } = useGetOne<Post>('posts', {
id: comment?.post_id,
});
if (isPending || error) return null;
return <div>{data.title}</div>;
};
// no render needed, only checking types
});
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, as we don't compile our tests, we won't ever see this fail in CI

@@ -398,4 +398,45 @@ describe('useGetMany', () => {
expect(abort).toHaveBeenCalled();
});
});

describe('TypeScript', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same

@fzaninotto fzaninotto merged commit 103f119 into master Jul 10, 2024
14 checks passed
@fzaninotto fzaninotto deleted the typescript-usegetone-enabled branch July 10, 2024 12:03
@fzaninotto fzaninotto added this to the 5.0.4 milestone Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFR Ready For Review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants