You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Intended outcome:
The networkStatus value that comes from the useQuery hook should immediately change to NetworkStatus.refetch as soon as the refetch function is called.
Actual outcome:
There is some delay between when the refetch function is called and the networkStatus value is updated to NetworkStatus.refetch.
Initially, I am not using the networkStatus value to calculate if the query is refetching.
In this case there is no issue with the "pull to refresh" functionality.
Everything works as expected.
If you tap on the toggle and start using networkStatus === NetworkStatus.refetch to calculate if the query is refetching, you can see that the "pull to refresh" animation is janky and makes the content jump up and down.
I found the same effect can be achieved if when onRefresh is called, instead of updating the refreshing value on RefreshControl immediately, you add a setTimeout(() => setIsRefreshing(true)), even without a time, you get the same result.
So my guess is that a process tick is going by between the time the refetch function is called and the time networkStatus is updated.
This is what causes the RefreshControl to end up with a janky behavior, which is not ideal.
const{loading, data,refetch: _refetch, error}=useListNotificationsQuery({...});const[refetch,isRefetching]=useRefetch(_refetch);// call refetch() to start a refetch, and check isRefetching for its status
I believe this may also reduce the number of re-renders required, because notifyOnNetworkStatusChange is no longer necessary.
Was pulling my hair out with janky refresh controls, took me some time to find the actual source of this behaviour and find this issue. @andreialecu solution works perfect.
Intended outcome:
The
networkStatus
value that comes from theuseQuery
hook should immediately change toNetworkStatus.refetch
as soon as therefetch
function is called.Actual outcome:
There is some delay between when the refetch function is called and the
networkStatus
value is updated toNetworkStatus.refetch
.RPReplay_Final1615761941.MP4
How to reproduce the issue:
I've created a snack to show visualize the error:
https://snack.expo.io/@david-arteaga/apollo-client-pull-to-refresh
Initially, I am not using the
networkStatus
value to calculate if the query is refetching.In this case there is no issue with the "pull to refresh" functionality.
Everything works as expected.
If you tap on the toggle and start using
networkStatus === NetworkStatus.refetch
to calculate if the query is refetching, you can see that the "pull to refresh" animation is janky and makes the content jump up and down.I found the same effect can be achieved if when
onRefresh
is called, instead of updating therefreshing
value onRefreshControl
immediately, you add asetTimeout(() => setIsRefreshing(true))
, even without a time, you get the same result.So my guess is that a process tick is going by between the time the
refetch
function is called and the timenetworkStatus
is updated.This is what causes the
RefreshControl
to end up with a janky behavior, which is not ideal.Versions
The text was updated successfully, but these errors were encountered: