[BUG] useDataGrid and syncWithLocation set to true triggers the same request twice about refine

[aliemir]

Hey @levipro sorry for the issue! This is a valid issue that we've been discussing with our team to provide a proper solution. We're passing the router parameters (parameters and query string) to the data providers with meta property and it's also used in the query keys. We've discussed about having a prop or a config to prevent router values to be included to the meta which user can then decide whether they should be included or not 🤔 We've also discussed to always remove the known parameters from the meta such as parameters from syncWithLocation like in this case.

I'll provide an update here as soon as we decide on the changes and working on the implementation. Please do not hesitate share if you have any ideas and comments on this.

[Conqxeror]

It looks like the issue might be related to how the useDataGrid hook handles the synchronization of sorting information with the URL when syncWithLocation is set to true. The described behavior indicates that the initial request is triggered correctly, but then a duplicate request is made due to the way the sorting information is included in the meta data.

To address the issue, you can try modifying the handleSortModelChange function in the useDataGrid hook. Specifically, you can update the function to immediately sync the sorting information with the URL when the sort model changes, preventing the need for a second request.

Link to that specific code.

Here's a modified version of the handleSortModelChange function:

const handleSortModelChange = (sortModel: GridSortModel) => {
    const crudSorting = transformSortModelToCrudSorting(sortModel);
    setSorters(crudSorting);

    // Immediately sync the sorting information with the URL
    if (syncWithLocationProp) {
        const link = createLinkForSyncWithLocation({ sorters: crudSorting });
        window.history.replaceState({}, "", link);
    }
};

This modification should update the URL immediately when the sorting model changes, avoiding the need for an additional request. Make sure to test this change in your application to ensure it resolves the described issue.

Will it create any other issue if we modify the code in that way @BatuhanW @aliemir ?

[BatuhanW]

Hello @Conqxeror thanks for the investigation, it looks great!

I think we need to confirm that duplicate request isn't caused by strict mode, see our FAQ here: https://refine.dev/docs/guides-concepts/faq/#why-are-api-calls-triggering-twice cc @levipro

[alicanerdurmaz]

Hello @levipro, are you using Next.js?

Yesterday we released new version of @refinedev/nextjs-router and we believe this issue is fixed.
Can you upgrade @refinedev/nextjs-router to @5.5.7 and try again please?

[suphon-t]

Hey @levipro sorry for the issue! This is a valid issue that we've been discussing with our team to provide a proper solution. We're passing the router parameters (parameters and query string) to the data providers with meta property and it's also used in the query keys. We've discussed about having a prop or a config to prevent router values to be included to the meta which user can then decide whether they should be included or not 🤔 We've also discussed to always remove the known parameters from the meta such as parameters from syncWithLocation like in this case.

I'll provide an update here as soon as we decide on the changes and working on the implementation. Please do not hesitate share if you have any ideas and comments on this.

Hello, @aliemir. Just wanted to chime in that I'm facing this issue too, but my use case is a bit different.
I'm using useDataGrid with another hook that also has syncWithLocation (useModalForm from @refinedev/react-hook-form). It's a list page with create/edit/show modals for the resource.

What happens is that the modal adds a modal-<resource>-create query to the params when it's open, and it gets included in the meta like you said, which causes the table to refresh.
In this case, the second solution you mentioned (automatically removing known parameters) might not work.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.