plugin-graphql
plugin-graphql copied to clipboard
Access to errors in simpleMutation / queries
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?
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.
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.
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.
@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.
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!
@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 :)
It says it's not a clean solution. It is efficient, but from a architectural view not ideal ;)
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 :)
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 :(