I use recompose pattern to organize my react components.
const isLoading = ({ loading }) => loading;
const EditQA = compose(
withEditReducer,
withGetQALib,
withGetQAPairsPaging,
withDeleteQAPairs,
withHandlers(handlers),
branch(isLoading, renderNothing),
)(_EditQA);
The withGetQAPairsPageing
HOC is declared as below:
const withGetQAPairsPaging = graphql(queries.getQAPairsPaging, {
options: ({ match }) => ({
variables: {
libId: match.params.id, ...DEFAULT_GET_QA_PAIRS_VARIABLES,
},
}),
props: ({
data: {
getQAPairsPaging: {
current,
total,
pageSize,
qaPairsPaging,
} = {},
refetch,
},
ownProps: {
match,
dispatch,
state: {
isTableLoading,
},
},
}) => ({
qaPairs: qaPairsPaging,
current,
pageSize,
total,
onPageChange(pagination) {
dispatch(setTableLoadingState(true));
refetch({
libId: match.params.id,
pageNo: pagination.current,
pageSize: pagination.pageSize,
})
.then(() => dispatch(setTableLoadingState(false)))
.catch(() => dispatch(setTableLoadingState(false)));
},
}),
});
The above code's feature is simple and easy to reason about. It provides a table component with paging functionality.
I've dived into the source code of apollo-client
a little bit.
I found that this statement in my code,
dispatch(setTableLoadingState(true));
, caused the whole component to re-render which then
caused the Query.componentWillReceiveProps
to call updateQuery
method.
Since the query variables had changed(pageNum was changed), ObservableQuery.setVariables
then triggered this.queryManager.fetchQuery
and made requestId
increased by 1 which resulted in the conditional expression requestId >= (lastRequestId || 1)
in fetchQuery
failed when the actual request had finished.
The consequence of failing the above condition is the _this.setQuery
in fetchRequest
function would never be called and result of this request was accidentally discarded. That's why the table stayed unchanged.
Intended outcome:
The table content changes to the next page after clicking the next button.
Actual outcome:
The table content stays unchanged after clicking the next button.
How to reproduce the issue:
Versions
System:
OS: macOS High Sierra 10.13.4
Binaries:
Node: 8.9.4 - ~/.nvm/versions/node/v8.9.4/bin/node
npm: 6.0.0 - ~/.nvm/versions/node/v8.9.4/bin/npm
Browsers:
Chrome: 66.0.3359.181
Safari: 11.1
npmPackages:
apollo-cache-inmemory: ^1.1.12 => 1.2.2
apollo-client: ^2.2.8 => 2.3.2
apollo-link: ^1.2.2 => 1.2.2
apollo-link-batch-http: ^1.2.2 => 1.2.2
apollo-link-error: ^1.0.9 => 1.1.0
apollo-link-schema: ^1.1.0 => 1.1.0
apollo-server-koa: ^1.3.4 => 1.3.6
react-apollo: ^2.1.4 => 2.1.4
refetchQueries has caused me so many headaches since moving to apollo...
Is this related to (or perhaps the cause of) apollographql/react-apollo#1929?
I tried a simple React <Query>
example based off the docs, and refetch()
doesn't update the store. Updating to the latest packages didn't help.
@dendrochronology Are you able to share the quick sample app you put together, that shows this happening? Any form of repro would greatly help here (you can use https://codesandbox.io/s/7361K9q6w as a starting point if that helps). Thanks!
In setting up an example, I realized that fetchMore
has the behavior that I was expecting. I still may try to reproduce, as I understand refetch
should still update the store with new results.
Refetch don't work for me, i pass variables and doesn't update store
refetch is returning new data in the console for me, but is not updating the props of the components grabbing it or using the query we're refetching
Same issuehere
If anyone here can supply a reproduction that demonstrates this issue, I'll be happy to take a look. Closing for now though since we haven't received a repro. Thanks!
Updates ?
Most helpful comment
refetchQueries has caused me so many headaches since moving to apollo...