Something went wrong on our end. Please try again.
Created by: courier-new
Fixes the problem observed in the UI when loading additional workspaces from the execution list with the "show more" button where sometimes no additional workspaces would appear. This is due to the response with the extra page of paginated data "fighting" with the response from the regular polling request for the already-loaded pages.
So, shouldn't Apollo Client be smart enough to handle that? Turns out there's a couple things going on here that make the situation non-ideal:
id
to identify a BatchSpecWorkspaceResolution
by
BatchSpec
node
node
type and then providing a nested query to its workspaces. This makes custom field policies, such as those which are typically recommended for properly merging paginated data in Apollo Client So, how do we get around this?
pollInterval
and fetchMore
at the same time.
BatchSpecWorkspaceResolution
https://user-images.githubusercontent.com/8942601/186096225-5eaa7e39-b175-43d0-aa26-61f1894dfb51.mov
The one (big) annoyance with this technique is that the Apollo Client cache doesn't seem to work the same way in the Storybook stories environment, so our workspace lists are in stories are... empty.
Of course, we could have ditched Apollo Client and reverted to the old requestGraphQL
request style or something else for this query, but this didn't feel like the right call because:
It's probably worth porting this solution to the changesets list on the batch change detail page, as well. This problem also impacts that list, but it happens a lot less frequently, it seems, so that's a lower priority. I'll write up an issue for this.
I'm also going to be writing up a more general issue about improving our polling strategies to more effectively take advantage of the cache.
Extensive manual testing.