-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[BUG] Queries are not responding to URL parameter changes #6377
Comments
Hi @aliemir I can work on this. Please assign me |
Hey @mr-loop-1 assigned issue to you. |
@aliemir why do we need to do same for mutation keys that you mentioned in your fix. |
Hey @mr-loop-1, I wanted to make sure we check for every usage of the keys in |
Do we need a separate mockdata file for multi-tenant testing similar to this |
@mr-loop-1 you can provide custom methods/mocks in the test case if they're going to be used in one place only 🤔 |
I worked on this extensively today. Isn't this test case related to same, I read in docs that
also, i may not be able to work on this for sometime hence unassigning |
The parameter change should also have an effect on the filters, e.g.: createResource("whatever", {
meta: {
hide: true,
parent: "projects",
filters: [{ field: "projects.id", operator: "eq", value: ":projectId" }],
},
}), |
Discussed in #6318
Originally posted by TomCaserta September 11, 2024
Essentially I'm reading over the multitenancy documentation https://refine.dev/docs/guides-concepts/multi-tenancy/ and I've implemented what it suggests:
:tenantId
tenantId
found in the meta and sends it to my endpoints via a headerThe issue seems to be when I replace the tenantId parameter in the URL it doesn't actually reload the data.
After looking at the examples it seems it uses the params and the tenant ID as a filter parameter in the multi tenancy strapi example.
This seems to be different to the suggested approach and of course works in that scenario as the param changing causes the query key to change as the filters are changing. As far as I can tell the meta (combinedMeta) is not taken into consideration in the
useList
query key creation, is this intentional?:https://github.com/refinedev/refine/blob/master/packages/core/src/hooks/data/useList.ts#L238
Is there any way to make this work using route parameters and without specifying a filter on every usage of a useList/useOne/useMany hook?
Proposed Fix
When generating query and mutation keys,
combinedMeta
should be used instead ofpreferredMeta
. This case needs to be done for every data hook to be consistent. A related test case needs to be added.The text was updated successfully, but these errors were encountered: