@graphql decorator

[dotansimha]

TODO

• Query implementation
• Mutation implementation
• Query with support for context-based options.
• Subscriptions support
• AoT alternative (expose method to wrap existing Component without using Decorators, because of Custom decorators are stripped when using the AoT build flag angular/angular-cli#2799)

Query

Usage is very similar to apollo-react component containers.

Usage for query with static options object:

@Component({
   template: 'Test'
})
@graphql([{
    name: "myQuery",
    query: query, // this is the gql Document
    options: {
         variables: {
              myVar: "test"
          }
    }
}])
class MyComponent {
      private myQuery: ApolloQueryObservable<any>;

      constructor() {

      }

      ngOnInit() {
           this.myQuery.subscribe(() => {
                  // handle subscription
           });
      }
}

Usage for query with context-based options object (passed as a function):

@Component({
   template: 'Test'
})
@graphql([{
    name: "myQuery",
    query: query, // this is the gql Document
    options: (instance: MyComponent) => {
          return {
               variables: {
                      myVar: instance.myVarValue
          }
    }
}])
class MyComponent {
      private myQuery: ApolloQueryObservable<any>;
      public myVarValue: string = "test";

      // ...
}

Variables properties can also be an Observable.

Mutation

Usage is very similar to apollo-react component containers.

Mutation exposes a method - which is the execution method, which accepts any Mutation properties that available on (MutationOptions form apollo-client) only without the mutation Document (which passed to the decorator).

Example for usage with predefined variables and options, but handle updateQueries inside the Component:

@Component({
   template: 'Test'
})
@graphql([{
    name: "myMutation",
    mutation: mutation, // this is the gql Document
    variables: {
        myVar: "test"
    }
}])
class MyComponent {
      private myMutation: Function;

      constructor() {
      }

      doMutation() {
          this.myMutation({
                  updateQueries: () => {

                   }
          });
      }
}

Example for usage with external logic of updateQueries and dynamic variables:

@Component({
   template: 'Test'
})
@graphql([{
    name: "myMutation",
    mutation: mutation, // this is the gql Document
    updateQueries: () => {
        // handle response
    }
}])
class MyComponent {
      private myMutation: Function;

      constructor() {
      }

      doMutation(val) {
          this.myMutation({
                  variables: {
                       myVar: val
                  }
          });
      }
}

Subscription

The main issue is to split the Component logic and the GraphQL subscription query.
Splitting the data and the view, but still provide an API to update the store on data change.

Subscriptions needs to be executed from an existing query, but we still wan't the gql object to be in use outside the Component's code.

This is the current implementation for subscriptions over query, this is not final and feel free to suggest a better usage:

@Component({
   template: 'Test'
})
@graphql([{
    name: "myQuery",
    query: query, // this is the gql Document
    subscriptions: [
        {
               name: "mySubscription",
               subscription: subscription // this is the gql Document,
               updateQueries: () => {
                         // update the store
               } 
        }
    ]
}])
class MyComponent {
      private myQuery: ApolloQueryObservable<any>;
      private mySubscription: Function;

      constructor() {

      }

      ngOnInit() {
           this.initSubscription();
      }

       initSubscription() {
             this.mySubscription({variables: {test: 1}});
       }
}

[dotansimha]

@kamilkisiela @Urigo
Please refer to the Subscription headline.
The subscriptions need to be executed from a query context, so I think it could be inside the query definition.
Any other usage ideas?

[kamilkisiela]

@dotansimha Few things.

---

I think there's going to be a change how we specify a query and a mutation. Instead of query: * and mutation: * there will be document: *. So we can use it like this:

{
  name: "myMutation",
  document: mutation, // this is a Document
  updateQueries: () => {
    // handle response
  }
}

---

Why do we keep subscriptions as an array of subscriptions?

Instead of:

{
  name: "myQuery",
  query: query, // this is a Document
  subscriptions: [{
    name: "mySubscription",
    subscription: subscription // this is the gql Document,
    updateQueries: () => {
      // update the store
    } 
  }]
}

we could just do this:

{
  name: "mySubscription",
  document: subscription, // this is a Document
  updateQueries: () => {
    // update the store
  }
}

Super pumped to have a new dev in angular2-apollo.

[dotansimha]

Thanks @kamilkisiela !!

Yeah you are correct regarding the document, we will also need to detect which type of Document is used.
Regarding the subscriptions: in order to create a subscription, we first need to create a query and then to run subscribeToMore because the subscription result is related to the same store of the Query (for example: comments, and then subscription for newComment). in the example you provided, there is no way to connect the subscription to the query. am I missing something?

[kamilkisiela]

You've got subscribeToMore and also subscribe.

First one is a part of ObservableQuery and the second one belongs to instance of ApolloClient.

and yes, it's not documented, don't know why :)

[kamilkisiela]

We could allow user to just use a subscription and then he could decide which queries he wants to update.

This way one subscription could update n number of queries.

An example

[dotansimha]

@kamilkisiela I see. so we can keep it simpler and provide the same API for creating subscriptions.

But how can you update the redux store when a new data arrives into the subscription without creating the subscription from the original query?

Thanks!