T
TanStack•2y ago
fair-rose

`exhaustive-deps` not complaining about `window.location.origin` anymore

Hey, in our codebase we are using window.location.origin inside our queryFn. Previously the exhaustive-deps check was complaining if we did not include it in the key. But if we did I think some kind of error occurred (can not really recall right now). So we ended up with something like 
// disable because queryKey should be independent from window location
// eslint-disable-next-line @tanstack/query/exhaustive-deps
queryKey: ['campaigns', 'list', parkId, filters],
// disable because queryKey should be independent from window location
// eslint-disable-next-line @tanstack/query/exhaustive-deps
queryKey: ['campaigns', 'list', parkId, filters],
Now we implemented a new query where we have the same kind of setup using the window location again. The new queryKey did not complain about the window missing. So we checked at the other places and also the older queries don't complain anymore. Has the rule changed? And in general: What would be the best practise for using window properties inside queryFn - include it in the key? Don't? Thanks in advance 🙂
6 Replies
quickest-silver
quickest-silver•2y ago
it's a normal dependency - include them in the key
fair-rose
fair-roseOP•2y ago
Sounds reasonable. The eslint rule doesn't find it anymore though on the below code: 
    queryKey: ['accessibility', windfarmId] as const,

    queryFn: async () => {
      const url = new URL(
        getApiRoute('/estimations/non-accessibility'),
        window.location.origin,
      );
      const searchParams = new URLSearchParams();

      [50, 75, 90].forEach(percentile => {
        searchParams.append('percentile', percentile.toString());
      });

      url.search = searchParams.toString();

      const response = await fetchData({
        url: url.toString(),
        method: 'GET',
        windfarmId,
      });

      return getNonAccessibilitySchema.parse(response.body);
    },
    queryKey: ['accessibility', windfarmId] as const,

    queryFn: async () => {
      const url = new URL(
        getApiRoute('/estimations/non-accessibility'),
        window.location.origin,
      );
      const searchParams = new URLSearchParams();

      [50, 75, 90].forEach(percentile => {
        searchParams.append('percentile', percentile.toString());
      });

      url.search = searchParams.toString();

      const response = await fetchData({
        url: url.toString(),
        method: 'GET',
        windfarmId,
      });

      return getNonAccessibilitySchema.parse(response.body);
    },
Do you think this is a bug?
quickest-silver
quickest-silver•2y ago
probably, not sure. globals aren't reactive and you're reading the latest value every time so I'm not sure if it's necessary. The thing is by reading window.location rather than useLocation() or whatever your routing solution offers, you are not subscribed to changes so your component won't re-render if location changes. I probably wouldn't do that at all
fair-rose
fair-roseOP•2y ago
Alright, sounds good. We've been leaving them out already and it works fine. Thank you I think I found something here on this topic. The queries I was mentioning that don't error on missing dependencies if window.location.origin is used inside the queryFn are not erroring about any missing dependencies when used with skipToken. https://tanstack.com/query/v5/docs/framework/react/guides/disabling-queries/#typesafe-disabling-of-queries-using-skiptoken This might be an issue for everyone using some conditional queryFn based upon the above docs, is it?
quickest-silver
quickest-silver•2y ago
does it not complain about anything with a conditional queryFn, or is it window.location specific ?
fair-rose
fair-roseOP•2y ago
No, it's not complaining about anything missing

Did you find this page helpful?