useQuery hook returns empty data on first render with cache

[iankberry]

I'm running into a certain behavior that does not appear to be intentional. The scenario is that I have a list of events that are fetched with useQuery. For this example, the events are already in the cache.

Here is the result of me logging the 'data' and 'loading' params on the first two renders:

Render 1:
Loading? true
Events:  null

Render 2:
Loading? false
Events:  {energyEvents: Array(12)}

If I swap out apollo-augmented-hooks for apollo/client, it looks like this:

Render 1:
Loading? false
Events:  {energyEvents: Array(12)}

Render 2:
Loading? false
Events:  {energyEvents: Array(12)}

Here's my call to useQuery:

const { data: energyEventsData, loading: energyEventsLoading, refetch: refetchEnergyEvents } = useQuery<GetEnergyEventsResponse>(GetEnergyEventsQuery, {
        fetchPolicy: 'cache-first',
        reducedQuery: false,
        pollInterval: getApiPollInterval(),
        variables: {
            interval: 'ALL',
        },
    });

    console.log('Loading? ' + energyEventsLoading)
    console.log('Events: ', energyEventsData);

[mindnektar]

This happens because you have set a pollInterval. apollo-augmented-hooks assumes that when a pollInterval is set, fresh data is more important than performance, so rather than waiting for the duration of the poll interval until the first poll request is executed, it makes a request immediately (by using a cache-and-network fetchPolicy and a cache-first nextFetchPolicy whenever a pollInterval is set). You brought to my attention the fact that I haven't documented this anywhere, and I apologise for that. I'll do that soon.

Is this a behaviour that you agree with or would you prefer an option to disable it?

[iankberry]

apollo-augmented-hooks assumes that when a pollInterval is set, fresh data is more important than performance

I can see your point, but I'm not sure that this assumption holds true in all cases. My take on the polling interval is more making sure the data stays fresh without necessarily having an opinion about how the data is initially fetched given that's what fetchPolicy is for.

Oh and fwiw my example above might be a little misleading here. The actual code generally uses cache-and-network and I still see the same results w/ both libraries in that case as well.

[mindnektar]

Fair points there. I've decided to remove this behaviour, given that (a) personally I've stopped using polling entirely in my projects, (b) it's easy enough to achieve the same thing in user land, (c) this behaviour isn't documented yet and (d) this library is young enough that probably nobody will mind or even notice. :)

I'll keep the issue open until I do. Thanks again for your input!

[mindnektar]

Fixed in v1.11.2

[iankberry]

Thanks for making this change! Unfortunately I'm still seeing the same behavior/output above with 1.11.2. That is, on the first render data is emitted as null regardless of the fetchPolicy and whether pollInterval is specified. Is this expected? I did confirm that it updated properly as well:

diff --git a/yarn.lock b/yarn.lock
index 10deb7a..9b75498 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -68,7 +68,7 @@ __metadata:
     "@typescript-eslint/eslint-plugin": ^4.17.0
     "@typescript-eslint/parser": ^4.17.0
     add-asset-html-webpack-plugin: ^3.2.0
-    apollo-augmented-hooks: ^1.11.1
+    apollo-augmented-hooks: ^1.11.2
     apollo-cache: ^1.3.5
     apollo-cache-persist: ^0.1.1
     babel-loader: ^8.2.2

[mindnektar]

Yep, there was actually a separate bug in there that caused cached data to only be returned on the second render. Fixed it in v1.11.3, thanks for the heads up!

[iankberry]

Works great now. Thanks again for your help!