Quasar and Apollo - Client State without Vuex - Part 2
Tags: vue, apollo, quasarframework, graphql
Published: 2020-04-05 14:43:39

---
title: Quasar and Apollo - Client State without Vuex - Part 2
published: true
description:  A series of articles to demonstrate Quasar, Vue-Apollo and client state management
tags: Vue, Apollo, QuasarFramework, GraphQL
---

### **Part 2 - Vue-Apollo and its Working Parts - Queries**

![](https://i.imgur.com/Brv3YJF.png)

If you've landed here inadvertently and haven't read the [**first part**](https://dev.to/quasar/quasar-and-apollo-client-state-without-vuex-2iii), please do. 

**This tutorial has 4 parts:**

* **[Part 1 - Getting Started](https://dev.to/quasar/quasar-and-apollo-client-state-without-vuex-2iii)**
* **Part 2 - Vue-Apollo and its Working Parts - Queries (*You are here now)*** 
* **[Part 3 - Vue-Apollo and its Working Parts - Mutations](https://dev.to/quasar/quasar-and-apollo-client-state-without-vuex-i08)**
* **[Part 4 - The Trick and the Rest of (Vue-)Apollo](https://dev.to/quasar/quasar-and-apollo-client-state-without-vuex-p4)**


### **Apollo and Vue**

Apollo is an awesome GraphQL client package and if you look at their docs, you'll notice it's mainly aimed at React. However, we in the world of Vue, thankfully, have a nice Vue plug-in package called `vue-apollo`, which helps offer a sleek API into Apollo within Vue (and of course Quasar). 

### **The Flow of Data in GraphQL**

Below is a diagram showing the flow of data through a Quasar/Vue/Apollo app. 

![](https://i.imgur.com/T7RVEFE.png)

If you are familiar with Vuex, the flow above might look somewhat familiar to you. With Apollo, you have Queries that pull the data from "a source" into the view, similar to Vuex's getters. And, you have mutations that alter the data in that same "source", similar to Vuex's setters. 

Fact of the matter is, this is the magic of GraphQL. While with other solutions the devs are fumbling around with GET and POST requests to a REST API to get data and mutate data between the client and the server and trying to figure out the right reply signature to make things semi-efficient and also how to best get it into their store, GraphQL is already just doing its thing. As soon as the mutation or query is written (of course, with the server or client side resolvers having been developed too), you are getting the responses you expect, and more importantly, in the form you need them. 

If you'll notice, in the middle of the diagram is a "store". That's Apollo's caching mechanism. Our litte todo app is only using that store and we won't be making calls to a server. However, if we did want data from or mutate it on the server, we wouldn't need to change our queries and mutations very much to make it happen. This will be explained better later.

For now, just realize the queries and mutations you are about to see are the same or similar for any GraphQL system or for calling from any "resource". That, in turn, is also a great benefit of GraphQL. It is is a specification and with a specification, you get standardization. And standardization means, less cognitive load for onboarding new devs, and that means better and faster solutioning. 

If you are at all in the know about GraphQL, we probably didn't need to mention this. But, if you are new to GraphQL, welcome to a new paradigm of data fetching and mutation.  

### **Priming The Cache (or Store)**

Before we can begin, one thing is very important. If we are going to be addressing the Apollo Cache ourselves to use it as our single-source of truth, we need to "prime" it. It's almost like how Vue needs data to be initialized in a component, before it can be reactive. 

In our example todo app, if you go to `/src/quasar-app-extension-apollo/apollo-clent-hooks.js` you'll see how this is done.

{% gist https://gist.github.com/smolinari/3f2fd7120cb25ebfb76f0eeee4cf389f %}

We've got our `todos` array, the `networkStatus` object and a `filters` object set up. 

Again, this needs to happen, but only for the data we want to store within Apollo for client-side state.

Before we continue to dig in, if you don't have any or very little knowledge of GraphQL, you should learn a bit more about it. Otherwise, we might be losing you at some point below and we don't want to have that. "[**How to GraphQL**](https://www.howtographql.com/)" is a good tutorial to get started and learn about the basics of GraphQL. For now, you only need to learn about the client side concepts and the concept of resolvers on the server and what they mean in response to queries and mutations.

### **Queries and the Apollo Option**

In our todo app, we only have two queries. One for the list of tasks, our "todos", and one for the list of filters of the todo list (All, Completed and Active).

![](https://i.imgur.com/VRV7oNF.png)


The filters could very well have been hard-coded into the components, but we've done it this way to demonstrate two things:

1. Another way to instantiate the cache with values you need (as shown above).
2. To show that you could theoretically also pull the list of filters from the server too and not have them hard coded in your component.

By that last point, we mean that you could very well pull the data of what filters offer, like the text in them, from the server, making the filterBar very dynamic for say, i18n purposes. 

Let's start with the query for filters.

Go to the `FilterBar` component. You'll see it is a normal component with a QBtn. 

{% gist https://gist.github.com/smolinari/b77cbed244802e1ca409a8602e440724 %}

So what do we have here?

In...

* lines 1-14 we have our `<template>` section, where we are building our possible filters via a `v-for` loop of the queried data.
* line 17, we are importing our queries and mutations.
* lines 19-26, we are initializing our component's data/ state. 
* lines 28-30, we are using the `apollo` option to inject our query into the component in order to get the list of filters from our store (more on this later).
* lines 32-43, we have a method with our mutation (more on this in Part 3.)

Important to note is the `apollo` option. This is how we can "connect" our component's data to the data we are querying for. The property should always match a property within the component's data and `vue-apollo` will automatically assign the result object to the matching data property. This is my personal favorite way of adding queries. There is another couple of ways, one we'll cover below.

One more note, should you not want to match your data's naming, you can also assign the property in Apollo to your data property via the `update` option of Apollo. For instance, let's say our data prop wasn't `filters`, but rather `fooFilters`. You could do something like this. 

```javascript
1  apollo: {
2    filters: {
3      query: gql`query {
4        // our query would be here. 
5      }`,
6      update: data => data.fooFilters
7    }
8  }
```

Getting back to the query, if you open up our `queries.js` file under the `/graphql/Todos` folder, it looks like this. 


```javascript
1  export const getFilters = gql`
2    query GetFilters {
3      filters @client {
4        name
5        label
6        active
7      }
8  }
9  `
10
```

It's a very simple GraphQL query.

Now let's go one up in the hierarchy and look at our `TodoList.vue` file. 

{% gist https://gist.github.com/smolinari/18dfc6b10d8db4a8477c0127885f0cb8 %}

So what do we have here?

In...

* lines 1-10, we have our `v-for` loop building our todo list of tasks. 
* lines 13-14, we are importing our queries and components.
* lines 16-25, we intializing our component's data.
* lines 27-30, we are injecting our queries into our `apollo` option.
* lines 32-45, we have a computed method to calculate our "visible" todos.
* lines 47-58, we have a watcher on our todos, so when they are all "completed", we give the user a nice motivational message.
* lines 60-65, we have another watcher watching the filters data and setting the active filter accordingly. 

If you've noticed, we are, once again, querying for the filters. This is so we can filter the todo list on the active filter. 

Here is a challenge. Can you imagine a different way of doing this? If yes, explain what your method would be in the comments below!

So that is how we query in `vue-apollo`. However, that is only one way. There are others....


### **The Vue-Apollo `<ApolloQuery>` Component**

Another way to do an Apollo query is via the `vue-apollo` query component. If you look at the `/components` folder, there is an alternate `TodoList.vue` file called `TodoList.alt.vue`. 

Open it up and you'll see this. 

{% gist https://gist.github.com/smolinari/88413f62a4b8fa12ae12884846e8fba4 %}

So what is different here?

In...

* lines 2-12, we have the `<ApolloQuery>` component. 
* lines 40-42, we are only injecting the filters query, because our todos query is above in the template now.
* line 44, we changed our computed to a method. Theoretically, it could have stayed a computed, but it looks a bit cleaner this way.
* line 59, we had to change our watcher to watch all data in the  `<ApolloQuery>` component.


There are two other methods to get the query into the component. 

1. By assigning the query to a data prop. 

```javascript
1  <template>
2    <ApolloQuery
3      :query="todoQuery" //<--here
4    >
....
5    </ApolloQuery>
6  </template>
7
8  <script>
9  import { queries } from 'src/graphql/Todos'
10 import Todo from 'components/Todo'
11
12 export default {
13   name: 'TodosList',
14   components: { Todo },
15   data () {
16     return {
17       filters: [],
18       activeFilter: ''
19       todoQuery: queries.getTodos //<--our query
20     }
21   },
22
```

### **Using '.gql' Files**

Using 'gql' or 'graphql' files has a slight advantage over putting the code in JavaScript, as we've been doing. With them in their own files, we can take advantage of Webpack and the GraphQL AST (your tree of queries) doesn't get built on the client, but rather on the server. As your application gets larger, you might want to consider this approach to save compute time on the client. 

This is what using a `.gql` file might look like.

```javascript
1  <template>
2    <ApolloQuery
3      :query="require('../graphql/GetTodos.gql')"
4    >
....
5    </ApolloQuery>
6  </template>
```

In order for this to work, however, you must add the appropriate Webpack loader into `quasar.conf.js`. You'll need to add this module rule. 

```javascript
chain.module.rule('gql')
   .test(/\.(graphql|gql)$/)
   .use('graphql-tag/loader')
   .loader('graphql-tag/loader')
```

Example code was added to the codesandbox to the app repo. See `TodoList.alt2.vue` and the `quasar.conf.js` files.

### **Conclusion**

So, this is how you can query for data within Quasar/ Vue with the `vue-apollo` package and with Apollo Client. There is more advanced things to learn about `vue-apollo` and querying, like how to offer variables with the query and more. You can find out more in the resources below.

Resources:

vue-apollo docs: https://apollo.vuejs.org/guide/
GraphQL docs: https://graphql.org/learn/
Apollo Client docs: https://www.apollographql.com/docs/react/

[**In Part 3**](https://dev.to/quasar/quasar-and-apollo-client-state-without-vuex-i08) we'll be going over mutations and closing the loop between pulling data and relating it to our components and also manipulating that same data and seeing the manipulations happening.