There have been some discussions about how prominent GraphQL should be in Prisma Admin. While it's a great way to describe the information you want to query, it's unclear how often people would go back and fiddle with the query after saving a certain filtered/ordered "view".
If we assume that most users will rather interact with the data through UI, it makes sense to push the GraphQL query into a "implementation detail" seat and instead make the necessary actions (filters, sorting, variables?) available through the UI.
Changes
With the introduction of tabs, the "page's" context menu got moved out of the query editor box and next to the page title
The underlying GraphQL query is only visible when clicking on the code icon
The filtering UI is visible when clicking on the filter icon
Removed text from the "Run" button to save space and reduce its focus a bit
Updated the pagination section (#5) to be more explicit about the specific range of items currently shown. User could change the range by editing numbers in the inputs and navigating with the arrows would keep the defined step size.
Making changes to the query or filters would put the results table in a "outdated" mode, with all the text grayed out and "Run" button prominently green.
Questions
By merging the two sections we've killed the ability to have query and the results table side-by-side. It's still an open question if that's something people would like to have or not.
Since the detail sidebar also supports custom views, would it be worth making the detail sidebar and the results table stackable instead? Some custom views may function better in a wider format.
How well do mutation usecases fit into this layout? (Where there is more emphasis on tweaking the query and the response is just JSON or a single node, rather than a table view).
Preview
https://padmin-prototype.netlify.com/
Why
There have been some discussions about how prominent GraphQL should be in Prisma Admin. While it's a great way to describe the information you want to query, it's unclear how often people would go back and fiddle with the query after saving a certain filtered/ordered "view".
If we assume that most users will rather interact with the data through UI, it makes sense to push the GraphQL query into a "implementation detail" seat and instead make the necessary actions (filters, sorting, variables?) available through the UI.
Changes
Questions