Feature/dark theme

[joelgriffith]

Super hot dark theme, super slick css, all in one nice PR:

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[joelgriffith]

Figured we could keep this open to future theme(s)

[leebyron]

Could this be done in a simpler way? For example, if there are more themes in the future - this sets a precedent that they can only be added by PR to this repo. Ideally anyone can write and share their own themes and host them in whatever repo they like.

What do we need to do for GraphiQL to enable that? Are the CSS class names descriptive enough that the only necessary thing is to just add another CSS file to the page? Do we need the ability to set an additional classname on the GraphiQL root node?

[joelgriffith]

I think it's easy enough to add your own body/html class and overwrite the current theme via css selector specificity. I've already done this myself in a few implementations. We could also expose an optional className prop to make this more explicit to users. Mostly this just needs to be documented and, potentially, we have a pre-done dark theme for users.

My final thought is that colors and other backgrounds are defined in numerous places, so theming can be kind of painful since you have to overwrite numerous selectors. This begs for either refactoring the css to make theming easier, or implement some preprocessor so consumers can overwrite variables and generate the css themselves.

[joelgriffith]

I'm going to close this PR and work on another branch that more descriptively shows how to theme, and offers a dark theme as an example

[joelgriffith]

Hrm, doing some digging on color definitions:

ack '\#.*;' css | grep -o '\#.*;' | sort | uniq | tee >(wc -l) => results in around 72 unique color definitions.

Dropping the uniq in my command shows that each color is defined around ~2 times: 139. I'm not sure what the threshold is in moving to a css-preprocessor, but this amount of colors and definitions makes it hard(er) for consumers to apply custom themes as there's a ton of rules to rewrite.

[swyxio]

i would be interested in this

[rjrobinson]

And another year later

[prakashn27]

And two more years later...

[acao]

@joelgriffith did you ever re-open this PR? this accidentally was cross referenced when merging other repos