Intended outcome:
When querying similar data throughout an app, it should be possible to exclude the id field on nested queries. E.g. ({ people { id, name, pets { name } }).
Actual outcome:
However, if you have two similar queries in your app, one that includes the nested id and the other that excludes it, the mounting either component leaves it stuck in the loading state.
See these two components:
const ConnectedComponentOnPage1 = graphql(gql`{
people {
id,
name,
pets {
id,
name,
belonging {
id, # id is queried
name,
}
}
}
}`,
{ options: { fetchPolicy: 'cache-and-network' }))(ComponentOnPage1); // the cache-and-network policy is allow essential to reproduce
// Notice the component is on a different page. The important aspect is that is is unmounted. It seems that the error is only triggered when mounting/unmounting components.
const ConnectedComponentOnPage2 = graphql(gql`{
people {
id,
name,
pets {
id,
name,
belonging {
name, # no id queried here fails
}
}
}
}`,
{ options: { fetchPolicy: 'cache-and-network' })(ComponentOnPage2);
The second components, when mounted, never gets refreshed with the data from the server, even if it completes successfully. It looks like this could be a similar issue to #1389, #1186, and other issues in react-apollo like this one. Included/excluding the id in both places fixes the issue. Seems like the cache is having a problem looking up the nested object when there are queries with an id and without an id.
How to reproduce the issue:
Handy dandy reproduction in error template
Thanks all! Let me know how I can help.
An error message is thrown in createApolloReducer because it attempted to write an object with no id when the store already contained an id, therefore the state is never updated (the loading flag is never set to false) and and no warning is emitted.
thanks @cesarsolorzano. are you working on a solution to this? just checking to see if someone still needs to pick this up (I'm up for helping out as well).
@derek-duncan yes, I'm working on it! 馃檪
@derek-duncan so, just to be clear, at the moment, we are talking here about a lack of warning.
The error thrown is from writeToStore and it's swallowed in fetchRequest from QueryManager.
@cesarsolorzano yep looks like it 鈥撀營've never seen that error because it's being swallowed.
Most helpful comment
@derek-duncan yes, I'm working on it! 馃檪