Description
Recently I implemented a small app that builds on top of GraphiQL and provides additional functionality like tabs, headers, etc. http://toolbox.sangria-graphql.org/graphiql
Along the way I faced several issues when I tried to include several instances of GraphiQL on the same page. I also tried to use single instance and control it's state via props based on the selected tab, but it did not really worked very well at all. I found "fragile workarounds" for all of the issues, but I would like to list some of the issues with possible solutions in order to provide a better alternatives in future.
- top-level container uses an
id
of the element which is not appropriate if one wants to include several instances on the same page. This also makes styling a bit harder. I thinkclass
would be a better choice here. - GraphiQL always includes an event listener for a key press which also sub-optimal. It would be nice to make it optional and configurable via props. I implemented a very fragile workaround to disable it and registered a single listener for a whole page. This also means that I had to use
_runQueryAtCursor
which I'm not suppose to use from the outside (I assume that underscore == private). It would be nice to "officially" expose this method as well. - CodeMirror inside of the GraphiQL has issues when rendered in a hidden (
display: none;
) div. The gutter size gets messed up a bit. I had to use a trick where I render an empty div on a tab change (first time only) and then, on a next "frame", i render the actual thing. I'm not 100% sure what the actual problem is :)
A minor thing to consider
GraphiQL uses box-sizing: content-box;
. As far as i saw, many people and css frameworks, like bootstrap and foundation, start to adopt box-sizing: border-box;
. it's easy to fix with
.graphiql-container * {
box-sizing: content-box;
}
I'm not very familiar with this field, so i'm not sure what would be a better choice, but still maybe it's a point worth considering