Handle loading states for queries that were fired before the subscription is set up

[qwertvasilii]

Im facing not handled query when application starts up, logging in reducer spit out only successful ended query, but didnt catch start of this query
any solution on this?

[amannn]

Hi @qwertvasilii, thanks for bringing this up. I'm aware of this, but I didn't work on the fix yet.

I'll see if I can provide a fix after the 3.0 PR is merged.

[qwertvasilii]

Any progress on that?

[amannn]

Not yet, I'm not sure yet what the best solution for this is.

The issue is basically this:

For a given component tree we append a link that receives all Apollo requests. All operations are passed to the Dispatcher. The available hooks subscribe to the dispatcher in useEffect. However Apollo calls queries during render.

The queries that are immediately called during the first render are available to the dispatcher, but will be missed in the hook subscription since it is set up too late.

I can think of two potential solutions based on this:

1. Set up the link subscription in render. I'm not sure yet how well this plays with concurrent mode, but Apollo does a similar thing anyway.
2. Keep a queue in the dispatcher that can be read from once a subscription is set up. Per component tree there's one dispatcher but potentially many subscribers. The subscribers would need to ensure that they only process every operation once and also we'd have to cap the queue somewhere, otherwise this would increase the memory indefinitely.

The first solution would help with the initial render use case but if you purposefully mount a subscription at a later point, you'd still have missed events.

The second solution works for lazily mounted components but can still not ensure that every single operation is processed due to the capping of the queue.

Current options to avoid this issue with the latest version of react-apollo-network-status are:

1. Use server side rendering with data fetching (i.e. there will be no queries fired when the client renders initially).
2. Lazy-render the data components in a second step once the subscription is set up.

@qwertvasilii Can you elaborate a bit on the circumstances where you're seeing the issue? What does the component tree look like with the Apollo hooks and the subscription hook from react-apollo-network-status?

[amannn]

There's a reproduction for this issue in #36. Thanks to @github0013!

[ab-pm]

Keep a queue in the dispatcher that can be read from once a subscription is set up. Per component tree there's one dispatcher but potentially many subscribers. The subscribers would need to ensure that they only process every operation once and also we'd have to cap the queue somewhere, otherwise this would increase the memory indefinitely.

I wouldn't keep a queue of all requests in the dispatcher, but only the NetworkStatus value (that is otherwise computed in useApolloNetworkStatus). I think most users of the library would expect the network status to be global (coupled to the link) and always to be the same value regardless in which component the hook is used.