Intended outcome:
When using local @client
state as a query variable via @export
I would expect that changing that state would cause the query to re-run (as the variable has changed and it shouldn't be in cache).
Actual outcome:
The query does not re-run. Using @client(always: true)
doesn't help, nor does changing fetchPolicy
.
How to reproduce the issue:
Using Query
component (haven't tried as a HOC) write a query using @client @export
, and inside that component have some event change client state with writeData
. The query will not re-run.
However doing something else to cause the component to re-render will cause the query to re-run, it's just not automatically tracked by Apollo. In the example I increment the Query component's key
to force it to re-render, and then Apollo re-fetches the query with the new state.
https://codesandbox.io/s/o57v4x1x25
Versions
System:
OS: macOS 10.14.3
Binaries:
Node: 11.9.0 - /usr/local/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 6.5.0 - /usr/local/bin/npm
Browsers:
Chrome: 72.0.3626.119
Safari: 12.0.3
npmPackages:
apollo-cache-inmemory: ^1.5.1 => 1.5.1
apollo-client: ^2.5.1 => 2.5.1
apollo-link-http: ^1.5.9 => 1.5.11
react-apollo: ^2.4.1 => 2.5.1
In my case even refetching does not seem to work (but I did not try in isolation).
Yes I've had much bigger issues with @client
in general since 2.5
but the @export
case is the only one I was able to reproduce in isolation. I'm hoping that fixing this will fix the other issues too if they all stem from the same root.
I'm so frustrated right now, 2.5 local state seemed so cool :)
Sorry to hear of your frustration @jide! I'll post back with an update on this shortly (I'm tackling this and a few other 2.5 issues today). Thanks!
That's what happens when such great features are announced ;) Awesome !
Hello everyone
We're having the same issue in our app. Interestingly if I console.log the log shows the newly fetched data as well as the correct local state variable, gathered via @export, for our query.
But no update on the component itself.
Side nodes:
Cheers
Don't post the "any update on this ?" comment, don't post the "any update on this ?" comment, don't post the "any update on this ?" comment. Just don't.
........any update on this ?
while we wait, my workaround for lit-apollo use cases.
in this example, I export the query
property.
I use the updated
lit-element lifecycle to check if the client variable (query
) is out of sync with the element's data.
/** @inheritdoc */
updated(changed) {
// HACK: workaround for https://github.com/apollographql/apollo-client/issues/4530
const newData = changed.get('data');
if (!newData || !this.data) return;
if (newData.query !== this.data.query) {
this.subscribe();
}
}
May I suggest that this bug is explicitly mentioned in the docs or this part removed in the meanwhile ? This is misleading for newcomers, who may spend some time trying this feature while it is broken.
I'm experiencing the same issue in my application. Can't seem to get this working in a single query
We have a solution for this ready in https://github.com/apollographql/apollo-client/pull/4604, but we're going to get those changes out in an apollo-client
2.6.0 release. We're still finalizing a few other things in that release, but will have this all resolved shortly.
As @hwillson indicated above, this problem should be fixed if you update apollo-client
to version 2.6.0-beta.2 (just released): https://codesandbox.io/s/nnxwn0r5ml
We're not quite ready to release [email protected]
officially, but that will happen faster if folks can help us test the beta versions. 🙏
Above repro fixed with 2.6.0. Also correctly uses loading
state, which is amazing. Thank you so much and looking forward to release
https://stackblitz.com/edit/apollo-client-local-state-export-repro-260-beta2?file=my-element.js
Beta fixed issue for me, but fetchPolicy: 'network-only'
causes initial loading to stuck:
https://codesandbox.io/s/8znyn79n80 (Items.jsx:60)
upd: 2.6.0-rc1 still suffering from this
There seems to be some sort of caching issue with this solution - it sends a network request every time, regardless of whether that item has already been fetched.
Switching back and forth between the options here repeatedly sets loading
to true https://codesandbox.io/s/012rnvnrrw.
Is this intended behaviour?
Something I encountered was that if the query encounters an error initially it will not rerender, even once the state is set correctly. Using errorPolicy: 'ignore'
seems to work in most cases.
@jwld Can you open a new issue with that reproduction? I think I know what's going on, but the solution will be different from the one for this issue (as originally reported).
HI,
I am using a @client @export variable as input of a @local resolver.
The reactivity and input parameters to the resolver are fine and the local resolver re-runs correctly .
However the new updated value returned by the @local resolver is not being passed to the component, even though the update function in the component is called correctly the actual response value being passed to the component as argument remains the same.
Has anyone spotted this behaviour before ?
PS: working with VUE.js
@fedeee I would love to look at a reproduction of that issue if you have time (and please open a new issue if/when you do)!
Closing since we just published the final version of [email protected]
to npm, including some improvements around the functionality discussed in this issue. While there may still be related issues that are worth addressing, let's continue those discussions in new issues. See CHANGELOG.md
if you're curious about the other changes in this release.
Is this working properly yet?
@NinjaOnRails This is fixed with v3. I'd suggest that you guys upgrade. It may persist in v2
@NinjaOnRails This is fixed with v3. I'd suggest that you guys upgrade. It may persist in v2
@bke-daniel apollo-client v3 isn't released yet. The latest version is 2.6.4
@NinjaOnRails This is fixed with v3. I'd suggest that you guys upgrade. It may persist in v2
@bke-daniel apollo-client v3 isn't released yet. The latest version is 2.6.4
Yes, your're absolutely right. Had the npm page for react-apollo open. Sorry for messing it up!
But, in the provided example he's using, for sure, the provider from react-apollo. If your going to fork the sandbox and update react-apollo to 3.1.1 and graphql-client to 2.6.4 then you'll that his example is working properly.
https://codesandbox.io/embed/apollo-client-error-template-ohu5q
I've updated the line 65 in App.js as well.
@NinjaOnRails This is fixed with v3. I'd suggest that you guys upgrade. It may persist in v2
@bke-daniel apollo-client v3 isn't released yet. The latest version is 2.6.4
Yes, your're absolutely right. Had the npm page for react-apollo open. Sorry for messing it up!
But, in the provided example he's using, for sure, the provider from react-apollo. If your going to fork the sandbox and update react-apollo to 3.1.1 and graphql-client to 2.6.4 then you'll that his example is working properly.
https://codesandbox.io/embed/apollo-client-error-template-ohu5q
I've updated the line 65 in App.js as well.
Check out the issue I opened as well. I'm trying to use the Local State field, which is an array, as a variable of a remote Query, which accepts an array as a variable. When I change the Local State (by adding a value to the array, the same happens when removing values from the array btw), the Query refetches with the new array of values (the Local State field) once. On every subsequent Local State change, the Query no longer refetches.
Most helpful comment
........any update on this ?