This example must be updated maybe like the main example.

The Problem

ApolloClient#mutate takes an update argument. Likewise, the ApolloMutationMixin uses this.update as the default value for that argument. This, however, conflicts with UpdatingElement#update, which LitElement exposes.

The Current Solution

The solution thus far was to monkey-patch the lit-apollo version of ApolloMutation#mutate to take this.onUpdate as default instead.

This has downsides:

• lit-apollo (which the majority of users use) is treated like an edge case
• properly documenting the element classes in is extremely awkward, maybe impossible

The Proposed Solution

I propose renaming the property used in the ApolloMutationMixinto updateCache. This would change the name across libraries. I would also consider renaming it for @apollo-elements/hybrids as well, even though it doesn't use the mixins, for consistency.

The downside to this is that in Apollo docs, the property used is called update, so changing the name here might break expectations.

This would be a breaking API change, and would probably be the last one before 1.0

I think there is an error on the usage example: the imported ApolloQuery seems from a wrong path.
Also I think should be added a reference for the client prop.

What do you think about this example? Ex:

<script type="module">
  import gql from 'graphql-tag';
  import ApolloClient from 'apollo-boost';
  import {ApolloQuery} from 'lit-apollo';

  // Create the apollo client
  const apolloClient = new ApolloClient({
	uri: 'https://your.graphql.server'
  });

  class MyConnectedElement extends ApolloQuery {
    _render({ data: { helloWorld }, loading, error, networkStatus }) {
      return (
          loading ? html`
            <what-spin></what-spin>`
        : error ? html`
            <h1>😢 Such sad, very error!</h1>
            <div>${error.message}</div>`
        : html`
            <div>${helloWorld.greeting}, ${helloWorld.name}</div>`
      );
     }

     constructor() {
       super();
       this.client = apolloClient;
       this.query = gql`query { helloWorld { name, greeting } }`;
     }
  };
  customElements.define('connected-element', MyConnectedElement)
</script>

Of course the window option must be documented but I think this is much more handy.

Side question: do you have some plan to document all the props and API exposed by the elements? Maybe it's worth to open an issue about documenting this also outside the README (maybe a GHPage with a small site).

It would be great to see a polymer project with apollo-elements already set up, maybe a todo app or something?

See below

OK. The open-wc people have some app generators we could build upon. I think we could piggyback on their generators for this project, publishing a generator-lit-apollo package to npm from this monorepo.

https://open-wc.org/developing/generator.html#available-scaffold-generators

@daKmoR's suggestion was something like:

yo lit-apollo:app
# which internally runs
yo open-wc:scaffold-vanilla
# some extra apollo stuff

PRs welcome.

I'm thinking we can distribute optional elements/apollo-query.js and elements/apollo-mutation.js that would basically follow the pattern set out in the README
@LasaleFamine @FluorescentHallucinogen What do you think about that? I think we can start experimenting with the design for <apollo-mutation> set out in #2 (comment) and see where it takes us.

Apollo Elements should support haunted with useQuery, useMutation hooks

It would be great to support Microsoft's FAST Element class

This looks like it should be a straightforward implementation, similar to @apollo-elements/lit-apollo - apply the mixin, hook up the observed properties or use Observable, and off we go.

I'm using apollo-query to refetch a query with the same variables but the result is not updating. I notice that your using setVariables to refetch the query but in the apollo client documentation says that the method is use for internal use only and instead you should use refetch. I made the change locally and it works as expected.

Hi Benny, perhaps you have a suggestion how to handle the following scenario:

I have a component which fetches something like a book author and I determine which book author to load based on the route. e. g. the route may be:

domain.com/authors/darren-hardy

This gets pushed into the GraphQL client store as routePath: '/authors' & routeDetail: 'darren-hardy'

When I'm on my component and want to fetch the author "darren-hardy" I need to first get the route data from the GraphQL store before I can set the variable to set this in my component.

There's a few solutions here:

1. Just push the route data in e. g. localStorage so I can easily retrieve it but then I'm not using GraphQL store for entire store management, which is the entire point of GraphQL store management
2. Do something in the constructor like run a vanilla apolloclient query for the routeData in the store and await for that data before setting the variable in the constructor.
3. Anything else I'm missing?

Do you think solution number two makes sense or is there another way how you handle this for your own projects?

/edit:

Nevermind number 2 wouldn't work, since you can't do an async call in a constructor.

I tried not setting the variable in the constructor and just call a method in the constructor that initiates the retrieval of the graphQL store and then set the variable but that results in an infinite loop.

/edit:

Actually nevermind, so it does work if you create a method that initializes the call to the store and then set the variable. I just accidentally called the method setVariables which was already a reserved name in ApolloQuery.

However, if one does it that way, the component will still try to fetch first even without an initial variable set, so in my case it'll still fetch something (my mongoose query will return the first document if there's no variable set)

So basically, first fetch & render update is the fetch without a variable set, the second fetch & render update will be with the proper variable set.

/edit:

I suppose one could check for this.variables in the render call and then render nothing if no variables are defined.

    if(!this.variables) {
      return nothing;
    }

This would still result in two queries being executed though, which could be a problem for heavier ones.

I'm just trying to figure out what's the best way to do this with the least amount of boilerplate necessary to keep things DRY. Food for thought: Should a component that requires variables fetch & render if no variables are set?

So while what I came up with works, it runs queries twice and it requires a lot of non-DRY setup. This is Ok for one component but if I have 6 different components on the page that all need to get the route state from the GraphQL store, that's a bit frustrating.

So this is what I have in my constructor right now FYI:

The @polymer/lit-element npm package has been moved to lit-element. @polymer/lit-element is deprecated and not receiving any updates, so please upgrade to lit-element@^2.0.0 as soon as possible.

Thanks!

$ npm i -S @apollo-elements/lit-apollo

and correct enough it doesn't exist

https://www.npmjs.com/package/@apollo-elements/mixins

I bet apollo elements support for GitHub's new hotness would be cool

https://github.github.io/catalyst/guide/introduction/

at the very least, probably some mixins and a decorator or two? maybe a base class?

OTOH, is there a more idiomatic way than subclassing?

Please add support of GraphQL real-time subscriptions (updates).

I spent some time creating a reproducible example
https://codesandbox.io/s/stoic-noether-d47ts

You can see in the console that it always says false, the loading state is never true and therefore loading is never showed to the user.

We have lots of new docs on https://apolloelements.dev

Would love to get some 👀 on them.

@peschee had some great feedback which I'll summarize here:

TODO

Content and Navigation

• Remove API docs footers from docs pages
• Draft a main page that's not just a dump of the README
• separate docs (prose) and API docs
  • consider using rocket for this

Design

• light mode (prefers-color-scheme and toggle)
• More whitespace

This issue is related to lit-apollo.
I have apolloQuery component, which uses variables.

Those variables are passed down as props from the parent component, and I want to refetch data from the server when new props arrive & use cache.

I tried the following approaches:

1. this.variables = {new variables}
2. this.refetch({new variables})
3. this.executeQuery({new variables})

My issues is the following:

1. this.variables approach is buggy. I think, it is related to this issue:
   apollographql/react-apollo#2202

2. this.refetch works, but does not use cache

3. this.executeQuery works, uses cache but does not pass down to render anything except data. so In order to make it work I have to do something like this:

      this.loading = true;
        let result = await this.executeQuery({
          variables: {
            from: this.from,
            categories: this.filters.categories,
            sortBy: this.filters.sortBy
          }
        });
        if (result === undefined) {
          this.loading = false;
          this.error = true;
        } else {
          this.loading = result.loading;
        }

There are several questions which repeatedly come up and should be addressed in the Documentation

1. How to build / import ApolloClient (see #57)
2. Recommended settings for said client
3. Why doesn't my component ever enter loading state (fetchPolicy related)
4. Why doesn't my component render (in next major version, a breaking change should remove the logic around rendering and always render, even without data)
5. How should/can users manage local state

• this is properly a matter for apollo client docs, but we should add a reference and maybe an example.

The Usage examples should be expounded on to give several examples, including

1. simplest usage, with window.__APOLLO_CLIENT__ and no local state (see #45 (comment))
2. example of local state, including mutations. (see #31)
   - routing is a good use case for this example
   - could eventually be spun out to a library
3. no global client, passed in constructor / class fields
4. no global client, passed as property
5. with query document as script in html
6. with query document passed via bundler magic
7. use of onCompleted and onError for mutation components
8. use of onCompleted and onError for query components (see #42)

The generator currently outputs TypeScript projects only. It should have an option to output JavaScript projects.

This could be accomplished without duplicating code by the following steps

1. If the TypeScript option is selected, continue as normal
2. If the JavaScript option is selected, run all the same steps as the TypeScript generator, but add the following steps afterwards:
   1. Run esbuild or TSC on the outputted TypeScript sources (minify: false)
   2. If necessary, run eslint --fix to align with linting standards
   3. Delete the generated TypeScript sources.

The generator should detect if the user is trying to add a JS component to a TS project and vice-versa, and either error out or warn.

Bonus points to adding unit and integration tests to the generator.

Hi. While I was trying the library, I had a doubt on how we can do both Query and Mutation on the same component? I mean at a time, we can extend only one class (without mixins). And that means that we can do only query or mutation in a component.

Is it possible to do both query and mutation in a component extending just 1 class in lit-apollo?

Thanks in advance.

I'm looking at using lit-html, lit-apollo, & apollo-client, but of course need to use webpack. But I've never used webpack. Does anyone have a working config they could drop that will help?

Thanks

Package

@apollo-elements/lit-apollo

Description

The @apollo-elements/lit-apollo package has no exported member html.

The usage docs state that the following html import should be used:

import { ApolloQuery, html } from '@apollo-elements/lit-apollo';

However, it seems that @apollo-elements/lit-apollo has no such exported member:

export { ApolloElement } from "./apollo-element";
export { ApolloQuery } from "./apollo-query";
export { ApolloMutation } from "./apollo-mutation";
export { ApolloSubscription } from "./apollo-subscription";
export { MutationResult } from "@apollo-elements/mixins/apollo-mutation-mixin";
export { OnSubscriptionDataOptions, SubscriptionResult } from "@apollo-elements/mixins/apollo-subscription-mixin";

Steps To Reproduce

1. npm install --save @apollo-elements/lit-apollo
2. Add import { ApolloQuery, html } from '@apollo-elements/lit-apollo'; in your component code
3. See error

Expected Behavior

Shouldn't the docs state the following?

import { html } from 'lit-element';

Description

I tried to use the "defaultOptions" option on ApolloClient, I set it up like this,

const defaultOptions = {
  watchQuery: {
    fetchPolicy: 'cache-and-network'
  },
  query: {
    fetchPolicy: 'cache-and-network'
  }
}


client = new ApolloClient({
    cache,
    link,
    defaultOptions
  })

but I didn't feel any effect on doing it.

In order to make it work, I had to set the fetchPolicy property to 'cache-and-network' when using ApolloQuery.

Can you explain how to set it up properly to get it to work?

After the update, it just crashes.
Here is the reproduction:
https://apollo-client-local-state-export-repro-98qwhr.stackblitz.io/

https://github.com/bennypowers/lit-apollo/blob/7c1413a21ad66c05d2e8f1eab6596dd7d8bc69f2/apollo-query.js#L148-L165

I does not understand all the stuffs but I fixed the issue in my own project by replacing this method by

shouldUpdate(changed, old) {
    return !!this.data || !!this.error || this.loading != null;
}

because data, error and loading are class properties and shouldUpdate() which is defined in "UpdatingElement" from @polymer/lit-element does not take a first parameter containing these data (it take a map called _changedProperties) so data, error and loading is always undefined…

Package

@apollo-elements/lit-apollo

Description

Transpilation produces error saying that Property 'connectedCallback' does not exist on type ApolloQuery. Indeed:
apollo-query.d.ts:

import { ApolloQuery as ApolloQueryBase } from "@apollo-elements/mixins/apollo-mutation-mixin";
...

query inherits from mutation, not from from query.
Furthermore apollo-element-mixin.d.ts:

...
export declare class ApolloElement<TBase, TData> extends HTMLElement {
...

ApolloElement inherits fromt HTMLElement, not from LitElement, which is TBase

Steps To Reproduce

test.ts:

import {ApolloQuery} from '@apollo-elements/lit-apollo'

class Test extends ApolloQuery<any, any>{
   connectedCallback(){
      super.connectedCallback()
   }
}

Expected Behavior

No typescript errors while transpiling above code

I work with Stencil and would like to see a version of apollo-elements made for/with Stencil components.

I tried briefly to make my own using this project as a starting point but couldn't quite get it to work. The decorators used by Stencil seemed to get in the way so I wasn't able to use approaches from some of the other libraries/frameworks that are supported. Perhaps that's why there isn't a Stencil version here yet?

I'm hoping that maybe other people are looking for Stencil apollo-elements and we'll be able to build something that works.

This repo will be moving to GitLab some time this month. Heads up

I tried to understand the Usage part a few times now and also after digging into the src of apollo-elements and the leeway demo, I still don't understand everything.

import { ApolloClient } from 'apollo-client';
import { ApolloQuery, html } from '@apollo-elements/lit-apollo';
import { cache } from './cache';
import { link } from './link';

// Create the Apollo Client
const client = new ApolloClient({ cache, link });

• What is the connection between ApolloQuery & client? Like how does ApolloQuery know that it should that particular client? Is it because I set this.client in the constructor?
• Where is ./cache & ./link coming from? I guess this is implicit knowledge if you have used GraphQL with Apollo before, but my background is that I started GraphQL in Java (there is no Apollo) and then wanted to use GraphQL with LitElement and found this repo.

          <connected-child id="child-component"
              .client="${this.client}"
              .query="${childQuery}"
          ></connected-child>`

• What is the connected-child? Is this also extending ApolloQuery?
• Do I also have to set a property named client on my class to get the relation between client and ApolloQuery?

All of this I can answer the longer I look at the Usage, but it would be super nice to have a proper documentation that describes how this works instead of having "just" an example that (from my point of view) is not complete if you are a beginner and have never used anything from Apollo.

Maybe it would make sense to also link a tutorial to ApolloClient? And add a comment into the constructor?

Hi,
trying to find out if it will work in IE11, because most of everything that I have tried to use to get a graphql client integrated doesn't work.

Steve

Package

@apollo-elements/hybrids

Description

index.js includes the export
export { variablesFactory } from './factories/variables.js';

...but the file variables.js does not exist.

An installation section should be added at the top of the README. Example: https://www.webcomponents.org/element/auto-check-element

I'd like to notice that:

ApolloQuery extends ApolloQueryMixin(ApolloElement)

ApolloElement extends ApolloElementMixin(LitElement)

ApolloQueryMixin = superclass => class extends ApolloElementMixin(superclass)

ApolloElementMixin = superclass => class extends superclass

as a result ApolloElementMixin is applied to both LitElement and then to ApolloElement (which extends LitElement) - is this on purpose?

ApolloElement should inherit from LitElement for getting the correct hint from the editor (firstly).
This is an example of what happen on VSCode with the correct typedef (a small change on index.d.ts):

I'll open a PR for this.

Peter on the Polymer slack had these errors:

node_modules/@apollo-elements/mixins/apollo-subscription-mixin.ts:155:43 - error TS2322: Type '{ data: TData | null | undefined; loading: boolean; error: null; }' is not assignable to type 'SubscriptionResult<TData>'.
  Types of property 'data' are incompatible.
    Type 'TData | null | undefined' is not assignable to type 'TData'.
      'TData' could be instantiated with an arbitrary type which could be unrelated to 'TData | null | undefined'.
        Type 'undefined' is not assignable to type 'TData'.
          'TData' could be instantiated with an arbitrary type which could be unrelated to 'undefined'.
155       this.onSubscriptionData?.({ client, subscriptionData });
                                              ~~~~~~~~~~~~~~~~
  node_modules/@apollo-elements/interfaces/apollo-subscription.ts:36:3
    36   subscriptionData: SubscriptionResult<TData>;
         ~~~~~~~~~~~~~~~~
    The expected type comes from property 'subscriptionData' which is declared here on type 'OnSubscriptionDataParams<TData>'
node_modules/@apollo-elements/mixins/apollo-subscription-mixin.ts:156:7 - error TS2322: Type 'TData | null | undefined' is not assignable to type 'TData'.
  'TData' could be instantiated with an arbitrary type which could be unrelated to 'TData | null | undefined'.
    Type 'undefined' is not assignable to type 'TData'.
      'TData' could be instantiated with an arbitrary type which could be unrelated to 'undefined'.
156       this.data = data;
          ~~~~~~~~~
node_modules/@apollo-elements/mixins/apollo-subscription-mixin.ts:158:7 - error TS2322: Type 'null' is not assignable to type 'Error | ApolloError'.
158       this.error = error;
          ~~~~~~~~~~
node_modules/@apollo-elements/mixins/apollo-subscription-mixin.ts:184:9 - error TS2322: Type 'undefined' is not assignable to type 'Subscription'.
184         this.observableSubscription = undefined;

On account of his setting "strict": true in tsconfig.

Apollo Elements shouldn't prevent users from setting strict.

Since, lit-apollo is not providing web components per se (it is non-visual, so it doesn't use HTML Templates API and Shadow DOM API, some users won't like to use custom elements for queries (there is an extra performance cost for registering web component as an HTML element, DOM declaration and data binding; every property does come at a cost (observers, listeners, etc.) that are not necessary for working non-visual elements), so it doesn't use Custom Elements API), this is just a set of base classes, that's what I think about:

1. Why is it needed at all? What problem does it solve? What are the advantages compared to vanilla apollo-client?

2. Since it does not come as a set of web components, why it extends from lit-element (lit-element is intended to create custom elements rendered with lit-html, apollo-client has nothing to do with lit-html)? What if users want to extend e.g. hyperhtml-element by @WebReflection instead of lit-element?

3. Since it is just a set of base classes and ApolloClient is also a class, why not just extend it?

@bennypowers Could you please cover some advantages of lit-apollo over using vanilla apollo-client with lit-element (small code samples) in README?

Package

@apollo-elements/create

Description

npm init @apollo-elements -- component should allow for creating components in subdirs with dashes in the name

Steps To Reproduce

1. run npm init @apollo-elements -- app to completion
2. run mkdir src/components/y
3. run npx @apollo-elements/create component -n update-site -d sites

Expected Behavior

npx: installed 44 in 4.478s

Creating update-site in src/components/sites/update-site

Writing src/components/sites/update-site/update-site.ts
Writing src/components/sites/update-site/update-site.css
Writing src/components/sites/update-site/UpdateSite.query.graphql
Writing src/components/sites/update-site/index.ts

Done!

Generating TypeScript Schema...

Actual Behaviour

npx: installed 44 in 4.478s

Creating update-site in src/components/sites/site

Writing src/components/sites/site/site.ts
Writing src/components/sites/site/site.css
Writing src/components/sites/site/Site.query.graphql
Writing src/components/sites/site/index.ts

Done!

Generating TypeScript Schema...

Best solution would probably add an option for no namespace, as this command expects a component namespace

I can see now that the Readme for ApolloQuery doesn't show the <script type="application/graphql"> at the top of the README, but still does in the apollo-elements root README.

Is that intentional?

I noticed that the lit-apollo element doesn't rerender when <script type="application/graphql"> changes, and the README for apollo-query now says that. I didn't notice that before.

I don't know why it should refetch if it receives new props.

If you loop over an array and then sort it, the elements will show the value for the old row and not the new row.

Say it looks like this at the start

1 <apolloquery>true <a href="1"></a></apolloquery>
2 <apolloquery>false <a href="2"></a></apolloquery>
3 <apolloquery>false <a href="3"></a></apolloquery>

then apollo query will fetch that data. Then you sort it

3 <apolloquery>true <a href="3"></a></apolloquery>
2 <apolloquery>false <a href="2"></a></apolloquery>
1 <apolloquery>false <a href="1"></a></apolloquery>

That is not that easy to figure out at first that it is apollo-query that doesn't refetch and not you who made a render mistake. Because the number is correct, the field will say 3 because you pass it as parameters, so lit-element will rerender the render() function. See how the link href updates, but the value stays the same.

Apollo-query: 1.1.0

This is not an issue with lit-apollo itself.

@bennypowers Do you know the IDE plugins that support syntax highlighting for inline query scripts?

<apollo-query data="{{data}}" variables="[[variables]]">
  <script type="application/graphql">
    query User($id: ID!)
      user(id: $id) {
        name
        picture
      }
    }
  </script>
</apollo-query>

I'm personally interested in the plugin for VSCode.

There are an option to use it as a mixin? Like the the pwa-helpers/connect-mixin.js.

So it could be used with other Web Components classes.

Hi,

Thank you writing this library.

How do I refetch same query with same set of variables? I'm using lit-element 0.6.0 and lit-apollo 0.6.6-dev. I've tried reassigning to both variables and queries in a hope that it'd trigger fetch. Also tried using fetchMore, but it didn't work.

Now that state management has shipped in the core of apollo client, do you think you'll make changes to the library or add some recipes on how to handle global state management?

E. g. I fetch some data from a view component and want to subscribe to the data via all the child components without having to data-bind everywhere, instead, I can refer to the data in the global store.

Hi @bennypowers ,

It's related to changes in LitElement. I saw that you've raised a issue lit/lit-element#196.
I just wanted to know if you're planning to change your elements to use explicit de-structuring of props like { data, loading, error } = this. If yes, how long would it take.
I'm currently overriding shouldUpdate method like:

shouldUpdate(changedProps) {
    const { data, loading, error, networkStatus } = this;
    return !!data || !!error || loading != null;
}

And have to use changedProps like:

if (changedProps.has("myProp")) {
    const { myProp } = this;
    // use myProp ...
}

Kind Regards,
Belove

as reported by Michele Pinto on Polymer slack

~/workspace/playground/apollo-elements-app % npm init @apollo-elements --version
6.14.8
~/workspace/playground/apollo-elements-app % npm init @apollo-elements component
npx: installed 44 in 5.057s
internal/modules/cjs/loader.js:985
  throw err;
  ^
Error: Cannot find module 'mkdirp'
Require stack:
- .npm/_npx/19411/lib/node_modules/@apollo-elements/create/component.js
- .npm/_npx/19411/lib/node_modules/@apollo-elements/create/index.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:982:15)
    at Function.Module._load (internal/modules/cjs/loader.js:864:27)
    at Module.require (internal/modules/cjs/loader.js:1044:19)
    at require (internal/modules/cjs/helpers.js:77:18)
    at Object.<anonymous> (/Users/michelepinto/.npm/_npx/19411/lib/node_modules/@apollo-elements/create/component.js:7:42)
    at Module._compile (internal/modules/cjs/loader.js:1158:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1178:10)
    at Module.load (internal/modules/cjs/loader.js:1002:32)
    at Function.Module._load (internal/modules/cjs/loader.js:901:14)
    at Module.require (internal/modules/cjs/loader.js:1044:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '.npm/_npx/19411/lib/node_modules/@apollo-elements/create/component.js',
    '.npm/_npx/19411/lib/node_modules/@apollo-elements/create/index.js'
  ]
}

If I understand correctly, mutations and subscriptions in GraphQL are also queries (special queries).

So what about the only single one universal web component instead of 3 (<apollo-query>, <apollo-mutation>, <apollo-subscription>)?

Sorry I think it is not a bug but an enhancement.

Package

@apollo-elements/mixins

Description

I'm using esm modules in my project but apollo-mixins is trying to import crocks using default imports for example: import pick from 'crocks/helpers/pick' however crocks doesn't provide a default export.

Expected Behavior

Support for esm modules. Maybe change the import to * as pick

What do you think to add a tool for writing changelogs with commits? I usually use standard-version

mixins sets a default fetchPolicy on a per-component basis. This may conflict with the user's default options

The choice of default fetch policy should therefore be deferred to ApolloClient, this setting should be removed.

https://glitch.com/edit/#!/brassy-philosophy?path=script.js:14:3

I have a component that doesn't throw any error when I'm querying, so there's no way to figure out what's wrong with the query. When I replace the query with some other query, it works just fine.

So since render never gets called and no error is thrown there is no way to figure out what's actually wrong with the query.

For reference: A query like this works:

query getRouteDetails {
    getRouteDetails @client {
        routePath 
        routeParam
    }
}

Something like this doesn't:

query getAuthor($humanId: String) {
    getAuthor(humanId: $humanId) {
        _id
        humanId
        firstName
        lastName
    }
}

I'm passing the variable in the constructor of the component. Any idea how to troubleshoot this? Can I somehow get error logs on what's happening before the call to render?

Version 3 removed queryFactory, mutationFactory, and subscriptionFactory from @apollo-elements/hybrids. The reason for doing so was maintenance and bug surface area: It's better to maintain all the logic in mixins and reuse it in packages.

However @smalluban pointed out in hybrids gitter chat that queryFactory etc are a more idiomatic hybrids pattern, and I agree.

This issue is to track the possibility of reimplementing queryFactory and friends while still maintaining all the logic in mixins, preferably without making any changes to mixins package itself.

We have a variety of tests scattered across the repo. @apollo-elements/mixins does most of the heavy lifting. I would like to see the tests in mixins replicated across packages. i.e. Just like ApolloQueryMixin is tested to make sure that data is set when a good query resolves, so should lit-apollo's ApolloQuery, and Polymer ApolloQuery, etc.

It would be swell to export some testBaseClass(class: Constructor<ApolloQueryInterface>) from test-helpers