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

V5 beta: duplicated queries on mount #9896

Closed
fzaninotto opened this issue Jun 3, 2024 · 2 comments
Closed

V5 beta: duplicated queries on mount #9896

fzaninotto opened this issue Jun 3, 2024 · 2 comments
Assignees
Labels

Comments

@fzaninotto
Copy link
Member

fzaninotto commented Jun 3, 2024

What you were expecting:
useGetOne and useGetList only trigger one call to the API.

What happened instead:
They call the API twice

Steps to reproduce:

  1. Launch the simple example
  2. Go to a comment edit page
  3. The getOne and getList calls are doubled.

Note that the duplication disappears when I remove StrictMode. However, the example is using React 18, so this isn't caused by changes in strict mode in React 19. When using react-admin v4 with React 18, the bug doesn't appear, so this a regression introduced by v5.

image

Related code:

https://stackblitz.com/github/marmelab/react-admin/tree/next/examples/simple

Environment

  • React-admin version: 5.0.0-beta.3
  • Last version that did not exhibit the issue (if applicable): 4.16
  • React version: 18
  • Browser: Chrome
@fzaninotto fzaninotto added the bug label Jun 3, 2024
@djhi
Copy link
Collaborator

djhi commented Jun 4, 2024

It looks like this is the expected behavior when combining react 18 strict mode and query cancellation. See TanStack/query#3633 (comment)

@fzaninotto
Copy link
Member Author

I can confirm that by removing the signal in useGetOne, the getOne request is no longer duplicated. But this is very surprising: the demo uses ra-data-fakerest, which doesn't implement the abortSignal.

All in all, it means that all apps, whatever their data provider, will see duplicated queries in strict mode by default. The developer experience is worse in general, for an end user benefit that only occurs in a minority of cases.

We need to disable the abortsignal by default, and find a way to make it an opt-in feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants