Expose errors in building schema about graphiql HOT 9 CLOSED

It's not quite true that without a schema nothing works. You can at least still use the editor with syntax highlighting and you can still send queries (we just won't validate them first). For that reason I'd rather not red-box the whole screen, but certainly outputting a clear error in the right pane is a good idea.

Our current behavior of silently continuing or printing a JS error with stack trace is clearly lacking though.

From first-principles, GraphiQL's role is to be a valuable tool for exploring and testing queries against a GraphQL server. I believe that should include diagnosing a broken server. So GraphiQL should do it's best to report with clarity why a server's introspection result is considered broken (relevant code here: https://github.com/graphql/graphql-js/blob/master/src/utilities/buildClientSchema.js)

This has obviously not been a priority for Facebook because our server is never broken like this, but it's understandable that someone could encounter a broken server and having clearer messaging about how to fix it is high value.

from graphiql.

I'll get either a simple dialog or info button on the top bar to expose errors to begin the effort

from graphiql.

@asiandrummer @leebyron what about displaying a redbox error (like on React Native), since without a schema, nothing works:

from graphiql.

With this method, I feel like you could bubble up fatal errors from the lower components and display this as well.

from graphiql.

Even logging something to the console can be helpful, in my case it was an incompatible field definition between an interface and an implementation type.

from graphiql.

👍 this would be great. @skevy has a working version of this for the electron wrapped version of GraphiQL.

from graphiql.

Having an error in the right pane I think is a good idea initially, but if a user runs a query that pane will show new data (Unable to fetch or whatever).

I've been thinking it might be nice to signal a potential problem by decorating the "play"/run-query button, similar to how the prettify button hanges hue when there's syntax issues. Once the user hovers over execute query button, we can show a message underneath by using the tooltip. Obviously if a query returns results/200 we can remove any decoration.

I can try and tackle this over the next few days if this sounds like a decent approach @leebyron

from graphiql.

At present, when I receive an error from the server when working with subscriptions it would show up as:

[object Object]

The only way I could find the error was by locating the web sockets frames. Not very optimal.

Perhaps this is my server implementation not throwing errors correctly though...

Also, perhaps this is a different bug...

from graphiql.

@vjpr yeah that seems like a different issue. The error is handled from this code and it's basically a String casted error.stack.

On the other hand, I'm closing this issue due to inactivity. I like the decorating solution, so if someone wants to tackle that then I'm willing to collaborate to get it committed. @vjpr feel free to open an issue for another issue if you're still having problems please.

from graphiql.