Vue-apollo: Fragments

[TheMallen]

Hey, can you give an example of how vue-apollo works with fragments? I'm not really clear how that works with this lib.

[Towerful]

I am about to start playing around with vue & vue-apollo for my current project.
I'd love to see an example of nested components utilising fragments & building up a query.

I think the way to do it would be to have each component export a graphql fragment separate to the actual component.
If a component requires a child component, it also requires the child's graphql query/fragment, and builds it into it's own query/fragment.
The app/super-parent then builds & executes the actual query, and the data is (kinda unfortunately) sent as props.
Or perhaps a component exports 2 similar definitions: a query (as a top-level component, responsible for fetching data) and a fragment (as a child component, responsible for asking for data).
The app/super-parent is responsible for building and executing the query, but each component has its own apollo query (as in a vue-apollo query, separate from the exported query and fragment) to fetch data directly from the store, little-to-no props required (as in, only the id of the object required).

I think the 2nd approach - from what I have read & understood - would be the way to do it.
there is a bit of code duplication, however - seeing as graphql is just a string - for simple-to-medium complexity problems, it would be trivial to implement, and the 'fields required' would be a matter of string concatenation.

I'm working on a time based system, where date ranges are pretty critical to what is displayed.
I want the data to be fetched & processed only for the visible date-range.
But baby steps.

[xRoker]

Hi, @Akryum . Same question. React users have https://github.com/apollographql/graphql-anywhere . I'm wondering if there is a way to use something like this in Vue

Update:
I just found out that graphql-anywhere works actually anywhere :) including Vue, with the exception of the react-only features like PropTypes

[Towerful]

I came up with a system which I quickly ditched (due to performance issues of 800 records, and I think Apollo restrictions).

Essentially, it went like this:

import exampleComponent from './exampleComponnent';

const fragments = `
  fragment aComponentFragment on SomeDate {
    id
    some_data
    exampleData {
      ...exampleComponentFragment
    }
  }
  ${exampleComponent.fragments}
`;

const query = gql`
  query SomeDate {
    ...aComponentFragment
  }
  ${fragments}
`;


export default {
    fragments,
    name: 'aComponent',
    components: { exampleComponent },
    apollo: {
      somedata: {
        query
      }
    },
    data() {
      return {
        somedata: {}
      }
    }
}

This pattern was repeated all the way down through components.

Basically,
Components define what data they want in their fragment. That fragment should also include whatever fragments child-components require.
The query turns it into gql, and makes sure that the component only gets what it requires (as well as data for the children).

I ran into an issue where Apollo didnt know what data to return from the store.
So a parent component might have requested & cached the data for it's children, but when the child requested it, Apollo didn't know it was already in the store, so would refetch from the server.
When I finally got it working, data processing time was about 5x what I would expect from a vanilla api layer.

I eventually went with julienvincent/modelizr. It's not quite what I want, but its close and fast.
Without writing it myself, I don't think there is a perfect-fit solution out there. And - I have so much else to do on my project - that the close fit of modelizr is good enough to let me get on with the work.

[xRoker]

@Towerful thank you for sharing this! Modelizr looks interesting. Can you please provide an example of a vue component using apollo with modelizr?

[Towerful]

@xRoker , I moved away from apollo to modelizr. Sorry I didn't make that clear.
I used it to create my own vuex store, and accessed it via actions.
I couldn't get apollo to work in a way that I any benefits over a more traditional approach to the data layer

[SebT]

I use the graphql-loader to be able to put queris in .gql or .graphql files. Here is an example :

fragments.gql

fragment UserParts on User {
  id
  name
  email
}

get-by-email.gql

#import "./fragment.gql"
query ($email: String!) {
  user {
    getByEmail(email: $email) {
      ...UserParts
    }
  }
}