On this page, you can learn how to use Apollo to attach GraphQL query results to your Angular UI. This guide assumes some familiarity with GraphQL itself. You can read about GraphQL queries themselves in detail at graphql.org.
One of our core values is “it’s just GraphQL.” When using Apollo Client, you don’t have to learn anything special about the query syntax, since everything is just standard GraphQL. Anything you can type into the GraphQL query IDE, you can also put into your Apollo Client code.
Basic Queries
When we are using a basic query, we can use the method in a very simple way. We simply need to parse our query into a GraphQL document using the tag from library.
For instance, in our example, we want to display a list of posts in component:
The method returns a object which has the property that is an .
We can see that the result object contains , a Boolean indicating if the query is “in-flight.” The observable will only emit once when the query is complete, and will be set to false unless you set the parameters to true. Once the query has completed, it will also contain a object with , the field we’ve picked out in operation.
It’s also possible to fetch data only once. The method of service returns an that also resolves with the same result as above.
Imagine you have two views (routes), one of them has the component. When you switch between views, you’ll notice that the list of posts loads instantly the second time. This is the Apollo cache at work!
What is
As you know, method returns an Observable that emits a result, just once. also does the same, except it can emit multiple results. (The GraphQL query itself is still only sent once, but the observable can also update if, for example, another query causes the object to be updated within Apollo Client’s global cache.)
So why doesn’t expose an Observable?
Apollo service and ApolloClient share pretty much the same API. It makes things easy to understand and use. No reason to change it.
In returns an Observable, but not a standard one, it contains many useful methods (like ) to manipulate the watched query. A normal Observable, has only one method, .
To use that Apollo’s Observable in RxJS, we would have to drop those methods. Since they are necessary to use Apollo to its full potential, we had to come up with a solution.
This is why we created .
The API of is very simple. It has the same methods as the Apollo Observable we talked about. To subscribe to query results, you have to access its property which exposes a clean RxJS Observable.
It’s worth mentioning that accepts two generic types.
Providing
The and methods expect one argument, an object with options. If you want to configure the query, you can provide any available option in the same object where the key lives.
If your query takes variables, this is the place to pass them in:
Using with
In Angular, the simplest way of displaying data that comes from Observable is to put on top of the property inside the UI. You can also achieve this with Apollo.
An Observable returned by holds the actual result under the field, so you can not directly access one of the properties of that object.
The result of the query has this structure:
Without using the operator, you would get the whole object instead of only the .
Updating Cached Query Results
Caching query results is handy and easy to do, but sometimes you want to make sure that cached data is up to date with your server. Apollo Client supports two strategies for this: polling and refetching.
Polling
Polling provides near-real-time synchronization with your server by causing a query to execute periodically at a specified interval. To enable polling for a query, pass a configuration option to the with an interval in milliseconds:
By setting the to , you’ll fetch the list of posts from the server every 0.5 seconds. Note that if you set to , the query will not poll.
Refetching
Refetching enables you to refresh query results in response to a particular user action, as opposed to using a fixed interval.
Let’s add a button to our component that calls our query’s refetch function whenever it’s clicked.
Call the method and notice that the UI updates with a new dog photo. Refetching is an excellent way to guarantee fresh data, but it introduces some complexity with loading state. In the next section, we’ll cover strategies for handling complex loading and error state.
Inspecting Error States
You can customize your query error handling by providing the configuration option to or . The default value is , which tells Apollo Angular to treat all GraphQL errors as runtime errors. In this case, Apollo Angular discards any query response data returned by the server and sets the error property in the result object to true.
If you set to , Apollo Angular does not discard query response data, allowing you to render partial results.
Loading State
Every response you get from contains the property. The option defaults to . That means the observable will emit immediately and synchronously with and . When the XHR is completed, the observable will emit with and with a defined .
If you prefer to be notified only when result is available, and you are not interested in loading state, then you can configure to , globally when constructing of for a specific query only. Something like this: