search

graphql / graphiql

GraphiQL & the GraphQL LSP Reference Ecosystem for building browser & IDE tools.
MIT License
16.07k stars 1.72k forks source link

Expose errors in building schema #17

Closed leebyron closed 7 years ago

leebyron commented 9 years ago

As #16 encountered, if an introspection result causes issues with building a client schema today we just silently continue without a schema - instead we should present some error so the developer can quickly find and fix the issue.

asiandrummer commented 9 years ago

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

skevy commented 9 years ago

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

Image of redbox

skevy commented 9 years ago

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

kroepke commented 9 years ago

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.

KyleAMathews commented 9 years ago

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

leebyron commented 8 years ago

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.

joelgriffith commented 7 years ago

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

vjpr commented 7 years ago

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.

screen shot 2017-09-12 at 1 15 59 am

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

Also, perhaps this is a different bug...

asiandrummer commented 7 years ago

@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.