Vue-apollo: Weak documentation, cryptic methodology, almost no examples at all

[c0h1b4]

I am trying to connect my Apollo GraphQL server to a Vuex app and it is a super difficult task.

The actual vue-apollo module is extremely not intuitive for regular users, the examples are very scarce and not useful at all.

Look all over the internet and you will find just a few examples that are outdated or very specific to a super complex boilerplate or really superficial.

I am thinking that this is on purpose for the Apollo team to sell support.

For now I will ditch the Apollo server and wait a few more iterations of the project until it is usable for a fast development and not rocket science... :(

Sorry to put this here, but I am struggling with this for over a week and got nowhere...

[Ben52]

Ask direct questions, specifically on forums like Vue's discord channel and you are very likely to get help...

[Akryum]

I think vue-apollo is actually simple to use. What didn't you understand from the docs? Also, please try not using vuex with apollo.

[acatejr]

I kind of agree with the initial ticket. The documentation is sparse. Even though the client is relatively easy to figure out for implementation trying to find more nuanced information is a challenge. For example, is there a way to alter query result data after as or after it is received?

[AnalyzePlatypus]

Same.
Documentation is sparse and often superficial.
Apollo Client is an advanced library with "too much magic" (as we used to say in the Rails community), and it needs a fair bit of explaining.

• How to replace Vuex with Apollo? Examples (The Local State page is very brief)?
• What exactly can components view of each other's queries?
• Best practices for storing lengthly query documents (They shouldn't clutter up our component files, right?)
• The default caching methodology is not explained

We could use more comprehensive docs, and more importantly, a collection of best practices.

[njwest]

@Akryum Thank you very much for vue-apollo, this is a really awesome Apollo implementation!

Since the React Apollo docs have been growing since Apollo's inception with community contributions, why don't we help improve vue-apollo docs by putting together some resources and docs as a community?

Here is an issue relevant to this effort, re: caching: https://github.com/Akryum/vue-apollo/issues/618

@AnalyzePlatypus Re: modularizing queries, one really basic way of doing it with require() statements + graphql-tag can be seen below

There are more options/things possible with the below methodology, worthy of its own docs section ;) Maybe if you're still using this, you may want to put something up on Medium for us to digest?

// in a Vue component
  <ApolloQuery
    :query="require('@/graphql/Users.js').default"
  >

// in graphql/Users.js
import gql from 'graphql-tag'

export default gql`
  query {
    user {
      id
      name
    }
  }
`

Frankly, vue-apollo is a magnificent implementation of Apollo, and Apollo packages beyond React and Vue implementations are worthy of focused study if you want to use the Apollo client in production. Let's contribute some solutions rather than just gripes.

[tre-dev]

I think vue-apollo is actually simple to use. What didn't you understand from the docs? Also, please try not using vuex with apollo.

Setting it up might be easy, but once it starts to get more complicated, the document is simply sparse. Even if you, as the maintainer and developer, don't think it is, clearly there are enough developers who feel that way!

Also, expecting people to just ditch Vuex in favour of a weird graphql store implementation is beyond my comprehension. Who in their right mind, wants to use graphql queries & mutations to interact with the store? I don't have a problem with finding new and better ways to deal with things, even if that means I need to relearn and refactor a lot of code. But I will most def. not have some opinionated decision forced upon me.

Or in other words: it doesn't matter if you think that Vuex is not needed or if it shouldn't be used with Apollo. That's the decision the developer has to make, whether he/she/it prefers to use graphql or vuex.

Especially, if that's resulting in a lockin. Imagin that for some reason, a project starts out with apollo, ditches Vuex and after months decides to switch to another graphql client & vuex. What a fun way to waste time by refactoring everything again, instead of just switching out the core graphql logic...

[c0h1b4]

A lot has changed in 1 1/2 years. The platform, documentation and examples evolved a lot. Now we have much more examples and the documentation is much better also.
The critic I've done was about the vue-apollo project from the past. I am using the new version and docs without any issues.

[tre-dev]

@c0h1b4
I'm not familiar with the documentation 1 1/2 years ago, but my guess is that it did improve. It's your ticket so feel free to close, but I don't think the issue has been solved yet.

In my view, the problem isn't about vue-apollo being too hard to grasp, but rather that in order to truly being able to replace vuex, the current examples are simply not enough.

It's great that akryum and some other folks prefers to use inline gql tags, but I find it quite verbose and error-prone. With vuex, I'm keeping certain logic in a single place and don't have to scramble around different components. On top of that, with getters/state, I have an easy way to distribute that data around.

Now, there are obviously other ways to distribute data (i.e. props), however, what if I'm loading a user on one page, but require said user on another page. I can't just prop that. But sure, I'm able to fetch the cache, however, based on the examples, that would mean:

1.) I write it via gql in multiple places, but add the @client directive in some of those places.
2.) I create two gql files for each query/mutation (one with and one without @client).

Even if those options would work, they're far from ideal in my PoV. A better would be:

3.) Dynamically update the gql files/queries in order to add a @client directive when needed.

**From this:**
// Makes a potential remote request
query getUser {
  user {
    name
  }
}

**into this:**
// Only fetches from the cache
query getUser {
  user @client {
    name
  }
}

Here's a potential solution. It's quite bare, probably not the best solution and I haven't written tests yet, but it works and most importantly: it reduces the horrible overhead of writing duplicate queries.

import {print} from 'graphql/language/printer'
import {parse} from 'graphql/language/parser'

export const makeLocal = (schema: any) => {
  const s = print(schema)
  const i = s.indexOf('{', s.indexOf('{') + 1)
  return parse(`${s.substring(0, i)}@client ${s.substring(i)}`)
}

example:

const query = require('./graphql/queries/getUser.query.gql')
user = {}

apollo: {
    user: {
      query: makeLocal(query) // only syncs with the cache
    }
}

To sum it up:

akryum was right when he said that apollo cache can be used for most of what vuex is currently doing. However, the simplicity of vuex in comparison to apollo cache is far superior, which is what should be adressed or at least not deemphasized.

[scottix]

I have been recently learning graphql and working on a project.

I agree for a large project storing queries in separate files is extremely important for optimization purposes and DRY coding practices.

Here is why I say for optimization purposes. Lets say you have 20 components each querying different aspects of the user. Like, name, email, login, etc...

If each one of those components are querying different things, a single page load could make 20 calls to the server, which defeats the whole purpose of graphql.

Also if you want to add something like updated_on, you would need to update all 20 components to make sure everything is optimal.

Having some standard way of storing the queries in separate files and examples of this scenario I think could be helpful.