In a test app I'm setting up to have SSR I get an error that the markup that is served (from the server) is different from the one generated on the client. (because on the client the loading property is true even if instantiated with false in the data method)
That message goes away when setting the loadingKey property to true, but then apollo doesn't call the graphql endpoint anymore. Any reason why that is?
To reproduce, change 0 to 1 or true in here https://github.com/Akryum/frontpage-vue-app/blob/master/src/PostList.vue#L48.
Won't you mind sharing your app code?
here it is https://github.com/matteodem/vue-apollo-loadingkey-bug, see https://github.com/matteodem/vue-apollo-loadingkey-bug/blob/master/src/app/components/About.vue#L43 for initialized loading value
any idea how to solve this?
Well I can't launch your app, I'll have to make a SSR version of frontpage when I have time.

Specified access path not found
oh. seems to work on OSX. isn't the simple reprodctuon description I have sufficient?
To reproduce, change 0 to 1 or true in here https://github.com/Akryum/frontpage-vue-app/blob/master/src/PostList.vue#L48.
It should just display "loading" and not load the data from the graphql endpoint.
adding apollo configuration like following helps:
posts: {
query: postsQuery,
loadingKey: 'loading',
watchLoading(isLoading) {
// TODO: remove this hack after resolving: https://github.com/Akryum/vue-apollo/issues/13
this.loading = isLoading;
}
},
but this shouldn't be required IMO.
The problem is here: https://github.com/Akryum/vue-apollo/blob/master/src/vue-plugin.js#L160
Do you remember any reason the if is in there?
If you don't define loadingKey in the apollo options.
ah yes. ignore that sorry
What's the reasoning behind using numbers instead of booleans for the loading key?
So that you can have multiple queries for one loading spinner. :smile_cat:
I guess it's just weird to me that the counter is set to 1 even before the component is mounted / rendered. That's why on the server it renders it with false (as in 0) and then the mismatch happens on the client.
Do you have any suggested solution to this? I'll happily submit a PR later today
The q function is called the first and then every time Vue dispatch a change in the reactive data inside the variables function. This in turns increment your loadingKey property. This means that as soon as your component's created is called, a query is sent and the counter equals 1. It may be the reason you have a mismatch in the HTML, since it was 0 on the server, and before the component is mounted it will be 1.
We may have to make a server-side version of the package to increment the value of loadingKey for each query defined on the component only on the server, so it matches the client.
We could also add the option to run the queries on the server. What results do you get by installing the Vue plugin in your server-side code too?
I get errors when running it on the server
Error sending the query undefined ReferenceError: fetch is not defined
at HTTPBatchedNetworkInterface.HTTPFetchNetworkInterface.fetchFromRemoteEndpoint (/Users/Matteo/Projects/personal/relaxstack/kits/standard/src/networkInterface.ts:186:12)
Since fetch is only available in a browser, try installing node-fetch and exposing it globally:
import fetch from 'fetch'
global.fetch = fetch
awesome! so with loading: false by default it now loads all the data on the server side before delivering the result. Even though that's great, it doesn't serve the same markup on the client.
(on the client it's loading for a split second and on the server it's not loading at all as it already has the data)
probably need to get this to work with vuex to have a consistent state on the server and client. unless you have another idea
Could you try with the latest version of vue-apollo?
What can I try?
If there are still issues with loadingKey like described in the original post, since I rewrote that feature recently.
Please re-open if you still have this issue.
Most helpful comment
adding apollo configuration like following helps:
but this shouldn't be required IMO.