Given a user would want to follow the Color Intentions pattern for properties other than default (primary, secondary, error). The documentation forwards a user to the material.io Color Tool. The functionality exists in the createPalette function.
Expose method and dependencies of augmentTool or add flag to color definitions of setIntention: true.
import { createMuiTheme, augmentColor } from "@material-ui/core/styles"; // augmentColor isn't currently exported
import { amber, green } from "@material-ui/core/colors";
export default createMuiTheme({
palette: {
success: { main: green[600], augment: true },
info: augmentColor(amber)
}
});
Allow user to generate a custom color intention pattern.
Is the idea here that success.main would be augmented with dark & light?
There was a discussion about adding success, warning and info as default keys alongside error, and exposing them in the appropriate color props. Not sure what's preventing us from doing that now, other than a long term objective to support dynamic color props.../
Is the idea here that
success.mainwould be augmented withdark&light?There was a discussion about adding success, warning and info as default keys alongside error, and exposing them in the appropriate color props. Not sure what's preventing us from doing that now, other than a long term objective to support dynamic color props.../
@mbrookes Correct. If success, warning, and info are added as default, that'd be cool. However, depending on implementation, is there a use case for users to want other augmented intent colors? Say, tertiary or something.
Are there other discussions for dynamic color props? Is that in reference in being able to name a selector via the styles api and pass the key as the "color" prop to a component?
is there a use case for users to want other augmented intent colors
You can do that now, since the function is exposed as theme.augmentColor, it just isn't automagically applied for you when you add a color to the theme.
Are there other discussions for dynamic color props?
Yes, here's one such discussion: https://github.com/mui-org/material-ui/issues/13875
You can do that now, since the function is exposed as
theme.augmentColor
This is in the theme object, which is _after_ the theme is generated. The proposal is to expose augmentColor so it's available to be applied to a color in the options signature for createMuiTheme options object or flag a color that needs to be augmented.
I suppose this would work...
import { createMuiTheme, augmentColor } from "@material-ui/core/styles"; // augmentColor isn't currently exported
import { amber, green } from "@material-ui/core/colors";
const { palette: { augmentColor } } = createMuiTheme({});
export default createMuiTheme({
palette: {
success: augmentColor(green),
info: augmentColor(amber)
}
});
...but it seems kinda silly.
This is in the theme object, which is after the theme is generated.
Uh, whoops, yes. I'm not sure why it's exposed in the theme in that case. 馃
You could probably reduce line 3 to:
const { augmentColor } = createPalette({});
But that's only a little less silly. I have no objection to it being exported directly.