Open PowerKiKi opened 9 months ago
@PowerKiKi that is an interesting idea!
I can understand why from an Angular perspective this might be beneficial, but I hesitate to remove it completely. Interestingly enough, I don't think we recommend client.query()
enough on the React side where it would be easier for our users to use in certain situations. We tend to have some overuse of useLazyQuery
where a client.query()
would be much more suitable.
Definitely something we will discuss as a team though. Appreciate the suggestion!
I would like to suggest dropping
ApolloClient.query()
entirely in the next major version. And instead all queries would have to usewatchQuery()
(which could potentially be renamed...).The first reasons for this is to reduce the API surface that has to be learned. Because
watchQuery()
is pretty much a mandatory thing to learn if we want to leverage Apollo cache system, that means that pretty much everybody is already familiar with it (and its concept of emitting multiple results in time). As I see it,query()
is a less-flexible subset of ofwatchQuery()
. And the sooner you understand that Apollo can, and should, emit multiple results over time, the better your overall DX will be.Of course as it would reduce the API surface, it would simplify future maintenance of the library quite a bit. Eg, we wouldn't need
FetchPolicy
vsWatchQueryFetchPolicy
. It would also most likely (slightly) reduce the bundle size.This change would go especially well with the migration to rxjs, since we could reproduce the original behavior of
query()
with something like:It is not required to migrate to rxjs to make this breaking change, but rxjs syntax makes this much more reasonable.
I realize this will be a major change of habits, but that's what major versions are for, and the introduction of rxjs makes it a good time to do it.