The ability to use observables as query variables was very convenient from #62 .
With the move to apollo-client 2.0 and apollo-angular 1.0, this feature seems to have been dropped.
Are there plans/desires to re-implement it?
I'm going to implement this
Hi @kamilkisiela were you able to work on this or do you have a date in mind?
@kamilkisiela any background on why this feature was dropped when the 1.0.0 release was cut? Guessing it's due to architectural changes in v2. This is quite powerful for triggering multiple query updates (e.g. when current user id changes).
@kamilkisiela Is there a workaround for apollo-angular 1.0.0 until the feature will be re-implemented, so v1.0 can be used with observable parameters at the time?
@knorzel You can use switchMap and combineLatest rxjs operators to do basically the same thing.
@matthewerwin We dropped this because it can be done within a separate npm package. This way it could be opt in and maintained separately.
What is the npm package name? Curious how it adds this into the watchQuery method or if it's a new method...documentation seemed to indicate 5 LOC upgrade path but this has a pretty extensive impact on the upgrade and no documentation except in the release notes saying it was dropped in v1.0.0 with no other remarks
@kamilkisiela Thanks for the tipp. However, this would require manually re-implementing many queries in a large productive codebase and undoing these changes manually as soon as the functionality has been re-implemented...
Do you have an estimate when the feature will be available again? For now, my migration is stuck right in the middle, blocking the implementation of new features that all rely on apollo...
@kamilkisiela Can you explain how you would reimplement this using switchMap and combineLatest
That works like a charm, thanks! It would be nice to have the old behaviour back, though.
Agree with the above comment. Not very elegant but I suppose a wrapper can be written. Seems to make natural sense for watchQuery to have this behavior built in since the whole purpose is to be responsive to changes...either to cache or to variables driving the query itself.
Is there a planned release date yet? in my opinion this is one hell of a major feature when working with data / tables / filtering in general :/ I simply can't update until this is implemented
So is it going to be back in apollo-client at all?
@kamilkisiela How it's going with this?
Hi there!
A little update, I've been working hard in last two months on my own projects, those of _work for food_ type. Unfortunately I didn't have time to implement this feature as a separate package, maybe some of you could do it to help others since we are a community.
There is a "hidden" method in ApolloClient called setVariables. Hidden because it is not mentioned in any documentation or tutorial and others. I think you all can use it. Check out the behavior.
I created a simple example that should be useful. It's on stackblitz.
There is also setOptions method that could be useful too :)
I'm using your example to implement filters in my app and I must say this is way more intuitive and comfortable than it was < Apollo Angular 1.0
What's missing is an updateVariables method (IMO) that merges a new set of variables with the old one
Example:
My initial filter always needs to be filter: { statusComplete: false }
Additionaly the user is able to filter countries filter: { country_contains: '...' }
With setFilter I always have to set statusComplete again
updateFilter could allow the behavior to overide the existing variables
What do you think @kamilkisiela?
Also, I'm not sure if we need an additional implementation of something around this.
What I'm doing is to watch my filters - if they change I call something like setFilterVariables which updates my variables.
@kroeder you could create an Observable with comineLatest and switchMap to make it happen. In conbineLatest you would combine each variable and execute setVariables in switchMap
We also stumbled upon this regression when migrating our project. We ended up implementing some kind of wrapper to still be able use observable variables. But there are multiple catches...
First of all setVariables() incorrectly never return a result coming from cache. This is visible in @kamilkisiela stackblitz example. If you click "Tom Coleman", then "Sashko Stubailo", then again "Tom Coleman", it will actually not change back to "Tom Coleman". Hopefully it will be fixed in apollo-client.
Second, if using fetchPolicy: 'cache-and-network' to avoid previous bug, then when setting new variables, it will immediately returns the old result with the loading flag to true, and only then the new result with loading flag to false will be returned. It seems this is by design, but it might still be very unexpected to ask for something and be given something else entirely. And this could lead to bugs in our apps. Of course we could filter out all results that are marked as loading. And this might even help to avoid re-rendering the page too often. But that still something we should be aware of.
Not sure if setVariables() should work as @PowerKiKi explained or it is a bug. We had to move to refetch() because of that, which is not complete solution also.
@milosbr do you mean the fact that you first get old results for new variables ?
@PowerKiKi
Nope, refetch() acts the same as setVariables() and we just check if loading is false to process the data.
I was talking regarding setVariables() and cache issue
I meant that refetch() works with every fetchPolicy (except 'cache-only') but it's costly,
while setVariables() works only with 'cache-and-network'. Even fetchPolicy: 'network-only' won't work.
Did anyone achieve to re-implement observable variables in a global, comfortable way, i.e., without adding switchMap etc. to every single query?
I'm still struggling with this issue, blocking me from migrating to the latest apollo versions...
@knorzel Same here. I'm also waiting for this to make progress and sticking to the old version which I do not find very nice to be honest. Last time I tried to migrate, I rand into some issues and decided that it is probably not worth the hustle. Hearing the fetch-policy issues does not make me comfortable enough to try again.
I also hope that other people could show how they solved it. (assuming there is a solution like that)
I changed everything to work with setVariables and refetch
See stackblitz example in https://github.com/apollographql/apollo-angular/issues/425#issuecomment-357047883
I got a Subject for my FilterForms I am subscribing to.
Everytime the Subject.emit(withNewQueryFilterVariables) I am passing them to my queryRef QueryRef<Query, QueryVariables>;
// Check against cache
myFilterSubject.subscribe(newFilterVars => this.queryRef.setVariables(newFilterVars);
// Re-Fetch without respecting the cache
myFilterSubject.subscribe(newFilterVars => this.queryRef.refetch(newFilterVars);
Does the job quite good for our angular apps.
The issue with setVariable and setOptions is related to apollo-client, would be nice to solve it so you all could use those instead of Subject.
You can all make some noise in this issue apollographql/apollo-client#2712 :loud_sound: :loudspeaker: :writing_hand: :+1: so it will be heard :)
Even better than making noise on the issue would be to help with the work in progress PR: https://github.com/apollographql/apollo-client/pull/2973
Thanks for the replies, but for me, the problem is the following:
One behavior of the observable variables in v1 was the following: the queries were not fired until all observable variables had been resolved. So I was able to set-up a query at loading time and it got executed when all data was present.
The workaround with setVariables now would require that I wait for the data to be present (e.g. using combineLatest) until I can create the query (otherwise, the queries are fired with required parameters set to NULL).
Therefore for me, the solution with setVariables is not working, or am I wrong? Is there a way to create a QueryRef, subscribing to it and waiting with executing the query until it should be executed?
I thank you @knorzel, I was just about to talk about this very problem here. I was wondering why nobody talked about required parameters in this thread. I am curious too.
Hi @knorzel @Eraldo
I modified @kamilkisiela stackblitz example and added a helper functions to accommodate the need for all variables to resolve.
You can find the code here https://stackblitz.com/edit/apollo-angular-example-variables-ncbwch
Hope that it helps for now :)
I'm closing this one, if someone wants to create a PullRequest or mention it in the docs then I'm happy to help with :)
I think that using variables as an Observable is awesome but this is something that could be done outside of Apollo's scope. I think it's better to have an Observable that emits an object with variables and then it passes the object to apollo.watchQuery.
New issue to make noise in: https://github.com/apollographql/apollo-feature-requests/issues/25
Most helpful comment
Is there a planned release date yet? in my opinion this is one hell of a major feature when working with data / tables / filtering in general :/ I simply can't update until this is implemented