Created by: eseliger
Observations:
Monitoring the networkStatus, we get
refetch
and
ready
all the time for the refetches. This is alright, as we do polling on this list.
*
Then, when we hit fetchMore, while it's refetching, we get the following:
networkStatus refetch
networkStatus ready
networkStatus ready
networkStatus ready.. So for some reason the ready event is emitted thrice. This caused the flickering we saw before.
When we don't notifyOnNetworkStatusChange, the flickering is entirely gone.
When the flag is ON, we see the following:
networkStatus refetch
networkStatus fetchMore # additional
networkStatus refetch # additional
networkStatus ready
networkStatus ready
networkStatus ready
networkStatus setVariables # from here on more state changes
networkStatus refetch # probably from polling
networkStatus ready
networkStatus setVariables # why this 3 more times?
networkStatus setVariables
networkStatus setVariables
networkStatus ready # after this, no more flickering and the regular refetch -> ready loop starts againWhen switching from no-cache to network-only, apollo starts logging a warning about the fact that the workspace resolution has no ID. I went ahead adding that, and the warning went away. I don't really want to expose an ID on it, but I guess I have to?
Using no-cache logs an error in our useConnection hook. Using the debugger, it seems that the previousResult is lacking fields. When no-cache is on,
the previous result would never be written to the cache.. so why is this function ever called with something?
When using network-only with the same debug halting point as above, the list does NOT properly update. When the debugger is off, it works.
Is there a race condition?
The notifyOnNetworkStatusChange according to apollo docs is REQUIRED for the loading state to be correct ..
First, why is that, that is very counterintuitive
Second, when it's on WAY more events are emitted though and some of them seem useless for what we want to achieve.
3x setVariables in a row? But AFTER the refetch has finished?
.. Actually, the docs say it should be poll -> ready, not refetch -> ready
OKAY, seems like we run refetch on an interval, instead of actual apollo polling.
That is, because we want to refresh ALL pages.
Could there be some race condition here?
I just added a condition that we don't refetch when some other request is currently ongoing, and that reduced the flicker by a bit
Now we have only one weird setVariables call left.
.. when notifyOnNetworkStatusChange is set to false, we have no more weird state refreshes.
.. according to the docs, notifyOnNetworkStatusChange only returns the networkState but shouldn't alter loading? So is it unnecessary here?
Now for the first time since starting this debugging endeavor, I got a warning message that updateQuery is deprecated.