Nuxt 3 SSR issues

[abrunner94]

Hi all.

I am using Nuxt 3 + SSR and I am running into an issue with how vue-query behaves.

Behavior
Whenever I hard refresh my Nuxt 3 page, no data is fetched. Whenever I go to another route, and come back, data is fetched successfully. Basically, every time I refresh my page, even when data is literally on that page at the moment, no data will be shown. It's only until after I go to another route and come back that data is fetched again.

I suspect this might have something to do with my custom composable, how SSR behaves, or maybe something else.

Context + Code
This is my setup:

plugins/vue-query.ts:

import type { DehydratedState, VueQueryPluginOptions } from '@tanstack/vue-query';
import { VueQueryPlugin, QueryClient, hydrate, dehydrate } from '@tanstack/vue-query';

// Nuxt 3 app aliases
import { useState } from '#app';
  
export default defineNuxtPlugin((nuxt) => {
    const vueQueryState = useState<DehydratedState | null>('vue-query');

    // Modify your Vue Query global settings here
    const queryClient = new QueryClient({
        defaultOptions: { 
            queries: { 
                staleTime: 2500, 
                refetchOnMount: 'always',
                refetchOnWindowFocus: 'always' 
            }
        },
    });

    const options: VueQueryPluginOptions = { queryClient };

    nuxt.vueApp.use(VueQueryPlugin, options);

    if (process.server) {
        nuxt.hooks.hook('app:rendered', () => {
            vueQueryState.value = dehydrate(queryClient);
        });
    }

    if (process.client) {
        nuxt.hooks.hook('app:created', () => {
            hydrate(queryClient, vueQueryState.value);
        });
    }
});
  

I also have this composable I wrote, which (may be) part of the issue:

composables/useQueryFetch.ts:

import { useQuery } from "@tanstack/vue-query";

export default function useQueryFetch<T>(queryKey: string, endpoint: string) {
    const config = useRuntimeConfig();

    const fetcher = async(): Promise<T> => {
        try {
            const { data, error } = await useFetch(`${config.public.baseURL}/api/${endpoint}`, { 
                credentials: 'include', 
                headers: useRequestHeaders()
            });

            if (error.value) {
                throw new Error(error.value?.data?.error || "An unknown error occurred during data fetching.");
            }

            if (!data.value) {
                throw new Error("No data returned from the fetch operation.");
            }

            return data.value as T;
        } catch (err: any) {
            throw new Error(err.message || "An error occurred during data fetching.");
        }
    };

    return useQuery<T>({ queryKey: [queryKey], queryFn: fetcher });
};

And this is how I use it in my pages/index.vue:

<script setup lang="ts">
    definePageMeta({ middleware: ['auth'] });
  
   //  ... other stuff not related
   
    // Data
    const { data: coolData, suspense, error, isError, isLoading, refetch } = useQueryFetch<CustomType[]>('coolData', 'cool_data');

    onServerPrefetch(async () => {
        await suspense();
    });
</script>

<template>
        <div v-if="isLoading">Loading...</div>
        <div v-else-if="isError">{{ error?.message }}</div>
        <div v-else-if="!isLoading && coolData?.data?.length === 0">...</div>
        <div v-else>
             <div v-for="item in coolData?.data">
                   {{ item?.name }}
             </div>
        </div>
</template>

[tinpe]

In my case, it was a cookie issue. I was using a $fetch inside useQuery which doesn't forward headers during SSR.

When we call $fetch in the browser, user headers like cookie will be directly sent to the API.

However, during Server-Side Rendering, due to security risks such as Server-Side Request Forgery (SSRF) or Authentication Misuse, the $fetch wouldn't include the user's browser cookies, nor pass on cookies from the fetch response.

This means my auth cookie wasn't forwarded, which would cause my API route to throw 401 error for that query during SSR, and query cache not filled.

When the component was created on the client and the request was issued, everything worked as expected because the headers (and the cookie) were properly forwarded.
This also caused hydration errors.