-
Notifications
You must be signed in to change notification settings - Fork 97
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
Ideas for improving the Developer Experience and Feature Discoverability #10
Comments
@dwwoelfel @sgrove @rofrischmann PTAL. 😉 |
I've improved some things:
|
Let me explain some important things about checkboxes and rotating triangles that may not be obvious.
Clicking on the rotating triangles and field names only expand child fields without checking (inserting) them: This is because inserting all child fileds in GraphQL is, generally speaking, bad practice, and can't be the default behavior. The one of the main ideas of GraphQL is to solve the overfetching problem (when API return additional data that's not needed), it gives you the power to ask (show) for what data you need and get exactly that, nothing more and nothing less. Inserting all child fileds may help to overfetching (if the user doesn't care about removing unnecessary fields). But in some cases the inserting all child fileds feature improves the DX (developer experience), e.g. in the case of very complex (auto-generated) API that has large number of types and large number of fields in each type. In this case, it is faster to check all nested checkboxes at once and then uncheck only unnecessary instead of check them only one by one. That's why inserting all child fileds should be here, but shouldn't be the default behavior. |
Here's the updated mockup based on the preview of the new Explorer version: Please note that I've added a button for adding fragments along with buttons for adding queries, mutations and subscriptions. |
The preview of the new Explorer version has one interesting feature — "Jump to definition" via What about a "View" icon that is displayed when hovering over the field in code editor to focus on this field in Explorer, and vice versa? 😉 |
@JakeDawkins PTAL. What about something like that for Apollo GraphQL for VS Code extension? |
👋 Yeah! This is beautiful! I'd love to see something like this in the future. We have a bit of work to do in VS Code around stability and service federation before this could be prioritized, but I'll keep it in mind :) |
I've added icons to refactor/transform any input fields to variables (see altair-graphql/altair#745 for more info). These icons are displayed when hovering over the input fields: |
PTAL at https://marketplace.visualstudio.com/items?itemName=GabrielNordeborn.vscode-graphiql-explorer. 😉 |
Currently, GraphiQL Explorer doesn't support GraphQL list (array) inputs. This is essential feature. It would be really nice to have the support with ability to:
Here's my vision: |
File upload is a recent addition to GraphQL. It allows to upload files directly to GraphQL API in addition to sending text data. It uses an |
@Nishchit14 @10S10 PTAL. 😉 |
You are a gem @FluorescentHallucinogen 🙌 , These all are the killing features. The most challenging feature I can say is Also, date-picker is nicer, but It'll add extra CSS/JS cost in bundle (plugin system would work great here), later we can add options of formating ( We're working on a new design of Firecamp desktop app, and to use explorer I need to plan some customization with it. I'll keep sharing suggestions/feedback on DX improvement :) |
The user would be able to upload multiple files if so provided by the GraphQL schema, i.e. the mutation argument is an array (list) of If the mutation argument is an array, it's assumed that the file upload dropzone uses
Just realized that GraphQL multipart form requests spec requires to use variables to upload file(s). So I've visualized my vision of the "Variables" panel: |
This is what we have in @firecampapp (https://firecamp.app) point no. Although it's an old UI in the blog GIF, but a new design will be up in a week. |
@Nishchit14 Isn't Firecamp open-source? 🤔 Just checked the GitHub repo and haven't found any source codes. |
It's not open source yet, but we've planned for it in the future. we're working on cloud-sync and team-collaboration. Once we release it then start thinking on the OSS model. |
Since Explorer is just another (visual) representation of code, everything that could be possible via code should be possible via Explorer, and vice versa. So here's the equivalent of "Insert child (nested) fields" feature described in #10 (comment) and #10 (comment): Some thoughts: what about removing the field from the autocomplete list if it's already inserted into the query? 🤔 This may improve UX by helping to avoid duplication of fields. |
Here's my vision of equivalent of "Extract to variable" feature described in #10 (comment): Also it would be really nice to have the inverse feature — "Inline variable": |
Agree - to my knowledge this should be feasible in the graphical plugin system! :D |
@nikolasburk @schickling Looks like Explorer-like autocomplete could be applied to GraphQL code-first approaches too. 😉 It would be really nice to have something like this in Prisma Studio for visual constructing of data filters. BTW, thanks a lot to @kuldar from @prisma team for sharing a Figma project with me. All mockups in this thread were made using it. It seems Explorer-like autocomplete could be applied to any TypeScript code. If so, it would be really nice to have this in VSCode (as a plug-in or built-in). @orta WDYT? |
The combo of gqless by @samdenty and Explorer-like autocomplete pictured in #10 (comment) would be a DX game-changer! 🤯 |
Damn these are pretty cool ideas! For gqless I have been toying around with the idea, of creating an all-in-one devtools. gqless will be able to do stuff like auto-dispatch mutations, when you update the cache. So stuff like the Table plugin shown above could be live-editable. This would require direct integration with the gqless Client (but should be usable without one too) With the clients Cache keying logic, we can display "references" to GraphQL data (instead of Query -> temporary response) in the devtools. This would turn the devtools from a REPL, to a full-blown GraphQL data explorer (like MongoDB compass, Prisma's data editor etc.) |
@samdenty sounds great! we are working with vscode on the monaco-editor LSP immplementation as we speak for GraphiQL plugins, that will make building out these experiences very powerful. We will have a GraphiQL Explorer plugin that uses this new monaco service soon! Codemirror Mode will still be available for folks to support, if they want to add the new GraphQL 15 language features learn more about all of this work in our roadmap |
I like the idea to combine documentation viewing and query building in Apollo Studio. 4 months ago I proposed this idea for Explorer. See the end of this comment: #44 (comment). Altair by @imolorhe has a similar feature (adding queries and fragments to code right from docs) for years. See https://altair.sirmuel.design/docs/features/add-queries-and-fragments.html. @acao What about something like this in GraphiQL? |
@FluorescentHallucinogen any RFC proposals are still welcome! if you want to join our plugin API RFC effort so that you can build whatever plugins you want, you are also welcome to join! we have some different schema/DX approaches we plan on implementing for some plugins, you are free to propose anything you like, and we decide in working groups which plugins to prioritize. this discussion would have been great for our working group call today, maybe next time? |
After some thought, I realized that combining docs viewing and query building (while remaining interesting idea/experiment) may be not a good idea from a practical perspective. And here's why:
|
BTW, looks like currently there is no integration between GraphiQL Explorer and GraphiQL Docs. It would be really nice if e.g. |
@FluorescentHallucinogen there is integration between the operation editor and the schema explorer at least, when you click a type name on hover. we will be improving the APIs for this, however an API is already available for this, so this capability you suggest could be introduced with a PR to this repository |
Another crazy idea has came to my mind: a tool similar to GraphQL Editor, but GraphQL Editor is for visual building of GraphQL schemas, and my tool is for visual building of GraphQL queries, similar to GraphiQL Explorer. @aexol cc. |
As a follow-up of my idea of displaying field description popup on hover in #10 (comment) and #10 (comment), here's a visualization of opening docs for the field by clicking on the icon next to it: BTW, docs for the field can also be opened right from the links in the field hover popup. This requires the integration between GraphiQL Explorer and GraphiQL Docs. |
@FluorescentHallucinogen are you programming that, or is that currently only design? And is there any timeline/priority on this? Because I see the issue started already three years ago :) |
@mmailaender That's currently the only design. I've programmed some of my ideas, but my contribution (see #49 as an example) for some reason is just ignored by project authors without any feedback. :( |
@FluorescentHallucinogen seems this project is not really active maintained anymore, based what I see from the commit history. Do you know if GraphiQL has any plans about including your suggestions directly into the main product? |
I hope so, but I don't know for sure. See graphql/graphiql#2216. I'm not sure that all my proposals will be implemented, but some of them definitely will be. GraphiQL has already taken a different path of combining operation building (GraphiQL Explorer) and docs viewing (GraphiQL Docs) into one tool. But my vision is that this is not a good idea, because they solve different problems and this creates visual noise. |
I've visualized how adding directives and constructing their arguments might look like: @Nishchit14 @jonathanawesome @thomasheyenbrock @acao @daniman @aexol @imolorhe @doc-jones PTAL. |
This issue acts as the central place for all discussions of ideas around improving the Developer Experience (DX), Feature Discoverability, Usability and UI design.
It would be great to be able to insert all fields of type (check all nested checkboxes at once and then uncheck only unnecessary instead of check them only one by one). This is very useful for types with a large number of fields.
If a field is 1) non-null AND 2) leaf (terminal / uncollapsible / has no child fields), it should be 1) checked AND 2) disabled (so the user could not uncheck it).
I've visualized these two ideas. Here's my vision (a slightly modified version of Explorer tab from Playground v2 concept):
Compare it with the original:
The text was updated successfully, but these errors were encountered: