-
Notifications
You must be signed in to change notification settings - Fork 203
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
SSR Data are loaded only after refresh (SSR BUG related with useAsyncData - so every composable) #473
Comments
The way in which I "hacked" this is issue is the following:
So I am conditionally refreshing the data if they are indeed null. This trick allow me to perform the SSR :) Maybe it's worth allowing an automatic refresh option when data are null and contemporarily we are using SSR. |
@Dinuz can you share apollo config in nuxt.config.ts and @nuxtjs/apollo version? i used
mine still return normal. |
@devhoangkien sure (what do you mean still return normal??), node version 18.13.0 my nuxt.config is super basic:
|
I was having the exact same issues here but ensuring I was on beta-5 of nuxt apollo and nuxt 3.1.2 and everything began working as expected. |
ContextI use a Laravel Lighthouse backend and this only occurs to me when auth is required. System and versions
My nuxt.config.ts// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
modules: ["@nuxtjs/apollo"],
apollo: {
clients: {
default: {
// Tried this too but results in same behavior.
// httpLinkOptions: {
// credentials: "include"
// },
httpEndpoint: "http://myapp.test/graphql"
}
},
},
}); BehaviorIf I protect the query (requiring auth) If I remove the protection from the query (no auth required anymore) Visual example of behavior
It appears when the server is making the request it does so without auth. But I'd like to be able to protect my queries and have them loaded on initial load when authenticated. The only way to get data is by calling the WorkaroundAdding a plugin utilizing the // plugins/apollo.ts
export default defineNuxtPlugin((nuxtApp) => {
nuxtApp.hook('apollo:auth', ({ client, token }) => {
// access cookie for auth
const cookie = useCookie(`apollo:${client}.token`)
// apply apollo client token
token.value = cookie.value ?? null
})
}) Other
|
I have a similar issue as @timyourivh, but in my case it works on refresh(SSR) and not on the client side. I am using the apollo:auth hook inside plugins/apollo.ts like so:
This works fine for SSR requests (like on refresh), but returns Bearer undefined for client side requests, like navigating between routes. How can I get the cookie to work for client side requests? Any ideas? |
Saw that I replied in this thread and encountered this same thing not that long ago, again. |
Environment
Darwin
v18.13.0
3.1.1
2.1.1
[email protected]
vite
debug
,ssr
,css
,build
,vite
,modules
,runtimeConfig
()
-
Describe the bug
Fetching data from Apollo server works only after refresh.
On Page loading, the setup function doesn't fire the request to the Apollo server, but it waits until a refresh is performed.
The request then appear in the console network, and everything works fine (on page loading the request/fetch doesn't exist).
This happens only when the ssr option is set to true in nuxt.config (by default it is set to true). The behavior changes, and the fetch is performed also on page load when the ssr option is set to false (clearly).
Expected behaviour
I would expect that the first time I load a page, the request is normally performed to the apollo server, in this way I can populate the page with the data.
Reproduction
Someone in December opened an issue and tagged it as BUG, unfortunately the issue was closed just before the end of the year without a real resolution. For reference the following is the link to the issue:
https://github.com/nuxt-modules/apollo/issues/452#issue-1451729190
Additional context
I tried to investigate a bit the issue, and I noticed that under the hood, the module uses the useAsyncData (form the nuxt composable). This is amazing but it's worth probably point out that (the yellow alert in particular):
Maybe the problem is just here??
Logs
No response
The text was updated successfully, but these errors were encountered: