Access to errors in simpleMutation / queries

[gotexis]

it seems that GraphQL errors are thrown into console as JS errors, which makes it difficult to catch and analyze.

Is there some way to access the errors?

[gotexis]

https://www.apollographql.com/docs/react/features/error-handling.html

Now I see it is a wrapper of Apollo client so we shell do Error handling referring to Apollo.

[gotexis]

Because the plugin implements its own flavor of Apollo instead of letting the user construct their client, I guess there is no easy way of hooking on the onError option in the Apollo client.

[phortx]

The user can construct their own apollo link instance. You can pass the link while setting up the GraphQL Plugin :)

If this is not enough, we could allow the user the construct an own client too, maybe.

[gotexis]

@phortx

Thanks for looking into this, but since reading TypeScript is a bit hard for me, I am struggling to modify the code.

But I guess this will solve some other problems, I read in the doc that

It is inefficient to dispatch SimpleQuery and SimpleMutation as Vuex stores actions.

I believe if the Apollo client is manually constructed, then it's easier to use it for both VueX queries and non-Vuex queries. The code will also be more modularized / adaptable.

Back to the topic of error handling, if I was not mistaken, I believe there is a onError hook from Apollo client that needs to be hooked.

[phortx]

It is inefficient to dispatch SimpleQuery and SimpleMutation in Vuex stores.

Where did you read that? It's not inefficient at all :)

Apollo has nothing to do with Vuex. Plugin-GraphQL is a bridge between Vuex-ORM and Apollo.

We could provide the onError hook in the configuration of this plugin, that shouldn't be any problem :) Thanks for the hint!

[gotexis]

@phortx

from here https://vuex-orm.github.io/plugin-graphql/guide/custom-queries.html

Marked yellow

Yeah that's what I thought, it shouldn't be any problem dispatching an action there but hey, I didn't wrote the documentation :)

[phortx]

It says it's not a clean solution. It is efficient, but from a architectural view not ideal ;)

[gotexis]

Right....OK whatever you say boss haha.

Right now I am still a bit confused about the barrier b/t apollo link and apollo client. But that's ok, I will figure it out eventually, but I just would like to consult if there is any barriers of implementing the WS version of apollo-link in the current stack.

https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-ws

There official link settings is like:

import { WebSocketLink } from "apollo-link-ws";
import { SubscriptionClient } from "subscriptions-transport-ws";

const GRAPHQL_ENDPOINT = "ws://localhost:3000/graphql";

const client = new SubscriptionClient(GRAPHQL_ENDPOINT, {
  reconnect: true
});

const link = new WebSocketLink(client);

Since you know, websocket is so cool :)

[phortx]

Websocket is really cool!

I don't think it's complicated to bring apollo-link-ws into this plugin. The biggest barrier is that I don't have any time currently for working on this plugin :(