-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access to errors in simpleMutation / queries #83
Comments
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. |
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
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. |
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 |
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 :( |
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?
The text was updated successfully, but these errors were encountered: