Changing variables in watchQuery after polling started

[timsuchanek]

Hi,
so I'm creating an observable with the client.watchQuery method and watch on it.
It works fine.
But let's say variables in my query changed.

How to properly handle that?
Do I really have to kill the old observable and create a new one which includes the new query?

In other words: How to change variables of a polling ObservableQuery in runtime?

Idea: Pass in an optional callback that returns the current variables.

I ask, because doing that kill/respawn approach would require a lot of refactoring in my code.

Thanks!

[Poincare]

Hi Tim. If you check out the relevant portion in src/QueryManager.ts:

 public watchQuery(options: WatchQueryOptions): ObservableQuery {
    // Call just to get errors synchronously
    getQueryDefinition(options.query);

    return new ObservableQuery((observer) => {
      const queryId = this.startQuery(options, (queryStoreValue: QueryStoreValue) => {
        if (!queryStoreValue.loading || queryStoreValue.returnPartialData) {

Since options is an object and you'd be passing a reference to the object itself, this could mean that just updating the keys/values in the object might be sufficient to change the variables the next time the query fires. This should be pretty easy to test - could you try it out?

Whether or not it works, it would be great if you could distill it into a unit test that we can use to guide this issue. Check out test/QueryManager.ts - that seems like a natural place for this unit test. Basically, you can use the mockNetworkInterface, set up a watchQuery and then modify one of the variables and assert whether or not the query was changed correctly.

[stubailo]

@Poincare I think mutating the variables is not the right approach long term, even though it might work now. I think we should encourage people to make those immutable, and perhaps provide a method to update the query options.

[Poincare]

Makes sense. I guess I will leave this issue open and we'll fix it soon.

[timsuchanek]

Hey guys, thanks for the fast answers.
@Poincare your solution works like a charm.
So do you want some unit tests or better later when there is a better api for this use case?

[stubailo]

You can help us design the API! What should it look like?

[timsuchanek]

Ha I'm pleasured to tell you my opinion for the API.

Ok, this is my use case:
I get params from react-router into my React component and pass them into an action, which is a redux-thunk, that then creates the observable and its subscription, parametrized by the params passed into the action by the component.

(Btw I'm aware of react-apollo, but I had some problems with error handling with it, so I decided for a pure redux/apollo-client implementation, as I just could move forward faster with this approach.)

So the first naive Idea I had, was to pass the apollo client a callback, that looks into the redux store and gets what it needs. Problem is: The url params of react-router are not available in the redux store.
They only get passed in into the component directly.
So we need a way that includes the component.
So the way I suggest is, that we add an explicit call on the observable, that updates the observable and if the user wants, directly performs a query afterwards.

Something like observable.updateVariables({vars}) would be really handy in this scenario.
Would do you think about it?

[stubailo]

Just trying to understand better - why not stop the previous observable and start a new one with new variables?

[Akryum]

Isn't this less efficient in terms of performance/memory?

[stubailo]

Not really - the overhead of creating an observable object is basically 0, everything else is handled by the cache almost exactly the same way.

[stubailo]

Or yeah, I guess there are also some extra things stored in Redux when you start/stop a query. So it could be less efficient, but we haven't run into that as a source of problems in our production apps. It's mostly React renders that are very costly.

[stubailo]

Done! #635