Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid view integrations tracking loading state manually #342

Closed
stubailo opened this issue Jun 30, 2016 · 7 comments
Closed

Avoid view integrations tracking loading state manually #342

stubailo opened this issue Jun 30, 2016 · 7 comments

Comments

@stubailo
Copy link
Contributor

Right now, it seems like both react-apollo and angular2-apollo are tracking loading state by doing manual bookkeeping. But this doesn't seem optimal, because:

  1. Apollo Client already keeps track of loading state internally
  2. Some options to watchQuery, for example returnPartialData, might return data while loading is still true, confusing the view integrations

I think we should have a way to get the loading state from apollo directly, so that other libraries don't have to guess what it is.

@jbaxleyiii @kamilkisiela do you have some ideas for how it should be best returned? Some ideas:

  1. Apollo Client returns a queryId, and has a getLoadingState method
  2. The observable returned by watchQuery has a getLoadingState method
  3. The result from the observable, which is currently a GraphQLResult with data and errors, can get a new property, loading

I think (3) is the best, would doing that be enough to remove the need to keep track of loading state in react-apollo and angular2-apollo?

@kamilkisiela
Copy link
Contributor

@stubailo Totally agree that loading state should be delivered to UI integrations directly from ApolloClient.

3rd option seems to be the best one.

would doing that be enough to remove the need to keep track of loading state in react-apollo and angular2-apollo

Yes, it would 👍

@davidwoody
Copy link
Contributor

@stubailo It seems like #385 has added the queryId to the result of calling watchQuery, so the queryId can now be used to read directly from the state of apollo.queries.

@stubailo
Copy link
Contributor Author

Oh, awesome! I didn't even notice. I should publish a new version with all of these changes.

@davidwoody
Copy link
Contributor

@stubailo haha yeah same, I was about to open up a PR for that tweak, but noticed the new changes in master beat me to it! I added a note to the changelog - #405

@kamilkisiela
Copy link
Contributor

@stubailo Do we stay with queryId and apollo.queries or there's going to be that 3rd option implemented?

The result from the observable, which is currently a GraphQLResult with data and errors, can get a new property, loading

kamilkisiela/apollo-angular#43

This was referenced Jul 25, 2016
@jbaxleyiii
Copy link
Contributor

@stubailo @kamilkisiela I would love for this to be done!

@Poincare
Copy link
Contributor

This should be fixed through #467 and then we can work on implementing the required changes within the view layers

@Poincare Poincare closed this as completed Aug 2, 2016
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants