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.

[SaraVieira]

Not sure if this is still relevant but in making my personal site I created a material theme:
https://github.com/SaraVieira/graphiql-material-theme

[bkeating]

...this is still open and I haven't found much out there that looks good. Made a quick CSS override that gives me what I want. Pulled colors from Atom's One Dark theme. Needed it. Was the only window open that wasn't dark and it was making my eyes bleed.

Quick and dirty source: https://gist.github.com/bkeating/cfe0d5e72bd3f9f1f77e1a2ff2309972 (relies on !important attribute(?) which is not ideal)

[FireyFly]

I tried to adapt the above CSS into a UserStyle for use with Stylus, but it seems that, at least with the GraphiQL setup included with Apollo's server, the class names for the sidepanel are all minified/generated. E.g. class="sc-fBuWsC fmbSvE" for the <div> that wraps the sidebar, which sets background colour to white. It doesn't seem to be the case with other class names, so I suspect this is a GiQL change rather than Apollo-related?

This means that even the built-in dark theme appears with a stark white Schema sidepanel, and that it's quite hard (and probably not very robust) to style it with these generated class names.

I think I'll go ahead and style the most important bits even with the minified class names, but I'd be interested in knowing if this is intentional/if there's a comfortable way to style GiQL to one's liking/what exactly is producing the class names.

Edit: here's a gist with some CSS for a darker sidebar, using said minified names. It isn't ideal at all, but I don't have too much time making it pretty right now, and it's more pleasant on the eyes than a dark theme with white sidebar at least.

[hansena]

@asiandrummer @leebyron would you be open to a PR for this which allowed for overriding the default classnames? Changes to the render method of <GraphiQL> would look something like:

<div 
  className={this.props.styles && this.props.styles.container 
    ? this.props.styles.container
    : "graphiql-container"}
>

Allowing consumers to override the default styles by doing something like:

<GraphiQL styles={{container: "new-container-classname"}} />

This would open the styling up for cssModules or css-in-js.

[acao]

We plan on providing much better options for custom theming in Version 1.x. Styled components with a theme provider is one proposal. We can discuss whether this is possible in 0.x., trying not to add too much as we prepare for 1.x

[hansena]

@acao makes total sense to wait for v1.x, thanks for the quick response 👍

[alexdobsom]

...this is still open and I haven't found much out there that looks good. Made a quick CSS override that gives me what I want. Pulled colors from Atom's One Dark theme. Needed it. Was the only window open that wasn't dark and it was making my eyes bleed.

Quick and dirty source: https://gist.github.com/bkeating/cfe0d5e72bd3f9f1f77e1a2ff2309972 (relies on !important attribute(?) which is not ideal)

How can one use this theme ?

[acao]

to note, GraphiQL still supports overriding the codemirror theme at least

check out the new storybook of components and theming system we’ve built! should be integrating it in the next month as we finally have the codebase ready for plugins

[acao]

I would suggest using dark reader plugin for now, but yes this can be achieved with some hacky css overrides and by using the editorTheme prop.

Theming system will come in 2.0.0

[xvaara]

Just a quick hack using css filter: https://gist.github.com/xvaara/771d3c92a62d4149fa4e4b6d629b1b2b

[mcnaveen]

Everyone:

Hopefully soon. 😌

[acao]

Hopefully someone will get to it, we are seeking new maintainers if you’re interested!

[acao]

@mcnaveen would you like to open a PR to implement the new theming system that supports dark mode variants? the roadmap is ready for folks to execute on. the theme provider is ready.

We don't have any active contributors towards 2.x unfortunately, so it can't move until people from the community start helping!

[harshitkumar31]

@acao Opened #2146 to get the ball rolling.

[thomasheyenbrock]

The new designs as planned in v2 include a dark mode! This should resolve this issue. For more details about this effort see #2328.

[thomasheyenbrock]

graphiql@2 now comes with a dark theme built-in. It's also very easy to customize all the colors of the UI using CSS variables.

[factoidforrest]

Is there a property to activate this from the react component? My whole app has a theme, it would be nice if they could sync. Is this not exposed as an attribute on ?

[thomasheyenbrock]

Hey @factoidforrest 👋 there currently isn't a prop to control the theme, though I believe it'd make sense to add that. Feel free to open an issue for that! (Please double check that there isn't an existing one before doing so.)

As a workaround for now you can do window.localStorage.setItem('graphiql:theme', 'light' /* or 'dark' */) to force a theme for GraphiQL, but be aware that:

• This needs to happen before the initial render of GraphiQL so that the desired value is read from localStorage
• The user can always overwrite that using the settings modal.