-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Simulate loading result for original query before fetchMore. (#6583)
Should fix #6354, #6542, #6534, and #6459. Reliable delivery of loading results is one of the core benefits that Apollo Client strives to provide, especially since handling loading states tends to be such an annoying, error-prone task in hand-written state management code, and Apollo Client is all about keeping hand-written state management code to a minimum. Ever since I refactored the FetchPolicy system in #6221, the fetchMore method of ObservableQuery has not been delivering a loading state before sending its request. Instead, the observed query was updated only once, after the completion of the fetchMore network request. I've been aware of this problem for a while now, but I procrastinated solving it because I knew it would be, well, annoying. With the final release of AC3 right around the corner (Tuesday!), the time has come to get this right. This loading result doesn't fit neatly into the fetchQueryObservable system introduced by #6221, since the consumer of the loading result is the original ObservableQuery, but the network request gets made with a fresh query ID, using different variables (and possibly even a different query) passed to fetchMore. This separation is important so that we don't have to change the query/variables/options of the original ObservableQuery for the duration of the fetchMore request. Instead, the fetchMore request is a one-off, independent request that effectively bypasses the usual FetchPolicy system (technically, it always uses the no-cache FetchPolicy). In Apollo Client 2.x (and before #6221 was released in beta.46), this logic was guided by an extra fetchMoreForQueryId parameter passed to QueryManager#fetchQuery, which ended up appearing in a number (16) of different places, across three different methods of the QueryManager. I think it's an improvement that the logic is now confined to one block of code in ObservableQuery#fetchMore, which seems naturally responsible for any fetchMore-related logic.
- Loading branch information
Showing
3 changed files
with
67 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters