Add ability to do a one-off query

[stubailo]

Right now you can call watchQuery then stop once you get the data, but that's not optimal.

[jbaxleyiii]

@stubailo do you think it would be confusing if we have a query method on the client? watchQuery is more descriptive of what the method does for sure, just don't want to cause confusion between creating a query.

Counter point would be that query and watchQuery will return drastically different things so there is no point in unifying the calling method. It would do more harm than good. They both seem like accurate explanations of what the method does.

query should return a promise that resolves to be the full result of the query, even if it is a merged cache + remote hit.

[stubailo]

Yeah I agree, these are separate methods, since one returns a fancy handle and the other will return a simple promise. IMO having both query and watchQuery methods is fine. Realistically, the end developer might not be using watchQuery much, since they will probably be using the view integration?

I think we should have consistent options where possible though, like whether to use the cache.

One important question - does query use watchQuery as the implementation, or does it do something else?

[jbaxleyiii]

hmmm, if it does, it comes down to a simple sugaring of watchQuery with a promise and self cleanup. I think the initial run could be that exactly. I'm not sure of the performance gains by bypassing the watch methods internally?

It shouldn't be a lot of overhead?

What if I'm watching a query, and also want to do a direct query of what will boil down to the same queryId? If it's just sugaring, the deregistration would remove the watched query handle yes?

[stubailo]

What if I'm watching a query, and also want to do a direct query of what will boil down to the same queryId?

Right now, if you do the same query twice, it will have two different query IDs, so this isn't a problem. I think the efficiency benefits of deduplicating queries and doing ref counts would be pretty minimal in the current architecture.

[jbaxleyiii]

const queryId = this.idCounter.toString();
this.idCounter++;

duh James

Seems easy enough! @johnthepink can probably knock this out tomorrow then because he is 🚀

[fikriauliya]

Right now, if you do the same query twice, it will have two different query IDs, so this isn't a problem. I think the efficiency benefits of deduplicating queries and doing ref counts would be pretty minimal in the current architecture.

@stubailo it doesn't happen in the case of server prerendering whereby apollo store is pre-populated with query running on server. (#759)

The client request would starts from zero again, effectively overwrite the 0th query on Store.

[helfer]

@fikriauliya Actually, we don't need to send the query store to the client when doing SSR. The client initializes its own queries, so any existing queries in the store are completely useless. Could you make a PR to remove the query store from the data that's sent to the client when doing SSR? That would be great! 🙂