Improvements for a better embedding several instances of GraphiQL on the same page

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 think class 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

[asiandrummer]

Hi @OlegIlyenko! These issues all look legitimate to me - I’ll see what I can do soon. Meanwhile, if you’d like to take a stab at it yourself I’m all for it!

[OlegIlyenko]

To be honest I’m not quite sure either. The last option sounds like a good one if it will work with DOM resize events (it’s still a bit of a mystery to me how and when does codemirror calculates the sizes).

The second option sounds like a good compromise as well. Though in this case I would prefer a single GraphiQL.refresh() function that will refresh codemirror in all editors at once. This will help with better component encapsulation. This generally will not solve the problem (I think), but it will make a workaround a bit simpler.

Generally I would trust your judgment on this one 😃 I’m not quite sure what would be the best solution considering the browser compatibility and development/maintenance effort.

I also updated the last item in my list. I thought about it for a while, and I think it’s not right to put it as a TODO item. I guess it’s a valid point to consider, but it does not necessarily belongs to this issue or even should be implemented now or later.