Overriding default button colors

[WebDevTmas]

I seem to be unable to override a primary buttons color.

  const newTheme: Theme = {
    ...defaultTheme,
    spinnerColor: "hotpink",
    colors: {
      ...defaultTheme.colors,
      intent: {
        ...defaultTheme.colors.intent,
        none: "hotpink",
      },
    },
  };

Is this not based on the intent color? (spinner override works perfectly)

[isTravis]

I've found a lot of the theming work is undocumented and fairly complex. You can't simply inspect the defaultTheme object and overwrite values because the real theme is derived from a set of functions and certain values are provided on that object (e.g. button colors) for convenience rather than canonical reference. To get overrides to work, I had to duplicate the getButtonAppearance function that defaultTheme relies on. I split things like this into separate files for each function that needs to be reproduced:

/* getButtonClassName.ts */

/* Copied from https://github.com/segmentio/evergreen/blob/master/src/theme/src/default-theme/component-specific/getButtonClassName.js */
/* Orignal values are left as comments next to their overwritten value */

// @ts-nocheck
import { Themer } from "evergreen-ui/commonjs/themer";
import memoizeClassName from "evergreen-ui/commonjs/theme/src/default-theme/utils/memoizeClassName";
import scales from "evergreen-ui/commonjs/theme/src/default-theme/foundational-styles/scales";
import {
	getTextColorForIntent,
	getPrimaryButtonStylesForIntent,
} from "evergreen-ui/commonjs/theme/src/default-theme/helpers";
import { defaultControlStyles } from "evergreen-ui/commonjs/theme/src/default-theme/shared";

/**
 * Disabled styles are all the same for all buttons.
 */
const { disabled } = defaultControlStyles;

/**
 * Get button appearance.
 * @param {string} appearance - default, primary, minimal.
 * @param {string} intent - none, success, warning, danger.
 * @return {Object} the appearance of the button.
 */
const getButtonAppearance = (appearance, intent) => {
	switch (appearance) {
		case "primary": {
			const { linearGradient, focusColor } = getPrimaryButtonStylesForIntent(intent);
			return Themer.createButtonAppearance({
				disabled,
				base: {
					color: "white",
					backgroundColor: "white",
					backgroundImage: linearGradient.base,
					boxShadow: `inset 0 0 0 1px ${scales.neutral.N5A}, inset 0 -1px 1px 0 ${scales.neutral.N2A}`,
				},
				hover: {
					backgroundImage: linearGradient.hover,
				},
				focus: {
					boxShadow: `0 0 0 3px ${focusColor}, inset 0 0 0 1px ${scales.neutral.N4A}, inset 0 -1px 1px 0 ${scales.neutral.N5A}`,
				},
				active: {
					backgroundImage: linearGradient.active,
					boxShadow: `inset 0 0 0 1px ${scales.neutral.N4A}, inset 0 1px 1px 0 ${scales.neutral.N2A}`,
				},
				focusAndActive: {
					boxShadow: `0 0 0 3px ${focusColor}, inset 0 0 0 1px ${scales.neutral.N4A}, inset 0 1px 1px 0 ${scales.neutral.N2A}`,
				},
			});
		}

		case "minimal": {
			// const intentTextColor = getTextColorForIntent(intent, scales.blue.B9);
			const intentTextColor = getTextColorForIntent(intent);
			return Themer.createButtonAppearance({
				disabled,
				base: {
					color: intentTextColor,
					backgroundColor: "transparent",
				},
				hover: {
					backgroundColor: scales.neutral.N2A,
				},
				focus: {
					// boxShadow: `0 0 0 3px ${scales.blue.B5A}`,
					boxShadow: `0 0 0 3px ${defaultControlStyles.focus}`,
				},
				active: {
					backgroundImage: "none",
					// backgroundColor: scales.blue.B3A,
					backgroundColor: scales.neutral.N3A,
				},
				focusAndActive: {},
			});
		}

		case "default":
		default: {
			const intentTextColor = getTextColorForIntent(intent);
			return Themer.createButtonAppearance({
				disabled,
				base: {
					color: intentTextColor,
					...defaultControlStyles.base,
				},
				hover: defaultControlStyles.hover,
				focus: defaultControlStyles.focus,
				active: defaultControlStyles.active,
				focusAndActive: defaultControlStyles.focusAndActive,
			});
		}
	}
};

/**
 * Get the className of a `Button`|`IconButton`.
 * @param {string} appearance - default, primary, minimal.
 * @param {Intent} intent - none, success, warning, danger.
 * @return {string} the appearance class name.
 */
export default memoizeClassName(getButtonAppearance);

And then I use that function in place of the default when updating my defaultTheme:

import { defaultTheme } from "evergreen-ui";

import getButtonClassName from "./getButtonClassName";

export const theme = {
	...defaultTheme,
	getButtonClassName,
	spinnerColor: "hotpink",
};

The spinner seems to be a simpler case that works in a straightforward way, while things like buttons, forms, radio buttons, etc are not.

Would love an update from Evergreen folks on what the roadmap for clearer theming support or documentation looks like!

[WebDevTmas]

That's a work :D Thank you for the information!

[akleiner2]

Hey there! Sorry for the relative silence here - the team's been quite busy with projects internally, so we haven't had a chance to engage here as frequently as we'd like.

For theming in v5, @isTravis is spot on. It's a bit convoluted right now, but the way to get theming to work - for Buttons, or any of the other getXClassname theme methods - is to basically override them yourself, following the internals of Evergreen. How you choose to do this is open-ended, but note that it will require you to target the same pseudoselectors in evergreen/src/themer/src/createButtonAppearance.js:L19-L25.

On the roadmap for v6 (which should be coming out in the next couple of months) include end-to-end theming support that's super flexible and straightforward. We're still hardening out the API and need to do things like doc-writing, etc for it - but it should solve the vast majority of use cases where theming's needed.

[brandongregoryscott]

Hey @NikxDa - you should be able to setup overrides for the default theme with merge from lodash, similar to this example for overriding fonts: #1163 (reply in thread)

Buttons (and some other components) have 'appearances' that you can add onto or override in the theme. The button appearances that ship w/ the default theme are primary, minimal, destructive and default. I spun up a CSB with a short example of overriding the primary and destructive appearances: https://codesandbox.io/s/evergreen-discussions-1106-t46ki

[NikxDa]

@brandongregoryscott Thanks for providing that example! I agree that it's technically possible, but your CodeSandbox highlights the issues I raised. The box-shadow on focus for example is still blue, and there are no active or hover states. I could absolutely just theme them onto the component, too, but at that point I feel like I'd be recreating the styling almost completely.

Shouldn't there be a set of primary colors that can be changed? So instead of the Button internals using blue100 for the box-shadow, shouldn't it be using primary100 so it can be easily redesigned? I can completely change the primary appearance by just assigning pink shades to the blue colors from the theme, but I'd argue that's not the point?

[brandongregoryscott]

Ah, I see. The active, hover and other states can be overridden like this:

primary: {
    color: "white",
    backgroundColor: "#fc7ef8",
    _hover: {
      backgroundColor: "#fc03f0"
    },
    _focus: {
      boxShadow: "0 0 0 2px #fccafa"
    }
  },
  destructive: {
    color: "white",
    backgroundColor: "#fcc57e",
    border: "none",
    _active: {
      backgroundColor: "#fc9003"
    },
    _hover: {
      backgroundColor: "#fc9003"
    },
    _focus: {
      backgroundColor: "#fc9003",
      boxShadow: "0 0 0 2px #fce7ca"
    }
  }
}

Note that the pseudoselectors (_hover, _active, etc.) need to map to the ones that are wired up in the Button component itself

evergreen/src/buttons/src/Button.js

Lines 46 to 53 in f9cb3da

	export const pseudoSelectors = {
	_active: '&:not([disabled]):active, &:not([disabled])[aria-expanded="true"], &:not([disabled])[data-active]',
	_disabled: '&[disabled]',
	_focus: '&:not([disabled]):focus',
	_focusAndActive:
	'&:not([disabled]):focus:active, &:not([disabled])[aria-expanded="true"]:focus, &:not([disabled])[data-active]:focus',
	_hover: '&:not([disabled]):hover'
	}

Edit: I suppose you can also define the pseudoselectors with string key syntax, i.e.

'&:active': {
  backgroundColor: "#fc9003"
}

but they aren't guaranteed to override the specific selectors that we have setup in the base component, if that's what you're looking for. (i.e. just using '&:focus' for Button has different behavior than _focus since it is mapped to '&:not([disabled]):focus')

[NikxDa]

@brandongregoryscott Thanks again for your detailed answer. I am aware I can override styles the way you describe but I think it is still missing the point. Let me try explaining again with a specific example:

In your code, you use hex colors directly to override the button styles, and you also override the box shadow with a specific value. If the default box shadow styling were to change to, say, a 3px box shadow, my overridden styles would not reflect this.
Since I am just trying to change the actual color, I would think the Button itself should use a box-shadow that - instead of directly referencing the blue shade - should reference a generic primary shade, that can then be overridden in the theme colors. This way, I don't have to worry about implementation details like the box shadow itself, but can just change the colors in the theme and be done with it in all components (no need to override any actual properties like box shadow)

[brandongregoryscott]

Ah, gotcha. Unfortunately, the generic color keys that we use in the default theme/our application design language (blue100, blue200, etc) provide additional granularity in the available color scales but are harder to re-theme at this level vs. semantically named keys (color-background-destructive, etc).

I'm not sure we have a refactor like this on the roadmap, currently, but we'll take the feedback into consideration for future iterations.

I'm not suggesting this is a great solution, but if you wanted to do a full pass of color changes, you could set up your own color tokens and remap them to what Evergreen uses internally without overriding individual components. Again, you'll be constrained to the current tokens (blue100, blue200, etc - though you don't need to use them all, just set them to the same value as the next shade up/below to reduce the overall color palette) and there might be some digging involved to completely re-do it all, but this is a proof-of-concept for replacing the blue and red color scales with more semantic primary and destructive values: https://codesandbox.io/s/evergreen-discussions-1106-color-remapping-28plw?file=/src/App.tsx

https://github.com/segmentio/evergreen/blob/master/src/themes/default/tokens/colors.js and https://github.com/segmentio/evergreen/blob/master/src/themes/default/tokens/fills.js will be useful for reference here.