Provide a `dark theme` for GraphiQL

[asiandrummer]

Probably a low-priority item (wishlist even), but a dark UI theme has been requested - I'm documenting as an issue here.

[leebyron]

If someone wants to tackle this, it should be as simple as writing a new css file to include - but this isn't something we're going to prioritize on our team.

[renebrandel]

@asiandrummer Are you interested in doing this? If so, I will help you out ;-)

[joelgriffith]

I've written a custom theme for my own implementation elsewhere. It's pretty easy to override the current theme via stronger css selectors. Would it be better to expose an interface via props on the root component?

I think documenting how to override the current theme might suffice in place of widening an API surface area.

[asiandrummer]

@Brene - This continues to be a low priority item on our list of feature requests, so I'm not sure if our team could tackle this in a near future. I'd love to review and help merging this if you'd like to give a hand 😄

@joelgriffith - Documentation for how to customize would be appreciated, but since I think some users of GraphiQL aren't as familiar with css rules, they would also like to have a stock-version of dark theme if it could be as easy as doing <GraphiQL theme="dark" /> or something similar to this.

[joelgriffith]

I can likely implement something like this then (and add docs on how to implement your own theme).

[joelgriffith]

#200 a theme prop (currently only supports dark atm). Here's a screenshot of the dark IDE (mostly just an inverted theme):

[joelgriffith]

Spilling over from my initial PR for this: there's so many color definitions and they're redefined nearly 2x throughout the css. This makes it hard for folks to bolt on their themes (combined with the fact that we don't expose setting a CodeMirror theme).

I feel that if we want to accomplish this for future cases, we should:

• Consolidate color definitions so things aren't redefined all over the place, which will ease theme-writing significantly.
• Potentially merge similar colors. There's quite a few colors that are roughly the same.
• Expose 2 top-level props: classNames and syntaxTheme. One for folks to use to override css via specificity, the other to apply other CodeMirror themes.
• BONUS: source all color definitions in a css-preprocessor. Consumers can then use those definitions and do all the fancy-pants lighten mix or what-have-you's to get the theme their ❤️ so desires.

Thoughts? @leebyron @asiandrummer

[andheiberg]

There are 160 colour definitions. 81 unique colours. Rough sorting... http://codepen.io/anon/pen/PWQWBg

I feel like making it "easy" to maintain these themes would somewhat require using a preprocessor?

Is that something you would accept a PR for?

[joelgriffith]

@AndreasHeiberg that's something that I was advocating for, but I think the consensus is that this project needs to be as lite as possible.

[wincent]

I added a preprocessor in aed3bd9 (specifically for auto-prefixing), so there is already some precedent for preprocessing the CSS. It seems that it would be desirable to do some or all of the following:

1. Reduce the number of colors in the default style sheets by consolidating duplicates (and near duplicates). [We should do this regardless of whether we want to go down the theming path.]
2. Add a preprocessor and refactor to use a centralized list of named color variables.
3. Provide a mechanism to produce a custom build of the styles, using a customized list of named color variables. (My thinking here is that if you care enough to produce a custom theme, you are probably happy enough having to run a build step. People who wish to merely use the stylesheet would only need to drop it on the page.)

Potentially adding a prop to select a specific CodeMirror theme, like @joelgriffith suggested above, would be worth considering too.

I think that list runs from least to most contentious, so we should start with "1." and work down from there.

[andheiberg]

@wincent good shout didn't look at build.sh truth be told I should probably look at how our GraphiQL is setup and what assets it's using.

I think keeping the project lite is a very valuable thing indeed. The other way of solving this would be to have classes for each color essentially. But all you're really saving is for the theme dev to having to duplicate color declarations. I might have a look at actually writing a theme and see where the pain points are.

[joelgriffith]

I agree with @wincent on the proposal. I've themed GraphiQL in AppNexus' usage, and it was simply just the classic "more-specific selectors" approach. It wasn't all that painful of an operation, but maybe a simple document would suffice?

Other forces come into play once you add a variables.{scss|less} as changing those can be a considered a breaking change.

[joelgriffith]

I would like to, at least, expose a top-level prop for the codemirror theme. That'd be a quick win towards customization that'd be practically cost-free

[wincent]

I would like to, at least, expose a top-level prop for the codemirror theme.

That sounds reasonable to me.